Overpass-the-hash, also called pass-the-key, converts a stolen NT hash (or AES key) into a legitimate Kerberos Ticket Granting Ticket. Instead of replaying the hash over NTLM, the attacker uses it as the account's Kerberos long-term key to request a TGT, then authenticates over Kerberos to any service. This blends into normal Kerberos traffic and reaches services that reject NTLM. Defend by protecting credential material (LSASS, Credential Guard), preferring AES, and detecting anomalous ticket requests.
What overpass-the-hash is
Pass-the-hash replays an NT hash over NTLM. Overpass-the-hash goes a step further: it uses that same hash as the Kerberos secret key for the account and requests a real TGT from the domain controller. The attacker now has a valid Kerberos ticket, so they operate over Kerberos, which is harder to spot and works against services that only accept Kerberos.
How the attack works
After dumping a hash (for example from LSASS), the attacker requests a TGT with the hash as the key using Rubeus asktgt /user:<user> /rc4:<nthash> /ptt, or mimikatz sekurlsa::pth /user:<user> /ntlm:<hash>. The returned TGT is injected into the session, and the attacker then requests service tickets and moves laterally over Kerberos. Using the account's AES key instead of the RC4 hash makes it blend in even more. Shown for defensive testing.
How to defend against it
The root cause is the same as pass-the-hash: stolen credential material. Protect LSASS with RunAsPPL and Credential Guard, keep tier-0 credentials off lower-trust machines, and enforce AES so RC4 (legacy) ticket requests stand out. Detect anomalies such as a TGT requested with RC4 for an account that normally uses AES, or ticket requests from unexpected hosts.
References
- [1]MITRE ATT&CK Enterprise Matrix(MITRE ATT&CK)
- [2]Microsoft: Kerberos authentication overview(Microsoft)
A single stolen hash can become a domain-wide Kerberos foothold. Talk to a security expert about testing your credential-theft exposure.