Every exploitable ADCS certificate path in your PKI, found and proven.
ADscan validates all 15 ESC classes against your Active Directory Certificate Services deployment — 12 auto-exploited end to end, 3 detected and flagged — so you know exactly which certificate misconfigurations are open attack routes to Domain Admin today.
ADCS certificate exposure is the set of certificate-template and PKI misconfigurations (ESC1 through ESC15) that allow an attacker to obtain a certificate that can be used to authenticate as a privileged user, including a Domain Admin or Domain Controller. ADscan validates each supported class against your live environment using a native certipy-equivalent implementation.
12 / 15
Active Directory Certificate Services is deployed in the majority of enterprise Windows environments, yet its attack surface remained largely unknown until the ESC research published by Will Schroeder and Lee Christensen in 2021. Since then, every major ransomware post-mortem has included a certificate-template misconfiguration as either the initial access vector or the privilege escalation step. Annual pentests rarely include a full ESC enumeration pass, and automated scanners only map templates without exploiting them. ADscan validates each class with a native implementation, proves the path end to end, and ties each finding to DORA, NIS2 and ENS.
ESC classes auto-exploited end to end by ADscan · ESC5, ESC10, ESC16, ESC17 detected and flagged
- 01
Enumerate the PKI
Collect every certificate template, CA configuration, and issuance policy from the domain natively — no agent, no certipy binary, no PowerShell dependency.
- 02
Classify each ESC class
Evaluate templates against all 15 ESC conditions: enrollment rights, CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT, EKU misconfigurations, CA-level misconfigurations, relay conditions, and the newer ESC11 through ESC15 classes.
- 03
Exploit each supported class
Request and obtain certificates for ESC1 through ESC4, ESC6 through ESC9, and ESC11 through ESC13 (12 classes) end to end, recovering a high-privilege credential or ticket from each.
- 04
Detect and flag remaining classes
ESC5, ESC10, ESC16 and ESC17 are enumerated, analysed and flagged as present with detailed exploitation notes, but are not auto-exploited given their environment-specific complexity.
- 05
Chain to Domain Admin
Where a certificate path leads to a Domain Controller account or a privileged group, ADscan chains the recovery through PKINIT or S4U to obtain a Domain Admin ticket and mark the path proven.
- 06
Map to compliance and remediate
Each proven or detected ESC class is tied to its DORA, NIS2 and ENS control, and paired with the specific template or CA configuration change that closes it.
ESC1 through ESC15 coverage
ADscan evaluates all 15 ESC classes defined in the Certified Pre-Owned research and its follow-up work. 12 are exploited automatically; 3 (ESC5, ESC10, ESC16, ESC17) are detected and surfaced with exploitation notes.
Native certipy-equivalent implementation
Certificate enumeration and exploitation use a native implementation — no certipy binary shipped or invoked. The same LDAP and RPC protocols used by Windows itself enumerate templates, request certificates and convert them to Kerberos tickets.
PKINIT and S4U chain to Tier 0
Where certificate recovery allows PKINIT, ADscan completes the chain to a Kerberos TGT and Domain Admin ticket, proving the path reaches Tier 0 rather than stopping at certificate retrieval.
CA-level misconfiguration detection
Beyond template checks, ADscan evaluates CA-level conditions (ESC6, ESC7, ESC8) including EDITF_ATTRIBUTESUBJECTALTNAME2, ACL on the CA object itself, and NTLM relay conditions against the certificate enrollment endpoint.
Proven vs detected, clearly separated
The report distinguishes exploited ESC classes (certificate obtained and chained to Domain Admin) from detected ESC classes (present and exploitable, but not auto-exploited). Both categories include severity rating and remediation.
Template-level remediation guidance
Each finding maps to the exact template property or CA setting that closes the exposure: flag names, registry keys, and the Group Policy path where relevant, not generic "harden your PKI" advice.
Mapped to the control your supervisor asks about.
ADCS certificate-template misconfigurations are direct attack paths to Domain Admin. Each proven ESC finding is tied to DORA Article 9.4 (protection and prevention of ICT infrastructure) and Article 24 (testing), NIS2 Article 21 risk-management and access-control measures, ENS Alto operational and access-control controls including OP.ACC.6 and MP.IF.7, and ISO 27001:2022 Annex A.8. The report delivers the legal citation next to each finding so your compliance evidence is ready without a separate mapping exercise.
The open-source ADscan engine on the command line enumerates all ESC classes, exploits the 12 supported classes end to end, and reports each finding with remediation guidance. Free on GitHub, no license required.
Adds the board-ready PDF report with the full ADCS attack narrative, per-finding DORA, NIS2 and ENS compliance mapping, and MITRE ATT&CK technique references. Free in beta for consultancies and MSSPs in exchange for feedback. The Enterprise platform adds scheduled re-validation and drift tracking across PKI changes.
Explore the rest of the platform.
In every regulated environment where ADscan has run a full PKI assessment, at least one exploitable ESC class was present. ESC1 and ESC3 are the most common; in two cases the CA itself had EDITF_ATTRIBUTESUBJECTALTNAME2 enabled, making every enrolled certificate a potential Domain Admin vector.
Questions, answered.
What is an ADCS ESC1 attack?
ESC1 is the certificate-template misconfiguration where the template allows the requesting user to supply a Subject Alternative Name (SAN) and grants enrollment rights to low-privilege users. An attacker requests a certificate with a Domain Admin UPN in the SAN field, then uses it to obtain a Kerberos TGT as Domain Admin. ADscan identifies eligible templates and completes this chain end to end.
How many ESC classes exist and which does ADscan cover?
The Certified Pre-Owned research defined ESC1 through ESC8, and subsequent research extended the catalogue to ESC15. ADscan evaluates all 15 classes. ESC1 through ESC4, ESC6 through ESC9, and ESC11 through ESC13 (12 classes) are auto-exploited end to end. ESC5, ESC10, ESC16 and ESC17 are detected and flagged with exploitation notes but are not auto-exploited due to their environment-specific complexity.
How does ADscan detect ADCS attacks without running certipy?
ADscan uses a native implementation of the same LDAP and RPC protocols that Windows uses to enumerate certificate templates, query CA configuration, and request certificates. No external binary is shipped or invoked. This keeps the tool dependency-free and means the enumeration logic can run across domain trusts and in constrained environments where PowerShell or third-party tooling is blocked.
Does ADscan use certipy?
No. ADscan includes a certipy-equivalent native implementation that reproduces the same enumeration and exploitation logic using Windows protocols directly. This avoids a Python runtime dependency, keeps the tool self-contained, and means the implementation can be audited alongside the rest of the ADscan codebase.
Is ADCS in DORA and ENS Alto scope?
Yes. ADCS is the PKI infrastructure that underpins authentication and code signing in Windows environments. A compromised certificate authority is equivalent to a compromised domain. DORA Article 9.4 requires protection and prevention measures for ICT infrastructure, and Article 24 requires periodic testing of those measures. ENS Alto operational controls (OP.ACC.6) and ISO 27001:2022 Annex A.8 both cover privileged access and authentication infrastructure. ADscan maps each ESC finding to the specific control.
What is the difference between a certificate misconfiguration and a path to Domain Admin?
A certificate misconfiguration (such as ESC1) is a property on a single template or CA. A path to Domain Admin is the chain: low-privilege account enrolls in the template, obtains a certificate with an admin SAN, uses PKINIT to get a TGT as Domain Admin. ADscan validates the full chain, not just the template condition, so you know the misconfiguration is a real attack route rather than a theoretical one.
Find out which path to Domain Admin you have today.
Request a proof of value and we will run ADscan against your Active Directory, then deliver the compliance-mapped report.