Detect it by identifying Kerberos logons that follow NTLM hash compromise or suspicious use of a user’s password material to request tickets. Look for unusual ticket-granting activity, logons from unexpected hosts, and a shift from NTLM-facing compromise to Kerberos authentication. Correlate with credential access on the source system and protect accounts with strong authentication and least privilege.
What overpass-the-hash looks like in Active Directory
Overpass-the-hash is a credential abuse pattern where an attacker uses captured password material, usually an NTLM hash, to obtain Kerberos tickets instead of using NTLM directly. The key detection problem is not “a hash exists”, but the transition from hash theft or use on one host to Kerberos activity on another, often with ticket requests that do not fit the user’s normal device, time, or access pattern.
This is why detection should focus on the authentication sequence and the source system, not just on a single failed logon. A suspicious chain usually includes local credential access, then a Kerberos ticket request, then lateral movement or access that looks legitimate because it is Kerberos-based.
For investigators, the question is whether the account’s Kerberos behavior is consistent with the way that identity normally operates. A sudden rise in ticket-granting activity, use from an unusual workstation, or service access that appears immediately after NTLM-related compromise are all stronger signals than isolated authentication noise. The Kerberos Security Guide is the best starting point when you need the broader ticketing context around this technique.
Which logon and ticket patterns matter most
The most useful telemetry is the combination of Windows logon events, Kerberos service ticket activity, and host-level evidence of credential access. On the identity side, watch for ticket requests that do not match the user’s normal geography, endpoint, or administrative role, especially when the account has no reason to be requesting new tickets at that moment. On the host side, look for evidence that the password material was obtained before the Kerberos activity began.
Ticket-granting activity is especially important because overpass-the-hash often tries to turn stolen password material into a Kerberos-authenticated session that blends into ordinary domain traffic. That means your detection logic should not stop at the presence of a valid Kerberos ticket. It should ask why the ticket was requested, from where, and whether that request follows a plausible administrative workflow.
Accounts with broader access deserve tighter scrutiny because once NTLM hash material is exposed, the attacker may be able to request tickets for multiple services without further password capture. The practical defence is to narrow where privileged credentials can be used and reduce the number of hosts from which ticket requests are acceptable. The Active Directory and Entra ID Hardening Guide is useful for the privileged-access side of that problem, and the Tiered Administration and Enterprise Access Model Guide helps when you need to separate admin activity from everyday user workstations.
How to separate overpass-the-hash from ordinary Kerberos use
Good differentiation depends on context. A legitimate Kerberos logon usually comes from a known device, follows a predictable access path, and aligns with the account’s role. Overpass-the-hash is more suspicious when Kerberos appears only after prior credential access on the source system, when the user never normally authenticates from that host, or when the account starts accessing services that are unusually sensitive for its profile.
Correlating across endpoints matters because the compromise often begins outside the domain controller. If the source machine shows signs of local credential theft, memory scraping, or suspicious administrative tooling, and then the same account begins making new ticket requests, the combined evidence is much stronger than any one event alone. A useful comparison is whether the account’s behaviour changed at the same time as the compromise path changed.
That is also why relying only on NTLM detections is insufficient. Overpass-the-hash is attractive precisely because the attacker can move from NTLM compromise into Kerberos operations that may look normal unless you compare identity, host, and timing together. If you want a broader operational lens on active directory attack patterns, the Top 10 Active Directory Security Risks and the Password Spraying and Credential Stuffing Defence Guide are good complements because they frame how credential compromise often precedes downstream ticket abuse.
Risk and Threat Considerations
Overpass-the-hash matters because a stolen NTLM hash can become a usable ticket request path without the attacker ever learning the cleartext password. That creates a fast transition from local credential compromise to domain-wide access opportunities, especially where privileged accounts, reused credentials, or weak workstation separation exist.
Failure mechanism: The attacker captures password material on a source host, uses it to obtain Kerberos tickets, and then operates through apparently valid authentication flows that can evade controls focused only on failed passwords or NTLM misuse.
Impact: The result can be lateral movement, access to multiple services under a legitimate identity, and delayed detection because the activity blends into normal Kerberos traffic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1550.002 — Pass the Hash | Covers the hash-based credential abuse path behind overpass-the-hash. |
| T1558.003 — Kerberoasting | Kerberos ticket abuse context helps distinguish ticket attacks and related detection paths. | |
| Recommendation — Correlate hash compromise with unusual Kerberos ticket use and lateral movement. Inspect anomalous ticket requests and validate service access against normal behaviour. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potentially adverse events | Detection of unusual authentication flows depends on continuous monitoring. |
| PR.AA-05 — Access permissions, entitlements, and authorizations are managed | Least privilege and constrained access reduce the blast radius of credential abuse. | |
| Recommendation — Monitor Kerberos and endpoint events for ticket activity that departs from baseline. Restrict privileged access paths so stolen credentials cannot reach broad domain resources. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Log correlation is central to spotting abnormal ticketing and host activity. |
| IA-2 — Identification and Authentication (Organizational Users) | The attack abuses organizational user authentication material. | |
| Recommendation — Review authentication and endpoint logs together to surface cross-host abuse patterns. Require strong authentication controls for user identities that can reach domain resources. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account governance and lifecycle controls reduce misuse of compromised identities. |
| Recommendation — Limit account scope and review privileged access to shrink the impact of hash theft. | ||
Practitioner Guidance
What to verify: Confirm whether the account’s Kerberos requests originated from a device that normally handles that identity, and check whether host evidence shows earlier credential access before the ticket activity. If the source system is suspicious but the ticket itself looks valid, treat that as a compromise indicator rather than reassurance.
Decision rule: If Kerberos activity begins immediately after NTLM hash compromise or local credential theft, prioritise containment of the source host and credential rotation before you spend time tuning around the individual ticket event. The important judgement is whether the identity has been reused, not whether one event looks malformed.
What good looks like: High-value accounts authenticate only from expected systems, unusual ticket requests generate alerts, and workstation compromise cannot easily become domain access. The strongest detections combine endpoint telemetry, directory authentication logs, and identity baselines rather than relying on a single event source.
Practitioner takeaway: Overpass-the-hash detection is strongest when you treat it as an end-to-end identity abuse chain, not a single Kerberos anomaly. The real signal is the handoff from stolen password material on one host to legitimate-looking ticket use on another.
Related resources from NHI Mgmt Group
- How should security teams detect Active Directory attacks that do not leave normal event log traces?
- How do you detect a new domain trust being created in Active Directory?
- How do you detect Active Directory enumeration using PowerShell cmdlets?
- How do you detect Active Directory enumeration with AdFind?