Now that we’ve looked at how pass-the-hash and pass-the-ticket attacks work and what to do to detect them, let’s take a look at overpass-the-hash. Basically, this is a combination of both attacks. The idea of overpass-the-hash is for an attacker to leverage the NTLM hash of another user account to obtain a Kerberos ticket which can be used to access network resources. This can come in handy if you are only able to obtain the NTLM hash for an account, but require Kerberos authentication to reach your destination.

Let’s take a look at how it works.

But first, sign up for our upcoming webinar where I will review the entire blog series “Understanding Lateral Movement in Active Directory and How to Defend Against It”. REGISTER NOW!

How Overpass-the-Hash Works

The first step is the same as with a pass-the-hash attack: we need to obtain the NTLM hash for an account we wish to compromise. For that we will use Mimikatz:

Privilege::debug Sekurlsa::logonpasswords

Now that I have the NTLM hash for the user I want and can perform a pass-the-hash attack:

Sekurlsa::pth /user:[USER] /domain:[DOMAIN] /ntlm:[NTLM HASH]

Not only did we just pass-the-hash, we overpassed it! You can see that the NTLM hash was passed into the Kerberos authentication provider using RC4 encryption. This is possible because Microsoft provides the ability to create RC4-HMAC-MD5-encrypted Kerberos tokens based on the NTLM hash. This is supported primarily for backwards compatibility, but it works nonetheless. In essence, all you need is a user’s NTLM hash to create a Kerberos ticket with the lowest level of security. Even if the security is bad, it still works. For more details you can read up on this in Benjamin Delpy’s blog.

You can also create Kerberos tickets using other information about a user such as their AES keys. Mimikatz allows you to extract this in a couple different ways. The DCSync command returns this information for any user in the domain if you have the proper Active Directory permissions. Also, you can use the sekurlsa:: ekeys command on your local system.

Lsadump::dcsync /user:[USER] /domain:[DOMAIN]

Now I have access to that user’s AES keys.

From there I can issue a pass-the-hash command to inject the AES key into a Kerberos ticket. This will be more difficult to detect as it will use more secure and commonly used encryption keys.

Sekurlsa::pth /user:[USER] /domain:[DOMAIN] /aes256:[AES256 KEY]

Now we can authenticate as this user, and if we use the klist command we should see AES256 encrypted Kerberos tickets being used for our authentication:

Okay, so now that we have seen how overpass-the-hash works, let’s take a look at how to detect it.

Detecting Overpass-the-Hash Attacks

We know that overpass-the-hash leverages portions of the pass-the-hash and pass-the-ticket attacks, so to build out a detection strategy we need to look into how we built detections for those.

If you read the post on detecting pass-the-hash, we were able to build a detection by looking for a specific event log signature on each endpoint:

Event ID 4624 with Logon Type = 9, Authentication Package = Negotiate, and Logon Process = seclogo

Sysmon Event ID 10 LSASS process access

When you see both of those at the same time, you’ve got pass-the-hash. Well, the same applies to detection for overpass-the-hash. The process of injecting the NTLM authentication and Kerberos tickets into a new session is the same in both attacks. There is no way (that I could find) on the endpoints to distinguish what options were passed into the pass-the-hash command from the event logs.

It looks like we need to take a broader look to distinguish between pass-the-hash and pass-the-ticket. Here is the event logs you can observe when performing a pass-the-hash attack on the network:

Source Host Target Host Domain Controller 4648 – A logon was attempted using explicit credentials. 4624 – An account was successfully logged on. Logon Type 3, NTLM 4776 – The computer attempted to validate the credentials for an account. 4624 – An account was successfully logged on. (Logon type = 9 Logon Process = Seclogo) 4672 – Special privileges assigned to new logon. 4672 – Special privileges assigned to new logon. (Logged on user, not impersonated user)

If I perform the same attack using overpass-the-hash, here is what I will see:

Source Host Target Host Domain Controller 4648 – A logon was attempted using explicit credentials. 4624 – An account was successfully logged on. (Logon Type = 3, Logon Process = Kerberos, Authentication Package = Kerberos) 4768 – A Kerberos authentication ticket (TGT) was requested. (Encryption Type for RC4/AES128/AES256) 4624 – An account was successfully logged on. (Logon type = 9 Logon Process = Seclogo) 4672 – Special privileges assigned to new logon. 4769 – A Kerberos service ticket was requested. (Encryption Type for RC4/AES128/AES256) 4672 – Special privileges assigned to new logon. (Logged on user, not impersonated user)

The main difference is you will see Kerberos authentication activity at the domain controller rather than NTLM. It is worth noting that at the domain controller you can see the encryption level for the tickets which will have values such as 0x17 for RC4, 0x11 for AES128, and 0x12 for AES256. However, as we’ve demonstrated this is not a reliable detection technique as an attacker can specify any or all of these when creating a ticket.

Our best method of detection is still to look at the endpoints to find out if a pass-the-hash occurred using event ID 4624 with Logon Type = 9 and optionally Sysmon for reduced false positives. From there, we can inspect our domain controller logs and see if we see event ID 4776 for that user (pass-the-hash) or 4768/4769 (overpass-the-hash).

Also to note, the detection we covered in ourpass-the-ticket post is useful here as well. That involves inspecting user sessions for their associated Kerberos tickets. If a ticket exists that doesn’t match the user associated with the session, then there has been a ticket injection.

One useful thing with overpass-the-hash is that we get the 4624 event on the endpoint with logon type 9, and this contains the session ID for the new session:

I can see I have a new logon for the user Michael. If I use the klist –li command on that logon ID, I can see any associated Kerberos tickets, and in this case it will show the tickets from the compromised user:

This is a useful way to determine for sure if it was a pass-the-hash or overpass-the-hash attack that took place.

So there we have it. There are certainly useful ways to detect these lateral movement techniques on your network, most of which require collection of event logs and diagnostic scripts on each and every endpoint as well as domain controllers. To look at other approaches to detecting and preventing these and other Active Directory based attacks, check out StealthDEFEND.

Interested in getting notifications for other blogs in this series? Sign up here.

Then, register for our upcoming webinar on AD lateral movement to get all the details!