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 Impacket tool and added support for this attack.

Basically, what the fork is doing is using allowing relaying of 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.

UPDATE:

Microsoft published an advisory regarding this - it's available at https://msrc.microsoft.com/update-guide/vulnerability/ADV210003

The advisory offers a workaround against the abuse of ADCS - it consist of disabling NTLM authentication as I wrote above in the diary. This should really be done enterprise wide, however, as always - test.

What the advisory above missed is the fact that the PetitPotam vulnerability (the first step in the diary above) is a completely separate issue - it allows an attacker to provoke a server to authenticate to an arbitrary machine. Abusing ADCS is just one way to use this - any service that allows NTLM authentication can probably be abused similarly (Print Spooler could be a candidate).

Detection: If you want to check if there were attacks against your environment, look for events with Event Code 4768 (TGT request), where the Certificate Information section contains data (Certificate Issuer Name, Serial Number and Thumbprint), indicating that a certificate was used for request.

This is what it looks like (the Splunk search used below was: index=windows EventCode=4768 Certificate_Issuer_Name=*):

--
Bojan
@bojanz
INFIGO IS