Silverfort Security Advisory: NTLM Relay to AD CS – PetitPotam and Printer Bug

The PetitPotam attack, published on GitHub, causes a remote server to authenticate to a target server with NTLM, using an MS-EFSRPC command called EfsRpcOpenFileRaw. MS-EFSRPC is a protocol that enables remote access to encrypted files. Causing a server to authenticate with NTLM remotely is bad, because it can be used to trigger NTLM relay attacks.

A particularly dangerous NTLM relay attack is one that targets the Active Directory Certificate Services (AD CS). In a whitepaper (see ESC8), SpecterOps explain how to use an NTLM relay attack on AD CS to take over a machine or impersonate that machine. To impersonate the machine, a client certificate is requested by the machine. Having obtained the client certificate, the attacker can then use one of the following techniques to take over the domain or the target machine:

1. If the machine is a domain controller or another privileged computer, it can use the credentials to sync secrets from the directory, effectively compromising the domain.
2. The attacker can use the S4U2Self protocol to get a service ticket to the target machine as any user.
3. The attacker can use PKInit to obtain the machine NT hash, and then run a silver ticket attack.

The Printer Bug

This vulnerability is related but different from the Printer Bug (presented in DerbyCon 2018 by Will Schroeder). This vulnerability allows an attacker to trigger an NTLM authentication by any client running the PrinterSpooler service. The mitigations provided below will prevent both PetitPotam and the Printer Bug from performing NTLM relay to the AD CS server but will not block an NTLM relay attack to a different target. Since there have been multiple Printer Spooler vulnerabilities published lately, we recommend disabling the Printer Spooler on all member servers and domain controllers that do not need printing.

Microsoft Guidance

Microsoft will not fix this vulnerability, but are advising several possible mitigations. The preferred mitigation is pretty extreme – to completely disable NTLM in the domain. In my experience, that’s not practical advice, NTLM usually takes up two-digit percent of all authentication in the network. Reducing this to zero is usually impractical. The other mitigation they recommend is to restrict incoming NTLM traffic into the AD CS server. If restricting NTLM to the entire server is too harsh, Microsoft instructs how to disable NTLM for the “Certificate Authority Web Enrollment” or “Certificate Enrollment Web Service” services at the IIS level. As a last resort, Microsoft recommends enabling EPA for AD CS.

Silverfort Guidance

The tricky part about Microsoft’s recommendation is to choose the mitigation that’s right for your environment. We recommend the following for Silverfort customers:

1. List all AD CS servers in your domain – we recommend looking specifically at the Cert Publishers security group to find a list of suspected AD CS servers. For each, filter the Silverfort log for NTLM authentication to that server.
2. If there is no NTLM authentication to any of the AD CS servers, disable NTLM into the AD CS servers.
3. Otherwise, follow Microsoft’s instructions for enabling EPA for AD CS.