Detect stealing or forging Kerberos tickets by watching for unusual ticket requests, golden or silver ticket patterns, and abnormal use of long-lived or high-privilege tickets. Investigate privilege escalation on domain controllers, credential dumping activity, and logons that bypass normal authentication paths. Reset compromised credentials, audit Kerberos service accounts, and check for ticket lifetime or delegation abuse.
How Kerberos ticket theft shows up in telemetry
Ticket theft and ticket forgery usually stand out less by one perfect signature than by patterns that do not fit the account’s normal behaviour. Look for bursts of ticket requests, unusual service ticket issuance, ticket use from hosts that do not normally authenticate that way, and tickets presented outside ordinary logon flows. Kerberos abuse often becomes visible when the attacker is trying to stay inside legitimate authentication machinery.
Forged tickets are especially important to distinguish from ordinary reuse of valid tickets. A golden or silver ticket often changes the shape of logon activity rather than creating an obvious failed-login storm, so the useful question is whether the ticket lifecycle, delegation path, and account privilege profile make sense together. If a ticket appears long-lived, overly privileged, or disconnected from the normal account history, treat it as a detection lead, not just an authentication event.
Identity Threat Detection and Response (ITDR) Guide is useful here because Kerberos abuse is often an identity attack pattern first and a malware symptom second. It helps teams connect ticket abuse, credential theft, and lateral movement into one detection and response view.
Kerberos Security Guide deepens the Kerberos-specific side of the problem, including the ticket patterns, reset actions, and authentication artefacts that matter when you are validating whether an event is normal, suspicious, or forged.
Where detection should focus first
The highest-value hunting pivots are the places where Kerberos tickets are minted, trusted, or replayed. Domain controllers, ticket-granting paths, and accounts with broad delegation rights deserve priority because abuse there can create tickets that look legitimate downstream. Credential dumping activity also matters because stolen secrets often precede ticket forging or ticket replay.
Normal authentication paths matter just as much as the attacker’s tooling. If a logon succeeds while bypassing the usual interactive, federated, or MFA-backed path, that is a strong clue that the session may have been built from an existing ticket rather than a fresh proof of identity. That is why ticket anomalies should be read alongside privilege escalation, unusual admin activity, and service account behaviour, not in isolation.
MITRE ATT&CK Enterprise Matrix helps map these observations to credential access, privilege escalation, and lateral movement techniques so analysts can turn scattered Kerberos alerts into a coherent intrusion path.
NIST SP 800-53 Rev 5 Security and Privacy Controls supports the control view of the problem, especially around authentication, auditability, and configuration discipline on the systems that issue and trust Kerberos tickets.
What to do when Kerberos abuse is suspected
Response should start with blast-radius control, not only with log review. If a forged or stolen ticket is plausible, reset or rotate the credentials that could have enabled it, and validate whether the attack touched service accounts, privileged accounts, or the KRBTGT trust chain. The point is to cut off the attacker’s ability to mint or reuse tickets while you preserve evidence.
Check for earlier compromise before you assume the ticket event is the beginning of the incident. A forged ticket is often a persistence or follow-on mechanism, which means the root cause may be credential dumping, privilege escalation, or a compromised workstation that exposed secrets earlier in the chain. Audit ticket lifetime, delegation settings, and any account that can issue or accept unusually durable authentication material.
For teams building the response playbook, the practical standard is to verify whether ticket abuse is isolated or systemic. If the same service principal, host, or delegation path appears in multiple suspicious events, broaden containment and assume the attacker may already have authenticated through more than one avenue.
Risk and Threat Considerations
Kerberos ticket theft or forgery is dangerous because it can convert one compromise into broad authenticated access without repeated password spraying or noisy login failures. Once an attacker can present a believable ticket, they may blend into normal domain activity, extend session validity, and reach sensitive services through trusted paths.
Failure mechanism: The attacker obtains credentials or ticket material, then forges, replays, or prolongs a Kerberos ticket so access appears legitimate to downstream systems and logs.
Impact: This can enable privilege escalation, lateral movement, stealthy persistence, and access to domain resources that normal authentication monitoring may not immediately flag.
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 SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1003 — OS Credential Dumping | Credential dumping often precedes Kerberos ticket theft or forgery. |
| T1550 — Use Alternate Authentication Material | Kerberos ticket replay and forgery are alternate auth material abuse. | |
| T1078 — Valid Accounts | Forged tickets let attackers act as valid domain users or services. | |
| Recommendation — Hunt for credential dumping activity that could expose Kerberos secrets. Map suspicious ticket use to alternate authentication material techniques. Correlate ticket anomalies with valid-account abuse and lateral movement. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Kerberos abuse is detected through review of authentication and ticket logs. |
| IA-5 — Authenticator Management | Response often requires rotating credentials and ticket-related secrets. | |
| AC-2 — Account Management | Kerberos service accounts and privileged accounts need tighter governance. | |
| Recommendation — Analyze Kerberos and domain controller logs for anomalous ticket behaviour. Rotate compromised credentials and review authenticator lifecycle controls. Review privileged and service accounts for excessive or stale access. | ||
Practitioner Guidance
What to verify: Confirm whether suspicious ticket use aligns with the account’s normal host, time, privilege, and delegation pattern. A single odd ticket is less important than repeated use across hosts or services that the account should not normally touch.
Decision rule: If the ticket appears long-lived, high-privilege, or detached from the normal authentication path, treat it as a potential compromise indicator and prioritize credential rotation and containment over deeper attribution work.
Practitioner takeaway: The best Kerberos detections do not look only for failed authentication, they look for authenticated behaviour that should not have been possible with that ticket, from that host, at that privilege level.