How do you detect pass-the-ticket and overpass-the-hash?

Detect overpass-the-hash by alerting on Event ID 4768 TGT requests that use RC4 (encryption type 0x17) for accounts that normally receive AES tickets, because an NT hash can only derive an RC4 key. Detect pass-the-ticket by correlating Kerberos type 3 logons (Event 4624) against domain controller 4768 and 4769 events: a logon from a source that never requested a ticket for that account suggests an imported ticket. A 4769 or Kerberos logon with no earlier 4768 anywhere points at a forged ticket, so collect from every domain controller. Enforcing AES and disabling RC4 where possible removes most legitimate downgrade noise.

Detecting Pass-the-Ticket and Overpass-the-Hash: Kerberos Anomalies

Pass-the-ticket injects a stolen TGT or service ticket into another session; overpass-the-hash converts an NT hash or AES key into a fresh TGT. Both produce Kerberos events on the domain controller and the target that do not line up the way an honest logon does. That mismatch, and the encryption type of the request, are what you detect.

Signals at a Glance

Signal	Where	ATT&CK
TGT request (4768) using RC4 (0x17) for an account that supports AES	DC Event 4768	T1550.003
Service ticket (4769) with RC4 encryption in an AES-enabled domain	DC Event 4769	T1558
Type 3 Kerberos logon from a source with no matching 4768/4769 for that account	Event 4624 + DC events	T1550.003
Ticket lifetime beyond policy or used long after issue	Event 4768/4769, 4624	T1558.001
Logon type 9 with seclogo on the source host before the Kerberos activity	Event 4624 type 9	T1550.002

Encryption Downgrade and Missing Requests

Modern clients request AES tickets. Overpass-the-hash with an NT hash can only build an RC4 key, so a 4768 with TicketEncryptionType 0x17 for an account configured for AES is a strong lead. Kerberoasting also produces RC4 requests, so separate the two by the requester and the pattern:

// Sentinel (KQL) - RC4 TGT requests for accounts that normally receive AES tickets
let aes_users = SecurityEvent
| where EventID == 4768 and TimeGenerated between (ago(14d) .. ago(1d))
| where TicketEncryptionType in ("0x12", "0x11")
| distinct TargetUserName;
SecurityEvent
| where EventID == 4768 and TimeGenerated > ago(1d)
| where TicketEncryptionType == "0x17"
| where TargetUserName in (aes_users) and TargetUserName !endswith "$"
| project TimeGenerated, Computer, TargetUserName, IpAddress, TicketEncryptionType, PreAuthType
// tune/validate: legacy systems and service accounts without AES keys will appear; allowlist them.

For pass-the-ticket proper, compare where a ticket was issued with where it is used. A type 3 logon with the Kerberos package from a source IP that never requested a TGT or service ticket for that account is a ticket imported from elsewhere:

// Sentinel (KQL) - Kerberos network logon from a source with no ticket request in the last 10 hours
let tickets = SecurityEvent
| where EventID in (4768, 4769) and TimeGenerated > ago(10h)
| extend Src = replace_string(tostring(IpAddress), "::ffff:", "")
| distinct TargetUserName, Src;
SecurityEvent
| where EventID == 4624 and LogonType == 3 and AuthenticationPackageName == "Kerberos"
| where TargetUserName !endswith "$"
| extend Src = replace_string(tostring(IpAddress), "::ffff:", "")
| join kind=leftanti tickets on TargetUserName, Src
| project TimeGenerated, Computer, TargetUserName, Src, LogonProcessName
// tune/validate: NAT, load balancers and delegation (S4U) change the apparent source address.

Forged Tickets and Operational Checks

A 4769 or a Kerberos 4624 with no earlier 4768 for that account anywhere on the domain controllers points at a forged TGT (golden ticket, T1558.001). Ingest events from every domain controller or the join will give false alerts.
Check TGT lifetime. A ticket presented after the maximum lifetime your policy sets, or one with an account name that does not exist, is a forged-ticket indicator.
Enforce AES and disable RC4 for accounts that support it. That removes the downgrade ambiguity and makes the 0x17 rule precise.
Rotate the KRBTGT account password twice after any suspected forged-ticket activity, and re-verify with the same queries.

Vetted sources

Use the SigmaHQ Kerberos and overpass-the-hash rules, Elastic and Splunk ESCU Kerberos content and MITRE CAR analytics for ticket abuse. Microsoft documents the Kerberos events and encryption-type values, and Atomic Red Team provides test cases. Baseline your own environment: service accounts, trusts and Linux Kerberos clients legitimately use RC4.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Encryption Downgrade and Missing Requests

Forged Tickets and Operational Checks

Build Detections That Fire

Lateral Movement Detection

Detection Hub

Pass-the-Hash Detection

Lateral Movement Graphing