What should incident responders do when they suspect a forged Kerberos ticket is being used on a domain?

Incident responders should treat suspected ticket forgery as a credential compromise problem, not just a single malformed ticket event. The response should focus on identifying how the attacker obtained the KRBTGT key or equivalent access, then assessing related lateral movement and unauthorized share access. Because forged tickets can resemble normal activity, responders need broad identity and network evidence.

How forged Kerberos tickets change the incident response problem

Suspected ticket forgery should be handled as an identity compromise with potential domain-wide impact, not as an isolated authentication anomaly. The practical question is whether the attacker obtained the KRBTGT key, another signing path, or enough privileged access to mint believable tickets. That changes the response from ticket cleanup to credential and trust recovery.

A forged ticket can preserve the normal shape of Kerberos logons, which means responders must look beyond the ticket itself and reconstruct the attacker’s path. Focus on what accounts were used, which systems accepted the ticket, and whether the activity aligns with lateral movement, remote service use, or share access that should not have been possible.

What evidence should responders collect first?

The first task is to preserve enough evidence to determine whether the forged ticket was used for access, privilege escalation, or persistence. That means collecting domain controller authentication records, host telemetry from likely pivot points, and network evidence that shows where the ticket was presented and what resources were touched. If the ticket was forged from a stolen key, the surrounding activity usually reveals the real compromise boundary.

Responders should correlate authentication events with host logons, administrative actions, and file or share access patterns. A forged ticket often becomes obvious only when the same principal appears to authenticate across systems in a way that does not match its normal behavior, or when access succeeds without the upstream controls that would normally be expected.

Because the ticket can be valid-looking, focus on scope before confidence. Determine whether the issue is limited to one compromised account, a service account path, or a broader domain trust problem that could require resetting Kerberos-related secrets and invalidating all tickets issued from the compromised key material.

What recovery actions matter most after suspicion is raised?

Once suspicion is credible, responders should assume the attacker may have durable domain access until proven otherwise. The recovery sequence should prioritize containment of the affected accounts and hosts, validation of privileged access paths, and assessment of whether additional forged tickets could still be minted with the same compromise material.

The response should also test for secondary abuse: unauthorized share access, remote execution, delegation abuse, and follow-on use of the same credentials on other systems. A forged ticket is often only the access vehicle; the operational damage usually comes from what the attacker does after the first successful use.

If the attacker likely obtained the KRBTGT key or an equivalent signing capability, responders need a coordinated reset plan with change control, service impact awareness, and validation that old tickets are no longer trusted. The recovery effort is as much about restoring trust in the domain as it is about removing the initial foothold.

Risk and Threat Considerations

Forged Kerberos tickets are dangerous because they can blend into normal domain activity while bypassing the account protections that responders usually rely on. The main risk is not the ticket artifact itself, but the possibility that an attacker can reuse domain trust to move laterally, impersonate legitimate users, and reach sensitive shares or services without obvious password abuse.

Failure mechanism: Attackers who gain signing material or equivalent privileged access can mint tickets that satisfy Kerberos validation and then reuse them across systems until the trust chain is reset or the compromise path is removed.

Impact: The likely impact is broad unauthorized access, hidden lateral movement, and extended dwell time, especially if responders focus only on the observed ticket rather than the upstream credential compromise and downstream access that it enabled.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address 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	T1558.001 — Golden Ticket	Forged Kerberos tickets are a core ATT&CK credential-access and persistence pattern.
Recommendation — Map suspected forged-ticket activity to Golden Ticket tradecraft and hunt for prior credential theft.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	KRBTGT and ticket-signing material are authenticators whose lifecycle and rotation drive recovery.
	AU-6 — Audit Review, Analysis, and Reporting	Response depends on correlating domain, host, and network logs to confirm ticket abuse.
	AC-6 — Least Privilege	Forged tickets often succeed by abusing excessive privilege and lateral access paths.
Recommendation — Rotate and invalidate compromised Kerberos authenticators under IA-5. Correlate authentication and access logs to reconstruct the ticket-forgery path. Review and reduce privileged access paths that could be abused by forged tickets.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Ticket forgery typically implies theft of signing or credential material.
	NHI-05 — Overprivileged NHI	Credential abuse becomes more damaging when the compromised principal has excessive rights.
Recommendation — Search for leaked signing material and rotate any exposed secrets immediately. Audit and reduce excessive privileges on service and machine accounts.

Practitioner Guidance

What to verify: Confirm whether the suspected ticket was accepted across multiple hosts, whether the account involved had an unusual privilege pattern, and whether access lines up with expected authentication behavior for that principal. If the evidence is only a single suspicious log entry, treat the case as unconfirmed until you can connect it to host and network activity.

Decision rule: If the indicators point to forged-ticket use with privileged or domain-wide reach, escalate immediately to domain trust recovery planning rather than waiting for proof of every downstream action. If the activity is confined to one account and one system, containment can be narrower, but the KRBTGT compromise question still has to be answered.

Practitioner takeaway: The responder’s job is to determine whether Kerberos trust itself has been compromised; if it has, the response must move from event handling to credential, privilege, and domain recovery.