In this video, Trenton Ivey, SecureWorks Security Analysis Consultant, gives a demonstration of how, after initial compromise, an attacker would conduct internal recon and subsequently use a PowerShell Empire module to deploy a new agent on a domain administrator's laptop.

To learn more, watch the full webcast that features SecureWorks technical testers demonstrating and speaking about:

  • Examples of real-world engagements
  • Tactics and techniques commonly used to achieve their objectives
  • Trends and weaknesses they are seeing in defenses
  • Lessons learned

Transcript:

Now that we can use PowerShell Empire to execute commands on a system connected to a target environment, let's start by performing a little bit of internal reconnaissance. We can get some basic system information by running the system info command. For now, just note that system is joined to the corp.acme.local domain and that our current user's name is included in the host name.

Before doing much else, we should understand what processes are running on the system. We can do this by using the PS command. Commands like ipconfig, netstat, and arp -a can start to give us an idea of the local network. Let's get a list of domain administrators. We can see that lcurtis up here is to be the only domain administrator besides the built in administrator account.

Let's get some more information about this user. While it may seem insignificant, organizations can make our jobs easier by including some type of user information and system naming conventions. Let's see if we can find a system related to the lcurtis user. We can see a system called DESKTOP-LCURTIS, let's make a note of this.

We are still running under the context of our target user, who is not an administrator so let's try to find a quick way to escalate privileges and start moving around the network. Many organizations use sysprep to help standardize the creation of new systems. Many times, we find clear text passwords in configuration files.

So let's look for some interesting files such UnattendGC, sysprep.xml, and sysprep.inf in a few common locations. It doesn't look like this technique will work this time. Before Microsoft released the security update in 2014, administrators could create group policies containing passwords. This allowed administrators to easily update accounts.

Unfortunately, the passwords are protected with a publicly available encryption key. This allows attackers to quickly recover credentials. Although many organizations have now applied a patch to prevent hard coded passwords and new policies, they haven't removed old policy objects containing hard-code credentials.

So, let's check and see if any policies have hard coded credentials. We can see that the local admin account was renamed to ACME-ADM and that the account also has a hard-coded password. Let's take note of this. Now we have the name of a domain administrator to target and the name of their system. We also have a local administrative credential.

Let's tie it all together. We'll use a PowerShell Empire module called Invoke_wmi to try to deploy a new agent on the domain admin's laptop. We now have access to a domain administrator system. We're well on our way to compromising the Acme domain.

SecureWorks Corp. published this content on 16 January 2017 and is solely responsible for the information contained herein.
Distributed by Public, unedited and unaltered, on 16 January 2017 19:20:04 UTC.

Original documenthttps://www.secureworks.com/resources/vd-technical-testing-part-6

Public permalinkhttp://www.publicnow.com/view/48D8E23000FDDA82A324588D6799DA143A6CDC9D