Phew, this was a really bad week for Microsoft (and a lot of reading for all of us). And just when we thought that the fiasco with the SAM hive was over, a new vulnerability popped up, which is much, much more dangerous unfortunately – it allows a user to completely take over a Windows domain that has the ADCS service running. And those are probably running in majority of enterprises.
This involves chaining few things (and I’m a big fan of chaining vulnerabilities), and the bottom line issue is in relaying NTLM authentications (as has been many, many times before).
This is what’s going on now:
(1) Let’s provoke arbitrary NTLM authentication
Earlier this week, @topotam77 released a PoC tool called PetitPotam, which exploits the MS-EFSRPC (Encrypting File System Remote (EFSRPC)) protocol in order to provoke one Windows host to try to authenticate to another. This is done over LSARPC (TCP port 445) and results in making the target server connect to an arbitrary server and perform NTLM authentication.
What’s even crazier is that this can be done without any authentication – so as long as you can connect to the target server to the LSARPC named pipe with interface c681d488-d850-11d0-8c52-00c04fd90f7e, you can make that target server connect to any other server.
Here’s how this can be done:
(2) Relaying to Active Directory Certificate Services
The other vulnerability that is being exploited here is the fact that the IIS server that is used by Active Directory Certificate Services uses NTLM over HTTP for authentication. This makes it perfect for this attack. @ExAndroidDev made a fork of the amazing Responder tool and added support for this attack.
Basically, what the fork is doing is using Responder to relay NTLM authentication to the Active Directory Certificate Services IIS server. In this process it first sends a POST HTTP request to the /certsrv/certfnsh.as endpoint with an automatically generated certificate. While doing this it also passes the NTLM credentials.
If the POST request was successful, the Active Directory Certificate Services server will sign the certificate and Responder will fetch it by sending a GET HTTP request to /certsrv/certnew.cer?ReqID= where the parameter will be provided as response to the POST request.
This is what it looks like when executed:
With the certificate now, it is actually game over.
(3) Using Rubeus to get a TGT
The attacker can now use the Rubeus tool to fetch a Kerberos TGT (Ticket Granting Ticket), by using the machine account that was initially abused to make the NTLM connection. You can probably guess it by now – if that machine was a domain controller, we can get the TGT as that domain controller machine account, which will then ultimately allow the attacker to fully compromise the domain.
It is really game over now. With this TGT in our cache, we can fetch service tickets and perform any action we want, including the Mimikatz’ famous DCSync as @gentilkiwi demonstrated.
Talk about a bad week. And weekend. Sowhat can we do?
One of main issues here is that Active Directory Certificate Services use NTLM for authentication:
So, depending on how your enterprise uses ADCS, you could disable NTLM authentication on the IIS server and this particular attack will not be possible any more. Of course, if you do not need this particular service (web based certificate enroll) – remove it completely!
Couple of other things that will help:
- Use host based firewalls to limit connectivity as much as possible. Does your DC need to make outbound connections to port 445? Do your workstations need to allow inbound connectivity to port 445?
- Collect IIS logs from the Active Directory Certificate Services server to your SIEM and check for those requests mentioned above.
We’ll (again) keep an eye on this, and will update the diary with new information when possible. But it looks like it will be a busy weekend for some.
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
