Steal or Forge Kerberos Tickets

How Kerberos ticket theft and forgery works

kerberos tickets are the proof objects that let a user or service prove authentication after the initial logon exchange. When an attacker steals a valid ticket, they can replay that proof until it expires; when they forge one, they are attempting to manufacture trust without going through normal credential verification.

This matters because the ticket, not the password, becomes the thing that is accepted by downstream services. In practice, compromise of a ticket-granting path can let an attacker impersonate a high-value account, move laterally, and blend in with ordinary authentication traffic.

Why forged or stolen tickets are dangerous

Kerberos is designed to reduce repeated password exposure, but that also means ticket abuse can bypass the most visible part of authentication. If a ticket is valid to the service, the service may not know whether it was issued legitimately, stolen from memory, or forged offline.

That makes ticket abuse especially dangerous in environments with broad trust relationships, long ticket lifetimes, or service accounts that can reach many systems. A single compromised ticket can become a durable access path when monitoring is weak or when services do not validate context carefully.

Defenders should treat this as an identity abuse problem as much as a protocol problem, because the attacker is leveraging accepted authentication state rather than breaking a password directly. NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful control baseline for identity, audit, and access-monitoring expectations in this kind of environment.

How organisations check exposure and contain the blast radius

Exposure begins with knowing which systems rely on Kerberos, which accounts can obtain tickets, and where those tickets are cached or reused. Asset inventory and account inventory both matter, because unmanaged hosts, old domain trusts, and high-privilege service principals often create the easiest path to ticket abuse.

Teams should also check whether critical services are reachable in ways that make stolen tickets immediately valuable, especially if the environment has limited segmentation or weak service-to-service authorization. NIST SP 800-207 Zero Trust Architecture is useful here because it reinforces continuous verification and reduces the assumption that an already-authenticated ticket should be trusted everywhere.

For environments that expose ticket-bearing services through modern integrations or APIs, it is worth validating that access paths are not broader than intended. OWASP API Security Top 10 is relevant where those integrations become an easy lateral path once a forged or stolen ticket is accepted.

Detection, response, and post-compromise review

Detection usually depends on spotting patterns that do not fit normal Kerberos behavior, such as unusual ticket use, improbable location changes, abnormal service access, or long-lived activity that keeps going after the original session should have aged out. Review should focus on where the ticket was issued, where it was presented, and whether the resulting access aligns with the account’s normal role.

When compromise is suspected, responders should assume that the attacker may have used the ticket to obtain additional access, not just a single resource hit. MITRE ATT&CK Enterprise Matrix is helpful for mapping this kind of activity to credential access, privilege escalation, and lateral movement behaviors so investigations stay focused on the full attack chain.

If the incident involves weak credential hygiene or long-lived secrets supporting related services, NIST SP 800-57 Key Management can help anchor the review of cryptographic lifecycle and rotation expectations around the material that underpins the trust relationship.

Practitioner Guidance

Why practitioners should care: Kerberos ticket abuse often bypasses the normal “password reset equals safety” instinct, so incident response has to focus on session state, service trust, and privilege pathways as well as on the original account. Treat a suspicious ticket as a live access artifact, not just an authentication record.

What to watch for: Look for ticket use that is out of pattern for the account, service access that should not be possible from that host or time window, and evidence that a compromised ticket was reused to reach other systems. If the account is privileged or long-lived, assume the blast radius may extend well beyond the first alert.

Practitioner takeaway: The fastest way to reduce risk is to tighten where tickets can be used, how long they remain useful, and how quickly you can prove whether a ticket presented to a service was expected.

Related resources from NHI Mgmt Group

• Why do stolen Kerberos tickets create such a difficult detection problem?
• What happens after an attacker can issue Kerberos service tickets on behalf of a target user?
• How should security teams reduce the risk of forged cloud tickets in Azure AD Kerberos deployments?
• Why do stolen NTLM hashes and Kerberos tickets create such high lateral movement risk in enterprise environments?