Recently, security researchers Will Schroeder and Lee Christensen released a blog post and white paper detailing several potential attack paths within Active Directory Certificate Services (ADCS). ADCS is Microsoft’s implementation of Public Key Infrastructure (PKI) responsible for providing and managing digital certificates, digital signatures and more within Active Directory. Their research focuses heavily on how certificates are utilized for account authentication and their use in potential attack paths for privilege escalation. Following the public disclosure of PetitPotam, one of their identified escalation paths (ESC8) developed into an unauthenticated kill-chain to trivially compromise a domain.

What is PetitPotam?

You might be familiar with the “printer bug” made famous by Lee at a DerbyCon talk in 2018, where a low-privileged domain user can coerce and control authentication from endpoints with an enabled print spooler service. This capability led to several attack chains involving relaying the credentials most recently the ESC8 kill-chain identified in Lee and Will’s blog, where the credentials are successfully relayed to Certificate Authority’s HTTP enrollment interface – more on this later.

PetitPotam, publicly disclosed by French security researcher Lionel Gilles, is comparable to the PrintSpooler bug but utilizes the MS-EFSRPC API to coerce authentication rather than MS-RPRN. The Encrypted File System Remote Protocol is used to remotely manage data objects in encrypted form. EfsRpcOpenFileRaw, the API method used in this attack, is responsible for opening and restoring encrypted objects created by the Encrypted File system and is the origin of the authentication attempt.

The glaring difference between both exploits is PetitPotam does not require any authentication when directed at Domain Controllers.

Breaking it down

At a high level the exploit is a simple four step process:

1. Attacker binds to the target endpoint.
2. Call the EfsRpcOpenFileRaw method directing the process to the attacker-controlled endpoint.
3. The authentication request made by the target is intercepted and/or relayed.
4. Successful exploitation is confirmed following an expected error response.

Each of these steps can be seen from Lionel’s script and within a packet capture to see it in action.

Image

Figure 1: PetitPotam exploit source code

Image

Figure 2: Packet capture of PetitPotam exploit

ESC8

The ESC8 attack path in Lee and Will’s research can relay coerced NTLM authentication attempts to the web-based certificate enrollment services which are vulnerable to NTLM relay attacks in its default configuration.

“This attack, like all NTLM relay attacks, requires a victim account to authenticate to an attacker-controlled machine. An attacker can coerce authentication by many means, but a simple technique is to coerce a machine account to authenticate to the attacker’s host using the MS-RPRN RpcRemoteFindFirstPrinterChangeNotification(Ex) methods using a tool like SpoolSample or Dementor.”

ExAndroidDev built on Will and Lee’s research releasing a proof of concept to perform the certificate request on behalf of the relayed account utilizing the print spooler bug. Their updated version of ntlmrelay can forward coerced authentication and submit a CSR and acquire the certificate for the relayed account – in the POC’s case, the domain controller. They’re then able to request a ticket granting ticket (TGT) as the relayed domain controller machine account, inject the ticket into their sessions, then perform a DCSync and compromise the domain. For more info on TGTs and other Kerberos attacks check out Kevin’s insightful Kerberos - A Domains Achille's Heel.

Putting it all together

As I mentioned, the limitation with ExAndroidDev’s attack chain is the requirement to have some form of legitimate domain credentials to leverage the printer bug. But with PetitPotam we’re freed from that limitation. So, I modified his chain and simulated the attack from a black box approach with no domain credentials or access.

Attack Scenario

1. Identify the vulnerable Certificate Authority running web-enrollment
2. Perform the NTLM relay using ExAndroidDev’s modified ntlmrelay and PetitPotam
3. From a non-domain joined Windows 10 host, configure DNS to point to the domain controller
4. From the same host, use Rubeus to request a TGT with the generated certificate
5. Use Mimikatz to extract domain hashes

1. Identifying the Certificate Authority

From a basic Nmap service discovery scan, you can see the default self-signed certificate for the CA in the format of “hostname-CA.” In my case, I needed to redeploy certificate services a few times, so you’ll notice it’s “hostname-CA-2.” I didn’t want to modify anything for the sake of testing and left it as is.

Image

Figure 3: Default self-signed certificate revealing certificate services web-enrollment

2. Perform the NTLM relay

We use Lionel’s PetitPotam script to coerce authentication from the Domain Controller to our attacking machine where ExAndroidDev’s updated ntlmrelay script is waiting to relay the authentication attempt to the located certificate authority. The relay is successful and we retrieve the domain controllers base64 encoded certificate.

Image

Figure 4: Running PetitPotam targeting the Domain Controller to authenticate to our attacking Kali host

Image

Figure 5: Relaying the authentication to the Certificate Authority

3. Configure Windows 10 host’s DNS settings

For the Kerberos attacks to be successful we need to update the DNS settings on our rogue Windows 10 host to resolve the “corp.local” domain as well as the fully qualified domain name of the domain controller itself.

Image

Figure 6: Showing the machine is workgroup joined with DNS configured to point to the Domain Controller

4. Use Rubeus to request the TGT and “pass-the-ticket” to inject into our session. We’re now effectively the “DC01$” machine account.

Image

Figure 7: Successfully requesting and injecting the TGT into our session

5. And to compromise the domain we will use Mimikatz to perform a DCSync attack and retrieve the Domain Administrator’s hash.

Mimikatz is a “proof of concept” tool developed by Benjamin Delpy that’s used in various attacks, including from memory credential dumping and Kerberos attacks. A DCSync attack is where an attacker acts as a domain controller and synchronizes with another domain controller to steal credentials. This synchronization is possible due to the Directory Replication Service (DRS) which is built in to Active Directory and is responsible for ensuring any changes made within the environment are synchronized across all domain controllers in the forest. For example: After a user’s password is updated on DC01 DRS, it ensures the password change is replicated, or synchronized, on DC02, DC03, etc. Since our current session is acting as the domain controller this attack is successful and we have compromised the domain.

Image

Figure 8: Extracting the domain administrator hash with Mimikatz

Impact and Mitigation

To recap, using a new NTLM relay attack chain targeting ADCS web enrollment, we have compromised our testing environment domain starting with zero privileges. All an attacker would need to be successful is network access to an environment where these services are deployed with the default configuration (combined with minor reconnaissance). As of this publication there has been no indication from Microsoft regarding intentions to adjust how the EFS API operates to mitigate this attack. That said, there are measures defenders can take to mitigate their risk.

Microsoft released some guidance on how to protect against the PetitPotam NTLM relay attack here. Their mitigation steps include:

1. Enabling EPA and disabling HTTP on ADCS servers.
   
   
   • EPA, or extended protection for authentication, essentially verifies the authentication being submitted to the service was originally intended for that endpoint. In relay attacks this is not the case so the authentication attempt fails when this is enabled.


2. Disabling NTLM at the Domain Controller and/or the ADCS server.

For IDS detection the attack detection team at ptsecurity released Suricata rules to aid in detection available on their GitHub here that focus on identifying the RPC bind and NTLM hash leak of the machine account in network traffic as shown in the packet capture previously.