Active Directory Certificate Services (ADCS) is one of the most dangerous and least-audited systems in a typical Windows environment. In most credit union and small business networks running default configurations, ADCS contains at least one critical misconfiguration that gives any authenticated domain user a direct path to domain admin.

This guide covers how to audit your ADCS deployment for the most common and most impactful misconfigurations, ESC1, ESC8, and a few others, and exactly what to do to fix them.

Why ADCS Is a Critical Attack Surface

ADCS issues digital certificates used throughout your Windows environment: for user authentication, computer authentication, code signing, smart card logon, and encrypted email. Certificates are trusted authentication tokens. When a misconfigured CA issues them incorrectly, attackers can authenticate as any user in the domain, including domain admins and domain controllers.

SpecterOps researchers documented the major ADCS attack classes in their 2021 Certified Pre-Owned whitepaper. Those findings remain valid in most environments today because ADCS gets treated as infrastructure nobody needs to revisit after setup.

Microsoft's own December 2025 guidance on Active Directory threats lists ADCS abuse as a high-priority attack vector requiring mitigation, often chained with NTLM relay attacks for the fastest path to domain admin.

The Three Most Common ADCS Misconfigurations

ESC1 — Enrollee Supplies Subject (Template Allows SAN Specification)

What it is: A certificate template has the "Supply in the request" option enabled for the Subject field. That means the person requesting the certificate can specify any Subject Alternative Name (SAN), including the UPN of a domain admin.

What attackers do with it: They request a certificate claiming to be a domain admin, use that certificate to authenticate via Kerberos PKINIT, and obtain a TGT for the domain admin account. No password required.

How to check: 1. Open the Certificate Templates console (certtmpl.msc) 2. For each custom template, open Properties and go to the Subject Name tab 3. If "Supply in the request" is selected, check who can enroll in the template

A template with "Supply in request" plus broad enrollment rights (Domain Users, Authenticated Users, or similar) is ESC1-vulnerable.

How to fix: - Change templates to "Build from this Active Directory information" rather than "Supply in the request" - For templates that legitimately need SAN flexibility (rare), restrict enrollment to a specific, minimal security group - Enable the CA Manager Approval requirement on sensitive templates to add a human review step before certificate issuance

ESC8 — NTLM Relay to ADCS HTTP Enrollment

What it is: The ADCS Web Enrollment service is accessible via HTTP and accepts NTLM authentication without Extended Protection for Authentication (EPA). An attacker who can coerce a domain controller to authenticate outbound can relay that authentication to /certsrv/ and receive a certificate for the DC's machine account.

What attackers do with it: They use the DC's certificate to request a Kerberos TGT via PKINIT, then run DCSync to extract all domain password hashes. Full domain compromise in approximately 15 minutes from a standard user account.

How to check: 1. Navigate to http://[your-CA-server]/certsrv/ from inside your network 2. If you reach a login page or are auto-authenticated, Web Enrollment is enabled 3. Check whether it's accessible over HTTP and not just HTTPS 4. In IIS Manager on the CA server, check whether EPA is enabled under the Web Enrollment site authentication settings

How to fix: 1. If Web Enrollment isn't actively used, disable it entirely. This removes the attack surface completely. 2. If Web Enrollment is needed, require HTTPS (HTTP must not be available), then enable EPA in IIS by selecting the Web Enrollment site, going to Authentication, then Windows Authentication, then Advanced Settings, and enabling Extended Protection. 3. As an additional defense, disable NTLM on the CA server entirely via Group Policy: Network Security: Restrict NTLM: Incoming NTLM traffic, set to Deny all domain accounts.

ESC4 — Vulnerable Certificate Template Access Control

What it is: A template's ACL grants Write or FullControl to non-admin principals, allowing an attacker to modify the template itself, for example by enabling the SAN flag to create an ESC1-equivalent vulnerability.

How to check: In certtmpl.msc, right-click each template, select All Tasks, then Manage Security. Look for Write Properties or Full Control grants to Domain Users, Authenticated Users, or specific service accounts that shouldn't have template modification rights.

How to fix: Remove Write access from non-administrative accounts. Template modification rights should be limited to Certificate Managers and Domain Admins.

Running a Full ADCS Audit

Microsoft's PKI Health Tool (pkiview.msc) checks CA health but does not surface security misconfigurations. For a security-focused audit, use Certipy.

Certipy (open source, Python): Certipy audits ADCS for all known ESC vulnerabilities. Running in "find" mode, it enumerates all certificate templates and the CA configuration, then produces a report of exploitable misconfigurations.

# Run Certipy audit (requires domain credentials)
certipy find -u [user]@[domain] -p [password] -target [DC-IP] -vulnerable

This produces output listing every vulnerable template with its ESC classification.

Note: Certipy is an offensive tool. Running it on your own environment in an authorized capacity is appropriate for security auditing. Ensure you have written authorization before running any enumeration tool.

For environments where running offensive tooling isn't appropriate, the manual checks described above for ESC1 and ESC8 cover the most critical exposures.

Additional ADCS Hardening Steps

Beyond the ESC vulnerabilities, several additional hardening measures reduce the overall attack surface.

Audit issued certificates regularly. Review the CA's issued certificate log for unexpected requesters, certificates for machine accounts requested by user accounts, or certificates using templates you wouldn't expect to see active. This can surface exploitation that already occurred. For more on what attackers do after obtaining a certificate, see the DCSync attack guide.

Enable CA Manager Approval on sensitive templates. Requiring a human review step before certificate issuance stops automated exploitation. An attacker cannot obtain a certificate without someone seeing the request first.

Restrict template enrollment rights. The default "Authenticated Users" enrollment right on many templates is far too broad. Restrict enrollment to the specific users or computers that legitimately need each certificate type.

Configure CRL Distribution Points (CDP) correctly. Expired or unreachable CRLs can cause certificate validation to fail domain-wide. Confirm CDPs are configured and accessible.

Enable audit logging on the CA. Enable "Audit Certificate Services" in Local Security Policy on the CA server. This logs certificate request events (Event ID 4886) and certificate issuance events (Event ID 4887), giving you visibility into certificate activity over time.

What to Do If You Suspect Active Exploitation

If a penetration test or security review turns up ADCS misconfigurations, treat them as potentially exploited before your test found them. A few indicators to check:

If active compromise looks likely, bring in an incident response provider. Revoking the certificates themselves is required to clear ADCS-based persistence. Password rotation alone leaves attackers with valid access until the underlying certificates are invalidated.

Frequently Asked Questions

How do I know if my ADCS is vulnerable without running offensive tools? The manual checks above, reviewing template Subject Name settings in certtmpl.msc and confirming Web Enrollment HTTP accessibility, cover the most common exposures without requiring offensive tooling. For a comprehensive assessment, a penetration test using Certipy provides complete coverage.

Do these vulnerabilities affect all Windows versions? ESC1 and ESC8 affect all Windows Server versions prior to 2025 in default configurations. Windows Server 2025 made HTTPS with EPA the default for new Web Enrollment deployments, but CAs upgraded from older versions may not have those settings applied automatically.

How long does it take to fix these issues? Fixing ESC1 by modifying template settings takes minutes. Fixing ESC8 by enabling EPA and requiring HTTPS takes a few hours of IIS configuration and testing. The full ADCS hardening process, covering templates, access controls, and audit logging, is typically a half-day project for a single CA deployment.

Sources

Stay sharp. Stay prepared. — ThreatForged AI

Written by Ryan Kucher, founder of ThreatForged AI. ADCS misconfiguration testing, including ESC1, ESC8, and ESC15, is included in every ThreatForged AI assessment. Book a scoping call.