Exploiting Parent-Child Domain Trusts
In the world of Active Directory, trust relationships are the glue that holds a forest together. But what if that trust could be turned against itself? Welcome to one of the most devastating attack paths in modern cybersecurity: child-to-parent domain trust exploitation. This technique transforms a seemingly contained breach in a subsidiary domain into a forest-wide catastrophe, elevating an attacker from Domain Administrator to the almighty Enterprise Administrator in a matter of minutes.
If you've ever wondered how a compromise in what appears to be a less critical child domain can lead to complete organizational takeover, you're about to discover the dark side of Active Directory's trust architecture. This guide will walk you through the mechanics, methodology, and implications of this powerful attack vector that every red teamer should master and every blue teamer should fear.
Understanding the Trust Relationship: The Foundation of the Attack
Active Directory forests are built on a foundation of trust, and nowhere is this more evident than in the automatic, bidirectional trust relationships that exist between parent and child domains. When an organization creates a child domain like internal.company.com under a parent domain company.com, Active Directory automatically establishes a two-way, transitive trust between them.
This trust relationship serves legitimate business purposes, enabling seamless authentication and resource sharing across the forest. Users in the child domain can access resources in the parent domain, and vice versa, without requiring separate credentials. Domain controllers in both domains can validate authentication requests and honor Kerberos tickets issued by their trusted counterparts.
However, this architectural design creates an inherent security vulnerability. The bidirectional nature of the trust means that a compromise in the child domain doesn't just affect that domain—it creates a direct pathway to the parent domain and, by extension, the entire forest. The trust relationship becomes a highway that attackers can exploit to escalate their privileges from the child domain's Domain Administrator level to the parent domain's Enterprise Administrator level.
The end goal of this lab is a privilege escalation from DA on a child domain to EA on a root domain. - ired.team
The Golden Ticket: Your Key to the Kingdom
At the heart of this attack lies one of the most powerful techniques in the Active Directory attacker's arsenal: the Golden Ticket. To understand why this attack is so devastating, we need to dive into the mechanics of Kerberos authentication and the role of the Key Distribution Center (KDC).
In every Active Directory domain, there exists a special account called krbtgt (Kerberos Ticket Granting Ticket). This account serves as the KDC service account and holds the cryptographic keys used to encrypt and sign all Kerberos Ticket-Granting Tickets (TGTs) issued within the domain. When a user authenticates to the domain, they receive a TGT signed by the krbtgt account's secret key.
A Golden Ticket attack involves forging a TGT by using the krbtgt account's password hash. With this hash, an attacker can create a completely fabricated TGT that appears legitimate to any service in the domain. The forged ticket can claim to represent any user, including non-existent users, and can include any group memberships the attacker desires.
The real magic happens when we combine Golden Ticket creation with SID History injection. SID History is a legitimate Active Directory attribute designed to maintain access permissions when users are migrated between domains. In our attack scenario, we abuse SID History by injecting the SID of the parent domain's Enterprise Admins group into our forged Golden Ticket.
The Attack Path: A Step-by-Step Journey to Enterprise Admin
Step 1: Enumerate the Trust Relationship
Every successful attack begins with reconnaissance. Your first task is to confirm the existence and nature of the trust relationship between your compromised child domain and the target parent domain.
nltest /domain_trustsThis command will display all trust relationships for the current domain, showing both incoming and outgoing trusts along with their types and attributes. Look for entries indicating a bidirectional trust with the parent domain.
For more detailed information, use PowerShell:
Get-ADTrust -Filter *Step 2: Extract the Child Domain's KRBTGT Hash
With the trust relationship confirmed, your next objective is to extract the cryptographic material necessary for Golden Ticket creation. The krbtgt account's password hash serves as the master key for all Kerberos operations within the domain.
Execute the following Mimikatz command to perform the DCSync attack:
mimikatz # lsadump::dcsync /domain:internal.company.com /user:krbtgtThe output will contain the NTLM hash of the krbtgt account as a 32-character hexadecimal string. Document this hash carefully, as it will be required for the Golden Ticket creation process.
Step 3: Obtain the Parent Domain's Enterprise Admins SID
The next critical piece of information you need is the Security Identifier (SID) of the Enterprise Admins group in the parent domain. This SID will be injected into your Golden Ticket's SID History attribute.
PowerView provides an elegant solution:
Get-NetGroup -Domain company.com -GroupName "Enterprise Admins" | Select-Object -ExpandProperty SIDThe Enterprise Admins group SID will follow the standard format: S-1-5-21-<domain_identifier>-519. The RID of 519 is consistent across all Active Directory forests for the Enterprise Admins group.
Step 4: Forge the Golden Ticket with SID History Injection
Now comes the moment of truth—creating the Golden Ticket that will serve as your passport to Enterprise Administrator privileges. The Mimikatz command for Golden Ticket creation with SID History injection is:
mimikatz # kerberos::golden /user:Administrator /domain:internal.company.com /sid:S-1-5-21-1234567890-1234567890-1234567890 /krbtgt:a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6 /sids:S-1-5-21-0987654321-0987654321-0987654321-519 /pttParameter breakdown:
/user:Administrator- The username that your forged ticket will claim to represent/domain:internal.company.com- The exact name of your child domain/sid:S-1-5-21-1234567890-1234567890-1234567890- The SID of your child domain/krbtgt:a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6- The NTLM hash from Step 2/sids:S-1-5-21-0987654321-0987654321-0987654321-519- The parent domain's Enterprise Admins SID/ptt- Pass-the-ticket flag for automatic injection
Step 5: Verify Parent Domain Access
With your Golden Ticket loaded into memory, test whether your privilege escalation was successful:
dir \\parent-dc.company.com\C$If the command executes successfully and displays the contents of the C: drive, congratulations—you've successfully escalated your privileges to Enterprise Administrator level in the parent domain.
Attack Flow Summary: The Complete Picture
| Phase | Action | Primary Tool | Expected Outcome | Time Estimate |
|---|---|---|---|---|
| 1 | Enumerate domain trusts | nltest, PowerShell | Confirm bidirectional trust with parent | 2-5 minutes |
| 2 | Extract child KRBTGT hash | Mimikatz DCSync | Obtain encryption key for ticket forgery | 1-3 minutes |
| 3 | Enumerate parent EA SID | PowerView, PowerShell | Identify target privilege group SID | 2-5 minutes |
| 4 | Forge golden ticket | Mimikatz | Create ticket with elevated privileges | 1-2 minutes |
| 5 | Access parent domain | Windows commands | Verify Enterprise Admin access | 1-2 minutes |
The entire attack can be completed in under 15 minutes once Domain Administrator access is obtained in the child domain.
Why This Matters: The Real-World Impact
The child-to-parent domain trust exploitation represents more than just a technical curiosity—it's a fundamental flaw in how many organizations conceptualize Active Directory security. The attack highlights the dangerous misconception that child domains can be treated as isolated security boundaries.
In real-world scenarios, organizations often place less critical systems, development environments, or subsidiary operations in child domains, operating under the assumption that a compromise in these "less important" domains won't affect core business operations. This attack demonstrates why that assumption is fatally flawed.
The business impact extends beyond immediate data access. Enterprise Administrator privileges provide attackers with the ability to modify Group Policy Objects (GPOs) that affect the entire forest, install malicious software on any system in the organization, access sensitive data across all domains, and establish persistent backdoors.
Detection and Blue Team Perspective: Spotting the Attack
Detecting child-to-parent domain trust exploitation requires a multi-layered approach that monitors both individual attack techniques and overall privilege escalation patterns.
Event Log Indicators provide the most direct evidence of Golden Ticket usage:
- Event ID 4769 (Kerberos service ticket requested) with unusual characteristics
- Event ID 4624 (successful logon) from unexpected sources
- Authentication events with SID History attributes
DCSync Operations represent another key detection opportunity. Event ID 4662 (An operation was performed on an object) with the DS-Replication-Get-Changes extended right can indicate DCSync activity.
Behavioral Analysis can reveal patterns consistent with this attack. Look for sequences showing initial compromise in a child domain followed by administrative access to parent domain resources.
Mitigation Strategies: Defending Against the Attack
Immediate mitigation actions:
- KRBTGT password rotation - The most effective immediate response. Microsoft recommends rotating twice with sufficient intervals.
- SID filtering implementation - Prevents SID History from being honored across trust boundaries
- Privilege review and reduction - Review all accounts with Domain Administrator privileges
Long-term security improvements:
- Deploy advanced threat detection solutions
- Implement zero-trust architecture principles
- Conduct regular security assessments
- Consider architectural changes to eliminate unnecessary child domains
Conclusion and Key Takeaways: Lessons for the Modern Enterprise
The child-to-parent domain trust exploitation attack serves as a stark reminder that in Active Directory forests, security is only as strong as the weakest domain. The primary lesson for security professionals is clear: any domain compromise must be treated as a potential forest-wide incident.
For red teamers and penetration testers, this attack represents an essential technique that should be included in every Active Directory assessment. For blue team professionals, investment in behavioral analysis, advanced threat detection, and comprehensive logging is essential.
The broader cybersecurity community should recognize this attack as emblematic of a larger trend toward "living off the land" techniques that abuse legitimate functionality rather than exploiting software vulnerabilities.
Moving forward, organizations should prioritize Active Directory security architecture reviews, implement comprehensive monitoring for trust-based attacks, and develop incident response procedures that account for the rapid escalation potential of forest-wide compromise scenarios.
Disclaimer: This content is provided for educational and authorized security testing purposes only. Unauthorized access to computer systems is illegal and may result in criminal prosecution. Always ensure you have explicit written permission before conducting security testing activities.