Forest root compromise via golden ticket SID history abuse

At a glance

What this is: This is a forest-root compromise walkthrough showing how a forged golden ticket with SID history can turn child-domain access into full forest control.

Why it matters: It matters because identity teams have to govern trust boundaries, Kerberos privilege, and tiered administration as one attack surface across NHI and human admin paths.

👉 Read FireCompass's walkthrough of forest root compromise via golden ticket SID history abuse

Context

A golden ticket with SID history is a Kerberos abuse pattern that lets an attacker combine stolen domain ticket material with a privileged SID from another trust boundary. In Active Directory terms, the risk is not just credential theft, but the ability to make a ticket appear valid in a domain or forest where the attacker did not earn access.

The governance failure here is treating a domain as the security boundary when the forest is the real boundary. For IAM and PAM teams, that means trust configuration, replication rights, and administrative tiering have to be evaluated together rather than as isolated controls.

This attack path is typical of environments where identity controls are tested per domain or per host, but not across the full trust chain.

Key questions

Q: What breaks when SID filtering is not enforced on an Active Directory trust?

A: A forged Kerberos ticket can carry a privileged SID across the trust boundary and be accepted in a higher-trust domain. That turns a child-domain compromise into forest-wide authority. The control failure is not just misconfiguration. It is the collapse of the boundary that should strip unauthorized identity claims before they reach the root.

Q: Why do golden ticket attacks become more severe when SID history is injected?

A: SID history lets the attacker claim membership in groups that belong to another domain, so the forged ticket does more than impersonate an account. It imports authority. That widens the blast radius from one domain to the trust chain, especially when the receiving domain does not quarantine the extra SID.

Q: How should teams detect forest-wide risk after a child-domain compromise?

A: Look for replication rights abuse, unusual ticket forgery patterns, and administrative actions that cross from child domains into the forest root. The key signal is not one alert, but a sequence that combines credential extraction, forged Kerberos use, and access to root-level directory objects.

Q: Should organisations treat forest-root administration differently from standard domain administration?

A: Yes. Forest-root administration needs its own tier, its own credentials, and its own recovery plan because compromise at that level changes the recovery problem entirely. If root control depends on the same paths as child-domain administration, the trust model is already too flat to contain a cross-domain attack.

Technical breakdown

How a golden ticket becomes forest-wide access

A golden ticket is forged from a domain's krbtgt hash, which allows the attacker to mint Kerberos ticket-granting tickets offline. SID history injection then adds an extra privileged SID into the ticket, so the token claims membership in a group from another domain or forest context. If the trust relationship does not strip that SID, the directory service can accept the forged authority as legitimate. The result is not just domain impersonation, but trust-boundary abuse that can cross into the forest root.

Practical implication: validate trust quarantine and SID filtering on every inter-domain trust, not just local domain hardening.

Why replication rights and krbtgt access are decisive

Once an attacker has replication privileges, DCSync lets them retrieve the krbtgt hash without needing interactive access to a domain controller. That hash is the cryptographic anchor for ticket forgery in the domain, which means compromise of a single administrative path can become durable authentication abuse. In a forest context, the problem compounds when the attacker can later present the forged ticket to another domain controller that trusts the injected SID. This is why credential material, not just endpoint compromise, defines the blast radius.

Practical implication: restrict replication rights aggressively and monitor for DCSync-style access as a high-severity identity event.

Why forest-root privilege is a different class of failure

Forest-root compromise is not merely a bigger child-domain compromise. It means the attacker has crossed the directory's highest administrative plane and can now dump the root NTDS database, extract the root krbtgt hash, and forge tickets for any account in the forest. At that point, recovery depends on coordinated krbtgt rotation and administrative separation that prevents child-domain admins from reaching forest-root authority. The technical failure is a broken trust model, not a single bad credential.

Practical implication: treat forest-root credentials as a separate protection domain with tiered administration and dedicated recovery procedures.

Threat narrative

Attacker objective: The attacker wanted to convert child-domain administrative access into forest-root dominance and persistent control over every credential in the directory.

1. Entry began with domain-admin-equivalent access already present in a child domain, giving the attacker a foothold inside the directory trust chain.
2. Escalation occurred when the attacker used DCSync to obtain the child domain's krbtgt hash and forged a golden ticket with the forest-root Enterprise Admins SID injected as extra-SID.
3. Impact followed when SID filtering was not enforced, the forest root honored the injected SID, and the attacker dumped the root NTDS database to gain full forest control.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Domain boundaries are not security boundaries in Active Directory. The article shows that a child-domain compromise can become a forest compromise when trust filtering is weak. That is a governance failure, not just a technical bug, because the security programme has misidentified the real boundary of control. Practitioners should evaluate the forest as the unit of trust, not the domain.

SID filtering is the missing control that keeps forged identity claims from crossing trust lines. The attack works because an extra SID survives the trust boundary and is treated as authoritative. That means identity control validation must include trust-quarantine verification, not just password, ticket, or group hardening. The practitioner takeaway is that inter-domain trust settings are part of core identity governance.

Replication rights remain one of the most dangerous forms of standing privilege in Windows estates. DCSync turns administrative authority into credential extraction authority, which makes krbtgt protection a foundational NHI and PAM concern. The attack chain proves that privileged directory replication and ticket forgery are inseparable in incident analysis. Teams should treat replication access as high-risk administrative exposure.

Forest-root compromise creates identity blast radius, not merely privilege escalation. Once root NTDS data is dumped, recovery extends beyond one domain and becomes a forest-wide trust reset problem. The practical consequence is that access segmentation, tiered administration, and krbtgt recovery playbooks need to be designed around blast radius, not only around least privilege at provisioning time.

Forest-root control depends on an administrative model that assumes compromise stays local. That assumption fails when a child-domain attacker can inject identity claims into the root trust path. The implication is that security teams must rethink how authority is separated across domains, because the old model does not survive cross-domain token forgery.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Our research also shows that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader control lens, see Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and privilege issues that make identity chains harder to contain.

What this signals

Forest-root compromise is a blast-radius problem, not just an access problem. Security programmes that still report identity risk per domain can miss the sequence that matters most: replication rights, ticket forgery, and trust acceptance across the forest. That is why the right operating model is closer to attack-path validation than to isolated control testing, a point reinforced by the forest-level risk patterns documented in the 52 NHI breaches Report.

Standing privilege remains the structural weakness that turns directory access into directory control. The lesson for IAM and PAM teams is to assess whether admin paths can cross trust lines before recovery or certification cycles ever see them. For control mapping, the NIST SP 800-53 Rev 5 Security and Privacy Controls and Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs provide the right lens for privilege management and offboarding discipline.

Identity programmes should now assume that trust boundaries will be tested as part of the attack path. The implication is that forest design, admin tiering, and recovery planning need to be reviewed together, not as separate workstreams. If your programme can only explain who has access, but not how that access could cross a trust boundary, the model is incomplete.

For practitioners

• Enforce SID filtering on every inter-domain trust Validate that trust quarantine is enabled and tested, then document exceptions with compensating controls. Recheck after forest changes or migrations, because a trust that is safe on paper can still accept injected group SIDs in practice.
• Reduce and monitor replication privileges Treat DCSync-capable rights as a privileged exception, not a routine admin entitlement. Pair access review with continuous detection for replication API use and investigate any account outside your tiered admin model.
• Separate forest-root administration from child-domain administration Keep forest-root credentials in a dedicated administrative tier and remove routine operational paths from child-domain admins to the root. This limits how far a compromised child domain can travel before it meets a hard boundary.
• Test krbtgt recovery before you need it Build and rehearse the double-rotation process for krbtgt in both the child domain and the forest root, including dependency mapping and service impact checks. Recovery is a directory exercise, not a single-server fix.
• Use attack-path validation instead of isolated control checks Model the full sequence from child-domain foothold to root ticket abuse, then verify where the chain breaks. The useful question is whether the attack path survives across domains, not whether each control passes in isolation.

Key takeaways

• This attack worked because a child-domain foothold was able to borrow trust at the forest level and turn Kerberos authority into root compromise.
• The evidence is the full forest takeover path, ending in a dumped root NTDS database and persistent control over every account in the environment.
• SID filtering, replication-rights restriction, and tiered forest-root administration are the controls that would have broken the chain early.

Key terms

• Golden Ticket: A Golden Ticket is a forged Kerberos ticket created from stolen domain-level cryptographic material. It gives the attacker durable access that can survive ordinary account resets, which makes it a persistence mechanism inside the identity layer.
• SID History Injection: SID History injection is an Active Directory attack where an attacker adds unauthorized security identifiers to a user or service account. The goal is to make that account inherit access linked to a privileged group or older domain identity, enabling escalation, persistence, and stealthy access to resources.
• SID Filtering: SID filtering is a trust control that removes foreign security identifiers from an access token when accounts cross forest boundaries. It helps prevent attackers from abusing SIDHistory or other imported identifiers to gain unauthorized access in a trusting forest. It should be enabled unless an active migration or consolidation requires temporary exceptions.
• DCSync: DCSync is an Active Directory replication abuse technique that requests credential data from a domain controller using replication rights. It matters because the attacker does not need to crack passwords directly once replication permissions have been obtained.

What's in the full article

FireCompass's full blog covers the operational detail this post intentionally leaves for the source:

• The exact Windows trust setting and command sequence used to enable SID quarantine across the inter-domain trust.
• The step-by-step offensive workflow for extracting krbtgt material and forging the ticket with the injected SID.
• The recovery sequence for double-rotating krbtgt in both domains without breaking directory operations.
• The attack-path diagram and root-cause discussion that show why isolated controls miss forest-wide compromise.

👉 FireCompass's full post covers the attack chain, trust failure, and krbtgt recovery steps in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.