Using SCOM to Detect Overpass the Hash Attacks

Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.

An overpass the hash attack is another flavor of a pass the hash type attack except that the attacker is passing a key instead of an NTLM hash.  As such, it is technically a kerberos based attack.  This type of attack is useful once an environment is already compromised as the key needed for the attack is obtained from a domain controller.  If the attacker has already compromised your domain controller, they have a number of options at their disposal, including things like a forged golden or silver kerberos tickets (I hope to cover that at some other time).  Once an attacker has your key, they can essentially impersonate you from any system, whether or not your password hash is exposed on the system in question.  As I learned in working on this article, detecting this type of attack is not easy.  Step one was to mine my key from a domain controller:

You can see from my output that with the right access, this is relatively easy to tease out. In this particular case, I’m looking at my AES256 key, though other keys can work here too. Unfortunately, I haven’t been able to spot any worthwhile breadcrumbs at this point.  I’ve discussed this a bit with some of our internal security experts, and unfortunately, there does not appear to be an easy way to tease a lot of this out of my logs.

Now that said, I’ve obtained a key. The next step is essentially to perform a pass the hash attack injecting they key into the PTH instead of an NTLM hash.  Mimikatz has this feature built into it, and I found that it works quite easily in my lab.

I should note that in this scenario, I’m signed on to a member server that does not have an unwitting domain admin signed on to it. Running this launches a shell under the credentials of the domain admin account that I mined from the DC.  However of note, that does generate a useful breadcrumb.  It doesn’t note the account being impersonated, but it does note the user account doing the impersonation:

The target username in this case is the account that is signed on to the server, not the one that is stolen, but this event is clearly generated by my activity. I’d further note that the credential swap rule I created in my initial pass the hash article catches this one already, so I don’t need to create a new rule, but for the record, I’ll repost the screenshot.