What does RODC Golden Ticket look like in a real intrusion?

How RODC Golden Ticket abuse shows up in the Kerberos flow

The real-world signal is usually not “one magic ticket,” but a Kerberos pattern that no longer looks tied to a normal user logon path. A forged ticket can be accepted because the attacker is working from data associated with a read-only domain controller, so the resulting access may look locally valid even when the authentication journey is not.

That is why defenders should think in terms of ticket issuance, ticket use, and where the access comes from. The abuse may surface as unusual ticket-granting activity, privilege appearing from an unexpected host, or access that survives ordinary password changes because the trust material being abused is not the same as a single user password.

When you review the event chain, focus on whether the observed Kerberos behavior lines up with the account, host, and domain controller that should have produced it. The operational question is not just “was a ticket seen,” but “does this ticket fit the identity path that should have existed?”

What defenders should check first when the pattern looks off

Start with exposure, not theory. Confirm whether the environment has read-only domain controllers, whether their secrets are protected appropriately, and whether the suspicious activity touches systems that should never need direct interaction with that trust material.

Then verify the access path. If privileged activity is appearing from hosts that do not normally administer the domain, treat that as a correlation problem worth investigating, especially when the ticket use does not match routine admin behavior or expected maintenance windows.

For broader context on ticket abuse, the Kerberos Security Guide covers the ticket abuse patterns, reset logic, and detection points that matter when forged tickets are part of the intrusion chain.

Why resets and normal cleanup may not be enough

RODC-related ticket abuse is dangerous because it can persist after the most obvious remediation steps. Password resets help against many compromises, but if the attacker is relying on forged ticket material or on trust data already exposed from the domain controller side, the visible symptom can continue until the underlying Kerberos trust issue is addressed.

That means you should look for earlier compromise as well as current abuse. Search for ticket-granting anomalies, repeated privileged service use, lateral movement that follows the same trust pattern, and any signs that the attacker has maintained access through the same Kerberos path even after account-level cleanup.

The right detection posture is identity-centric. The Identity Threat Detection and Response (ITDR) Guide is useful here because it frames the response around identity abuse, persistence, and the differences between credential compromise and ticket-based abuse.

Risk and Threat Considerations

rodc golden ticket abuse is high impact because it can turn a domain trust component into durable unauthorized access. Once forged Kerberos material is accepted, the attacker may blend in with legitimate ticket activity while retaining access that is hard to distinguish from normal administration.

Failure mechanism: The attacker abuses trust material associated with the read-only domain controller to mint or present tickets that the domain accepts, bypassing ordinary authentication expectations and masking the source of access.

Impact: Privileged access can persist, spread laterally, and survive routine account resets, making domain-wide compromise harder to contain and extending the incident timeline.

Practitioner Guidance

What to verify: Confirm whether the suspicious ticket use maps to expected Kerberos issuance, expected source hosts, and expected administrative activity. If the access path looks “valid” but the context does not, treat it as compromise until proven otherwise.

Decision rule: If you see privileged access that depends on RODC trust material or odd ticket-granting behavior, prioritise containment of the domain trust path and evidence preservation before assuming a simple password reset is sufficient.

What good looks like: You can explain which tickets were issued, from where, for what purpose, and why they should have existed. If you cannot reconstruct that chain cleanly, your response should assume the attacker had a durable Kerberos foothold.

Practitioner takeaway: The key judgement is to separate user-password compromise from Kerberos trust compromise, because RODC golden ticket activity is often about the latter, and that changes both containment order and confidence in remediation.

Related resources from NHI Mgmt Group

• What does Fast-Flux DNS look like in a real intrusion?
• What does HTTP Desync Attack look like in a real intrusion?
• What does timeroasting look like in a real intrusion?
• What does ReadLAPSPassword look like in a real intrusion?