How do attackers use RODC Golden Ticket?

Attackers use an RODC Golden Ticket after compromising a Read-Only Domain Controller account or its secrets to forge Kerberos tickets for identities linked to that domain controller. This can enable impersonation within the allowed scope and complicate detection. Defenders should protect RODC credentials, monitor for abnormal ticket issuance, and treat domain controller compromise as a high-severity event.

How an RODC Golden Ticket is used in practice

An rodc golden ticket is a forged Kerberos artifact built around a compromised Read-Only Domain Controller context. Once an attacker has the RODC account or its secrets, they can mint tickets that are accepted within that controller’s allowed scope, which can make the abuse look like legitimate Kerberos activity rather than a simple stolen-password event.

The practical significance is that the attacker is not trying to break Kerberos generally, but to abuse a trusted domain controller boundary. That changes the investigation: you are looking for forged ticket use, abnormal identity impersonation, and any sign that the RODC itself has become a trust anchor for wider lateral movement.

Because the technique depends on trust in the controller account and ticket path, it tends to be more durable than a single stolen session. Kerberos Security Guide is the best starting point when you need to understand how ticket forgery, delegation boundaries, and KRBTGT-adjacent abuse fit together.

What attackers gain from the abuse path

The main gain is impersonation within the scope the forged ticket can reach. That may be enough to request services, access resources, or blend in with normal Kerberos traffic while the attacker continues reconnaissance. The value to the attacker comes from turning one compromised controller relationship into authenticated activity that defenders may not immediately classify as hostile.

This is why RODC golden ticket activity is often discussed alongside other identity-forging techniques. The issue is less about a single ticket and more about the authority the attacker inherits from the compromised controller context. In an investigation, that means the question is not only “was a ticket forged?” but also “which identities and services were reachable because the trust boundary was abused?”

For broader identity-attack patterns, Identity Threat Detection and Response (ITDR) Guide gives useful context on how forged tickets, pass-the-ticket activity, and identity compromise are typically detected and handled. The State of NHI & AI Agent Breach Report 2026 is also relevant because it shows how credential and secret theft often become the first step in broader compromise chains.

How defenders should respond to suspected RODC ticket forging

The response priority is to verify whether the RODC account or its secrets were exposed, then assume the affected trust path may have been used to mint additional tickets. If the compromise is credible, treat it as a controller-level incident, not just an endpoint event, because the attacker may already have acted with valid-looking authentication material.

Defenders should review ticket issuance and service access patterns around the suspected window, looking for identities that should not have authenticated through that RODC or for unusual resource access that lines up with the forged scope. Preserve evidence before rotating credentials where possible, because once the controller trust path is changed, retrospective reconstruction gets harder.

Anthropic’s first AI-orchestrated cyber espionage campaign report is a useful reminder that attackers increasingly automate reconnaissance and credential abuse, which makes rapid containment and log preservation more important once abuse of trusted access is suspected.

Risk and Threat Considerations

The core risk is that a compromised RODC can become a trusted source of forged authentication material, which blurs the line between legitimate and malicious Kerberos activity. That can widen the blast radius beyond the initial compromise and delay detection, especially if monitoring is focused on password theft rather than ticket abuse.

Failure mechanism: If the attacker obtains the RODC account or its secrets, they can forge tickets that inherit that controller’s scope and then use those tickets to request services or impersonate linked identities.

Impact: The result is stealthier authenticated access, harder attribution, and a higher chance that the attacker can continue operating while defenders believe the traffic is normal Kerberos use.

Practitioner Guidance

What to verify: Confirm whether the RODC itself, its account material, or any associated administrative path was exposed. If you cannot prove the RODC remained intact, treat the ticketing trust chain as suspect and escalate accordingly.

Decision rule: If abnormal ticket issuance or service use aligns with the suspected window, prioritise containment and credential-trust review before assuming the issue is isolated. If there is no clear compromise evidence, still preserve logs and validate that the RODC was not used as a covert authentication source.

Practitioner takeaway: RODC Golden Ticket abuse is dangerous because it turns a domain controller trust relationship into believable authentication, so the response must focus on trust-path compromise, not just suspicious logon events.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?