Using Machine Account Passwords During an Engagement

Introduction

Of the many advancements in red teaming over the last 12 months, the development of BloodHound has provided a monumental step forward and is quickly becoming an essential tool in the arsenal of an attacker.

During a recent red team engagement, we were given the opportunity to really put this tool to good use within an Active Directory forest, with one of the goals of the assessment being to find a method of accessing Enterprise Admin.

After embedding ourselves within the targets internal network, we fired up the new "Sharphound" ingestor of BloodHound. After loading the results into BloodHound, a potential path was quickly identified. This path happened to travel via a server running Windows Server 2008 R2, which was a member of a group with a number of desirable privileges which would help facilitate our privilege escalation. Unfortunately for us, shortly after gaining access to this server we found our access cut short and we later found that the server was taken offline.

Sometimes things like this will happen during an engagement, so we returned to the drawing board and attempted to figure out another route to our destination, however we quickly found that all routes came back to this now unaccessible host. Fortunately for us, we have previously run Mimikatz's "sekurlsa::wdigest" against the host to recover some credentials of logged in users in a familiar format (recreated below in our lab environment):

Now, as you browse through the results you would be forgiven for skipping over that huge block of text at the bottom. To be honest, many of us have trained ourselves to just look for the juicy passwords and disregard these ugly blocks of text that are helpfully thrown up, however in this case if we take a look at an early comment from the creator of Mimikatz, we actually see this:

So this means that if a password is found to contain non-printable characters, a hex dump of the password is provided instead. Also, this is clearly associated with a machine account (or computer account as it is sometimes referred) with the familiar "<SERVERNAME>$" name format. Knowing this, we wanted to see if it was possible to take this password and reuse it with our tools to regain the privileges that the machine account held.

Recreating in our lab

To recreate this scenario in a lab environment, we will begin with the following simple network layout:

With our network created, we will set up our lab Active Directory objects to consist of:

1. A group named "Trusted Servers" containing our Windows 2008 R2 server
2. A user named "DA" which is a member of the Domain Admins group.
3. A group named "Admins" which contains the "DA" user.
4. Delegation between the "Trusted Servers" and "Admins" groups allowing "All Extended Rights".

Running Sharphound (the latest bloodhound ingestor available here) on the domain from our attacking machine, we can see our attack path from the machine account "WIN2008R2" to "Domain Admins" is correctly identified:

With this, we know that the machine account belonging to "WIN2008R2" (which is a member or "Trusted Servers") has permission to add users to the "Admins" group.

If we run Mimikatz on the WIN2008R2 host and collect it's output, we will see something that looks like this:

As mentioned in gentilkiwi's comment above, this is a hex dump of the machine account password as it contains non-printable characters. The easiest way to deal with this kind of password is to convert it to a NTLM hash. To do this, we can use a simple Python script (courtesy of TrustedSec):

If we run this small script on the above machine account password, we see the following output:

Alternatively, if you opt for the "sekurlsa::logonpasswords" option of Mimikatz, you will find that the NTLM hash of the machine account is available:

Now we have our NTLM hash, what can we do with it? Well one possibility is to use a technique called "overpass-the-hash" to retrieve a Kerberos ticket from the domain controller. If you have never come across this technique before, overpass-the-hash relies on the fact that to pre-authenticate with a key distribution centre (usually the DC), the NTLM hash is used to encrypt a challenge/timestamp (a full explanation of this attack available over on gentilkiwi's blog here).

To pull off this attack, we can use Invoke-Mimikatz with the following command:

When executed, the resulting session will allow you to impersonate the machine account via a command prompt, allowing you to take advantage of those interesting paths in BloodHound, even when the original server is inaccessible.

Demo

OK time for a demo. In the below video, we can see our attacking host with a user logged on as the local Administrator account.

Once we complete our "Invoke-Mimikatz" command, you will see that the machine account becomes available and we can interact with the domain as though our machine was authenticated to the domain natively:

Protecting yourself

So how do we protect ourselves against these kinds of attacks? Well first it's important to understand that a machine account is simply another kind of object in Active Directory. That is to say that just because you have powered down a computer, that doesn't mean that any captured machine account password is unusable.

If you suspect that a machine may have been compromised, you can disable the machine account in Active Directory by right-clicking on the computer object, and selecting "Disable Account". Then, if an attacker attempts to use the machine account password, they receive a nice "Access Denied" warning:

It is also possible for an administrator to reset a machine account password by using the "Reset-ComputerMachinePassword" command in PowerShell

Finally, the principle of least privilege should be applied to machine accounts in the same way as any other account. The primary line of defence is to restrict access wherever possible, and this should always include machine accounts.