In August 2021, Microsoft released a patch for Local Security Authority (LSA) Spoofing vulnerability, CVE-2021-36942. This patches one of the issues well known as PetitPotam [1].

PetitPotam is an attack which forces a server to authenticate against an attacker-controlled server using NTLM (NT Lan Manager) by requesting a file present in a malicious server utilising MS-EFSRPC (Microsoft Encrypting File System Remote Protocol) interface. This attacker-controlled server can then relay the NTLM authentication. In this blog we will discuss how PetitPotam can be chained with a relay attack reported in Active Directory Certificate Service (AD CS).

As per Microsoft’s protocol document [2], EFSRPC provides an interface for remote management of encrypted objects stored on disk in order to enforce access control policies and to provide confidentiality from unauthorized users. This can be used to encrypt/decrypt an object, backup and restore an encrypted object and change access rights (user certificates). It connects to named pipes – \pipe\lsarpc and \pipe\efsrpc using SMB as its transport protocol. LSARPC (Local Security Authority Remote Protocol) is an interface for remote management of security related policy settings related to account objects, secret objects and Trusted Domain objects (TDO’s). It uses SMB as its transport and connects to a named pipe \pipe\lsarpc.

NTLM has been long known to be vulnerable to relay attacks. NTLM Relay Attack is a classic Man-in-the-Middle attack where NTLM authentication requests/responses are relayed by an attacker between client and server in order to authenticate and gain access to service or machine. There are several ways to gain access to the network including the recently reported vulnerabilities in Exchange servers. Cross-protocol relay is also possible in NTLM, which means authentication from one protocol (e.g. SMB) can be relayed over another protocol (e.g. HTTP).

PetitPotam allows an attacker to request an object (file) using the EfsRpcOpenFileRaw() method call, passing a UNCPath (file path) present on an attacker-controlled server (NTLM Relay node). This forces the server to connect to the malicious machine which then relays NTLM authentication to the target server. 

In June 2021, AD CS was reported to be vulnerable to NTLM relay attacks under default configuration.

Active Directory Certificate Service, as the name suggests, is a service that deals with issuance and verification of security certificates in a domain. AD CS is Microsoft’s implementation to enable PKI and related services such as IP Security (IPSec) and Encrypting File System (EFS). In [3], authors have identified NTLM Relay to AD CS HTTP endpoint, which means an attacker present in the network can impersonate any account and relay NTLM authentication to request for a client authentication certificate. This certificate can then be used in the network to gain access to services and machines. Various NTLM authentication methods such as SMB, the printer bug, etc, can be used to trigger and relay NTLM authentication request-response.

In [1], the author demonstrated how PetitPotam can be used to force a DC to authenticate to an attacker-controlled server ultimately resulting in compromise of the network. In this blog, we discuss the attack chain leading to the compromise.

The Exploit Chain

We have set up two Windows 2012 R2 servers in AD DC and AD CS roles as shown in Figure 1. A lot of organisations have these on the same machines, but that did not work for us. We used ntlmrelayx [4] on an attacker-controlled machine to relay NTLM authentication to AD CS server and get a client authentication certificate.

Figure 1 shows the set up and flow of traffic in the domain. This will make more sense once we have discussed the attack.

When ntlmrelayx is started on AT, it waits for a connection. Now we execute PetitPotam PoC as shown in Figure 2. 

The attacker requests a file using UNC Path of the relay node (AT) using SMB protocol which forces DC to authenticate to AT (Relay) using NTLM.

These credentials will be relayed to CS. Figure 4 shows NTLM response sent from DC to AT (ntlmrelayx) over SMB traffic. Since cross-protocol relay works, these authentication details are relayed to CS using HTTP as shown in Figure 5. 

As it has been shown in [3], due to NTLM Relay attack against CS, we get a base64 encoded authentication certificate as shown in Figure 6. This certificate can then be used to access machines and services in the domain.

For this attack to work, an attacker needs to be present in the network. This can be achieved using a myriad of vulnerabilities in Windows servers such as the ProxyLogon exchange server vulnerability and other network devices.

Analysis

With the information that a request is being made to EfsRpcOpenRawFile() through /pipe/lsarpc in the demo, let’s debug LSASS.exe and see what’s happening. Based on a quick look up, breakpoints were set up at efslsaext!EfsRpcOpenFileRaw_Downlevel() and efslsaext!EfsRpcOpenFileRaw(). 

On execution, we observed that RPCRT4 handles the connection and calls EfsRpcOpenFileRaw_Downlevel() passing on the file name that was requested as shown in Figure 7.

Looking at the function in Ghidra, we observe that EfsGetLocalFileName() is called before RpcImpersonateclient() as shown in Figure 8. Using RpcImpersonateclient(), a server impersonates a client to use the client’s security context for handling the request. Since this is getting done later, the EfsGetLocalFileName() call is executed with the server’s context, which is a huge risk since the server we connected to in our demo was a Domain Controller.

To fix the issue, Microsoft checks the registry value HKLM\SYSTEM\CurrentControlSet\Services\EFS, and if it is not set to1, the function will not execute as shown in Figure 8. This will protect the large number of customers who are not using this feature from Microsoft.

Recommendations

1. Harden all the critical servers during setup as per the requirements
2. Use a reputed security product like K7 Endpoint Security and K7 Total Security to stay protected from the latest threats
3. Ensure your applications and systems are up-to-date for latest patches and allow updates to install by default

Mitigations

For LSA Spoofing (PetitPotam)

• Install the patch released by Microsoft and keep your system up to date. 

For AD CS

• AD CS is vulnerable in default configuration
• Follow Microsoft Advisory to 
  • Enable Extended Protection for Authentication (EPA) feature
  • Disable NTLM authentication in the domain
  • Ensure SSL is enabled for AD CS server

Further Readings

1. PoC for PetitPotam
2. Microsoft EFSRPC documentation
3. Certified pre-owner: Abusing AD CS published paper is here
4. Ntlmrelayx branch with ADCS attack is here 
5. Excellent write up with NTLM Relay basics
6. MSRC CVE-2021-36942