What is Active Directory Certificate Services?

Definition

Active Directory Certificate Services (AD CS) is Microsoft's Public Key Infrastructure (PKI) built into Windows Server. It issues, manages, and revokes X.509 certificates used for:

• User and computer authentication (smart card logon, certificate-based Wi-Fi/VPN, IPSec).
• TLS for internal services.
• Code signing, document signing, EFS encryption.
• AD-integrated PKI with auto-enrollment and template-driven issuance.

AD CS is forest-wide and a Tier 0 asset.

In simple terms:

AD CS issues certificates that grant access. Misconfigured templates let attackers issue themselves a certificate as Domain Admin.

---

Why AD CS Matters

• Certificates can authenticate as any user if a template is misconfigured.
• AD CS abuses bypass password policies, MFA, and many monitoring tools.
• The 2021 SpecterOps "Certified Pre-Owned" research uncovered the ESC1–ESC8 family of misconfigurations; later research extended this to ESC9–ESC15+.
• AD CS is rarely audited closely — and is one of the most common paths to Domain Admin in modern AD assessments.

---

How AD CS Works (High Level)

Components

• Certification Authority (CA) — issues certificates.
• Certificate Templates — define who can request what type of certificate, with what attributes.
• Web Enrollment (/certsrv) — HTTP(S) interface for certificate requests.
• CES / CEP — modern certificate enrollment web services.
• NDES — Network Device Enrollment Service.
• AD CS objects in AD — published templates, CA configuration.

Issuance Flow

1. User/computer requests a certificate based on a template.
2. CA validates the request against template settings (rights, EKUs, etc.).
3. CA issues the certificate.
4. The recipient uses the certificate (e.g., for smart card logon: PKINIT).

Authentication With Certificates

Kerberos PKINIT allows certificate-based logon. The KDC trusts certificates issued by trusted CAs and maps them to user accounts via SAN (Subject Alternative Name), UPN, or strong mappings.

---

The ESC Family of Attacks

SpecterOps's ESC1–ESC8 (and follow-on ESC9–ESC15+) catalog AD CS misconfigurations. A non-exhaustive overview:

• ESC1 — Templates allowing low-privilege users to request certificates with Enrollee Supplies Subject and Client Authentication EKU. Attacker requests a cert as Domain Admin.
• ESC2 — Templates with Any Purpose EKU allow certificate misuse including authentication.
• ESC3 — Enrollment Agent templates that allow requesting on behalf of others without restriction.
• ESC4 — Misconfigured ACLs on templates allow modification.
• ESC5 — Misconfigured ACLs on PKI objects (CA itself, NTAuthCertificates, etc.).
• ESC6 — EDITF_ATTRIBUTESUBJECTALTNAME2 flag on CA allows attacker-supplied SAN.
• ESC7 — Manage CA / Manage Certificates rights misgranted.
• ESC8 — NTLM relay to AD CS web enrollment (/certsrv).
• ESC9 / ESC10 — Weak certificate mapping configurations (UPN-based, no strong mapping).
• ESC11 — NTLM relay to ICPR (RPC interface) without packet integrity.
• ESC12 — Compromised CA private key on YubiHSM/etc.
• ESC13 / ESC14 / ESC15 — Various template-related misconfigurations and OID group link abuses.

(Numbers and details continue to evolve as researchers find new variants.)

---

Real-World Examples

1. ESC1 → Domain Admin

A long-standing template named User-Web allows authenticated users to request certificates with arbitrary subject and Client Authentication EKU. Attacker requests a cert as [email protected], authenticates via PKINIT, becomes Domain Admin.

2. ESC8 (PetitPotam → AD CS)

Attacker uses PetitPotam to coerce a DC to authenticate to attacker-controlled host. Authentication is relayed to https://ca.corp.local/certsrv/certfnsh.asp. Attacker obtains a DC certificate and uses it for DCSync.

3. ESC6 SAN Injection

The CA has the EDITF_ATTRIBUTESUBJECTALTNAME2 flag enabled. Attacker requests a cert and supplies [email protected] in attributes. CA includes it in SAN; PKINIT authenticates as Administrator.

4. ESC10 (Weak Mapping Post-May-2022 Patches)

After Microsoft's strong-certificate-mapping enforcement, environments still in compatibility mode are vulnerable to weak SAN/UPN mapping abuses.

---

AD CS Hardening Best Practices

Templates

1. Audit every published template for:
   • Who can enroll (security descriptors).
   • Whether Enrollee Supplies Subject is enabled.
   • EKU list (especially Client Authentication, Smart Card Logon, Any Purpose).
   • Manager approval requirements.
2. Require manager approval on sensitive templates.
3. Disable Enrollee Supplies Subject unless absolutely required.
4. Restrict enrollment rights to specific groups.
5. Remove unused templates.

CA Configuration

6. Disable EDITF_ATTRIBUTESUBJECTALTNAME2 flag (ESC6).
7. Restrict Manage CA / Manage Certificates rights.
8. Enable auditing on CAs (Event ID 4886, 4887).
9. Patch promptly (May 2022 strong mapping; ongoing).

Enrollment Endpoints

10. Disable HTTP on web enrollment; require HTTPS with EPA (Extended Protection for Authentication).
11. Disable web enrollment entirely if not used.
12. Restrict NTLM to AD CS endpoints.
13. Apply CES/CEP with modern auth where possible.

Certificate Mapping

14. Enforce strong certificate mapping (post-May 2022 KB updates).
15. Add OID 2.16.840.1.114414 SID extension as required.
16. Audit weak mappings and migrate.

Architecture

17. Treat CAs as Tier 0.
18. Protect CA private keys with HSMs.
19. Separate online issuing CA from offline root CA.
20. Monitor NTAuthCertificates for unauthorized additions.

Detection

21. Detect anomalous certificate issuance (unusual templates, requesters).
22. Detect PetitPotam / NTLM relay patterns.
23. Monitor Event IDs 4886, 4887, 4768 for PKINIT anomalies.

---

AD CS Security Checklist

• Templates audited for ESC1, ESC2, ESC3, ESC4 patterns?
• CA flag EDITF_ATTRIBUTESUBJECTALTNAME2 disabled (ESC6)?
• Manage CA / Certificates rights restricted (ESC7)?
• Web enrollment HTTPS-only with EPA, NTLM restricted (ESC8)?
• Strong certificate mapping enforced (post-May 2022)?
• Unused templates removed?
• CA private keys in HSM?
• CAs treated as Tier 0?
• Patching current?
• AD CS detections live in SIEM?

---

How Forestall Helps

Forestall continuously analyzes the AD CS configuration:

• Lists every template with risky settings (ESC1–ESC15).
• Identifies CAs with EDITF_ATTRIBUTESUBJECTALTNAME2 enabled (ESC6).
• Surfaces enrollment rights misconfigurations.
• Detects weak mappings.
• Maps certificate-issuance paths from low-privilege identity → Tier 0.
• Tracks ESC findings over time as remediations land.

---

Frequently Asked Questions

Should I disable AD CS?

Not unless you don't use it. AD CS is essential for many legitimate scenarios; the goal is hardening, not removal.

How urgent is ESC8 mitigation?

Urgent. ESC8 enables PetitPotam-style escalation to Domain Admin in many environments.

Does the May 2022 patch fix everything?

It's a major step — strong mapping reduces several ESCs — but many ESC abuses remain (template misconfigs, ACLs, ESC6).

Are external CAs safer?

Often yes, for internet-facing TLS. AD CS still has a place for internal authentication and smart card logon.

How often should I audit AD CS?

Continuously is best. Templates, ACLs, and CA settings drift quickly.

---

Conclusion

Active Directory Certificate Services is one of the most consequential and most overlooked components of Active Directory. The ESC family of misconfigurations has turned AD CS into a top path to Domain Admin in modern attacks. Comprehensive template auditing, strict CA configuration, NTLM relay protections, strong certificate mapping, HSM protection, and continuous monitoring transform AD CS from a hidden risk into a well-managed Tier 0 service. If you have AD CS, treat it as carefully as you treat your Domain Controllers.