Overpass-the-Hash — NTLM Hash to Kerberos TGT Conversion

MITRE ATT&CK

Security Relevance

Overpass-the-Hash is strategically important because it lets attackers escape NTLM-based detection while using only what they already have — an NTLM hash. In environments where NTLM is blocked at the network layer or triggers SIEM alerts, attackers use OPtH to convert their stolen hash into a legitimate Kerberos ticket and continue laterally via Kerberos. Unlike a Golden Ticket (which forges a TGT entirely), OPtH requests a real TGT from the DC — generating Event 4768, which is normal Kerberos traffic. The detection signal is not the presence of 4768 but its characteristics: RC4 encryption when AES is enforced, a source IP that doesn't match the account's known workstation, and a TGT request immediately followed by service ticket requests (4769) for sensitive targets.

Indicators of Malicious Use

• ⚑Event 4768 with Ticket Encryption Type 0x17 (RC4-HMAC) in a domain with 'Network security: Configure encryption types allowed for Kerberos' set to AES128/AES256 only — the hash was used as an RC4 key for Kerberos pre-auth
• ⚑Event 4768 source IP (Client Address) does not match the account's typical workstation or the last known login location — TGT was requested from an attacker-controlled host
• ⚑Event 4624 Type 9 (NewCredentials) on the attacker's source host immediately before or after 4688 for Mimikatz — sekurlsa::pth creates this logon type when spawning a process with new credentials
• ⚑Event 4688 or 4104: sekurlsa::pth, Rubeus asktgt /rc4:, Rubeus asktgt /aes256: — explicit OPtH tool signatures
• ⚑Rapid sequence of Event 4769 (service ticket requests) for multiple high-value SPNs from the same account/IP shortly after a 4768 — attacker received a TGT and immediately began mapping access
• ⚑Event 4768 for an account that is in the Protected Users security group — Protected Users members cannot use RC4 for Kerberos; an RC4 4768 for such an account indicates either the group is misconfigured or the account was removed from it

Example Log Entry

-- On the attacker's source host --

Event ID: 4688 — A new process has been created
  Process Name:  C:\Windows\System32\cmd.exe
  Command Line:  sekurlsa::pth /user:svc_backup /domain:corp.local
                 /ntlm:aad3b435b51404eeaad3b435b51404ee /run:cmd.exe
  ← Mimikatz spawns cmd.exe with a Kerberos identity for svc_backup

Event ID: 4624 — Logon on source host
  Logon Type:    9 (NewCredentials)
  Account Name:  svc_backup
  ← cloned token with new credentials; no interactive session created

-- On the Domain Controller --

Event ID: 4768 — Kerberos Authentication Service
  Account Name:      svc_backup@CORP.LOCAL
  Client Address:    ::ffff:10.10.5.88   ← attacker host, not svc_backup's workstation
  Ticket Encryption: 0x17 (RC4-HMAC)    ← NTLM hash used as RC4 key; AES256 expected
  Pre-Auth Type:     2
  Result Code:       0x0 (success)       ← real TGT issued by KDC

Event ID: 4769 — Kerberos Service Ticket
  Account Name:      svc_backup@CORP.LOCAL
  Service Name:      cifs/fileserver.corp.local
  Client Address:    ::ffff:10.10.5.88   ← same attacker host; now accessing file shares

Investigation Steps

1. 1.Start on the DC: pull all Event 4768 records for the past 24 hours and filter for Ticket Encryption Type 0x17 (RC4-HMAC) in any domain that enforces AES-only Kerberos. Every result is a candidate — the account name and Client Address in each event identify who was targeted and from where.
2. 2.Verify the source IP: does the Client Address in Event 4768 match this account's known workstation? Query 4624 logon history for the account and compare the most recent Type 2 (interactive) or Type 10 (remote interactive) logon source against the 4768 source. A mismatch means the TGT was requested from a different host.
3. 3.Check Event 4624 Type 9 (NewCredentials) on the identified attacker host at the time of the 4768. This logon type is created by Mimikatz sekurlsa::pth when it spawns a process with new credentials — it's a host-side confirmation of OPtH.
4. 4.Trace the TGT to service access: find Event 4769 (service ticket requests) from the same account and Client Address following the 4768. The SPNs requested tell you which resources the attacker was targeting. cifs/ = file shares, host/ = WMI/WinRM/Task Scheduler, mssql/ = databases, http/ = web apps.
5. 5.Search Event 4688 and 4104 on the attacker's source host for Mimikatz sekurlsa::pth or Rubeus asktgt. The /ntlm: and /rc4: flags in the command line confirm OPtH. The /aes256: flag indicates Pass-the-Key (same technique using the AES session key — less detectable because AES is expected, but the source IP mismatch is still the tell).
6. 6.Determine the hash source: how did the attacker obtain the NTLM hash? Check Event 4663 (LSASS memory access), 4662 (DCSync replication GUIDs), and 4688 for credential dumping tools in the hours before the 4768. The hash acquisition event is the start of the attack chain.
7. 7.Scope lateral movement: identify every service ticket (4769) and subsequent logon (4624) generated by the OPtH TGT. Each target system may have been accessed with the victim account's full Kerberos privileges.

Common False Positives

• ◎RC4 Kerberos authentication (4768 with 0x17) is not exclusively OPtH — older systems, some printers, NAS devices, and legacy applications still negotiate RC4 for compatibility. The combination of RC4 + unexpected source IP + Type 9 logon on the source host is the definitive pattern.
• ◎Authorized penetration tests and red team engagements use sekurlsa::pth and Rubeus asktgt routinely. Confirm with your security team before escalating.
• ◎Some monitoring tools and identity products request Kerberos tickets on behalf of accounts they manage — these may appear as TGT requests from unexpected IPs. Maintain an allowlist of known identity product hosts.
• ◎What is the difference between Overpass-the-Hash and Pass-the-Key? They are the same mechanism but with different inputs: OPtH uses the NTLM hash as the RC4 Kerberos key (Ticket Encryption 0x17 in 4768); Pass-the-Key uses the AES128 or AES256 session key (Ticket Encryption 0x12 or 0x11). Pass-the-Key is harder to detect because AES is the expected encryption type — source IP anomaly is the primary signal.

Remediation

• ✓Rotate the compromised account's password immediately — this invalidates the NTLM hash used for the OPtH AS-REQ and all Kerberos tickets derived from it.
• ✓Add privileged and sensitive accounts to the Protected Users security group — members cannot authenticate with RC4; any OPtH attempt with the NTLM hash will fail (0x18 Pre-authentication failure) because the KDC will require AES. This is the strongest single control against OPtH.
• ✓Enforce AES-only Kerberos via Group Policy: 'Network security: Configure encryption types allowed for Kerberos' → enable AES128_HMAC_SHA1 and AES256_HMAC_SHA1 only, disable RC4_HMAC_MD5. This forces OPtH to require AES keys rather than the more easily obtained NTLM hash, significantly raising the bar.
• ✓Enable Credential Guard on all domain-joined workstations — it isolates LSASS in a virtualization-based security context, preventing Mimikatz sekurlsa::pth from reading hashes from LSASS memory. No hash extraction = no OPtH.
• ✓Create a SIEM rule alerting on Event 4768 with Ticket Encryption Type 0x17 (RC4) from a source IP not in your maintained allowlist of known DC IPs and legacy-requiring devices. This rule has high fidelity in AES-enforced domains.
• ✓Deploy Microsoft Defender for Identity — it baselines each account's typical TGT request source and alerts on anomalous AS-REQ patterns including OPtH and Pass-the-Key.
• ✓Eliminate the hash acquisition prerequisites: deploy LAPS for local admin accounts (unique passwords per machine — hash reuse across hosts fails), enforce least privilege (fewer accounts have hashes worth stealing), and ensure Credential Guard is deployed before OPtH reaches your environment.

Related Event IDs

Related Detection Guides

Frequently Asked Questions

What is the difference between Overpass-the-Hash and Pass-the-Hash?

Pass-the-Hash uses the NTLM hash directly in the NTLM challenge-response protocol — the attacker authenticates via NTLM (generating Event 4776 on the DC and a Type 3 NTLM logon in Event 4624). Overpass-the-Hash uses the NTLM hash as a Kerberos RC4 pre-authentication key, requesting a real TGT from the KDC (generating Event 4768 on the DC). The result is a Kerberos-based session with no NTLM traffic — useful in environments where NTLM is blocked or monitored.

If the TGT is real and issued by the KDC, why is Overpass-the-Hash detectable?

The TGT is legitimate, but the way it was requested is anomalous. Two signals survive: (1) the pre-authentication type — most modern accounts use AES256 (0x12), but OPtH with an NTLM hash uses RC4 (0x17) because the NTLM hash is the RC4 key; (2) the source IP — the TGT was requested from the attacker's host, not the account's known workstation. A legitimate TGT request from an unexpected IP combined with RC4 encryption when AES is expected is a reliable OPtH indicator even though the DC issued a real ticket.

What is Pass-the-Key and how does it relate to Overpass-the-Hash?

Pass-the-Key is the same technique using the AES128 or AES256 Kerberos session key instead of the NTLM hash. Because AES is the expected encryption type in modern domains, the resulting 4768 shows 0x12 (AES256) — which blends in with legitimate traffic. Pass-the-Key requires obtaining the AES key rather than the NTLM hash (both are in LSASS, but AES keys are less commonly targeted by credential dump recipes). The source IP mismatch is the primary detection signal when RC4 encryption is not anomalous.

Does adding an account to Protected Users stop Overpass-the-Hash?

Yes, it blocks the RC4 variant. Protected Users members cannot use RC4 for Kerberos authentication — the KDC will reject any AS-REQ using RC4 for these accounts with a pre-authentication failure (0x18). An attacker would need the AES key (Pass-the-Key) instead of the NTLM hash. Combined with Credential Guard (which prevents LSASS hash extraction), Protected Users is the strongest defense: the KDC rejects RC4 OPtH, and Credential Guard prevents hash acquisition in the first place.