Active Directory Certificate Services Is the Privilege Escalation Path Your Pentest Is Missing

The internal penetration test report comes back clean on the usual items. No Kerberoastable accounts with weak passwords. No AS-REP roasting opportunities. No unconstrained delegation on anything sensitive. The assessors got to domain admin eventually, but only through a chain of misconfigurations that the team is already patching.

Then someone asks: did you look at ADCS?

If the assessment was typical, the answer is probably not. Active Directory Certificate Services has become one of the most reliable paths to domain compromise available to a penetration tester, and it is also one of the most consistently under-reviewed areas in an average internal engagement.

What ADCS Is and Why It Matters

ADCS is Microsoft's Public Key Infrastructure implementation for Windows environments. It issues certificates used for authentication, code signing, email encryption, and dozens of other purposes inside a domain. It has been a standard component of large Active Directory environments for years.

The problem is that it was designed primarily for functionality, not for adversarial review. The default configurations are permissive in ways that were acceptable when only administrators were expected to interact with the PKI, and the attack surface those configurations create was not widely documented until 2021, when SpecterOps released research covering eight distinct misconfiguration classes - now commonly referred to as ESC1 through ESC8.

Since that research was published, ADCS misconfigurations have shown up in breaches, in ransomware attack paths, and in virtually every mature red team engagement against Windows environments that bothers to look for them. They are not theoretical. They are present in a large fraction of enterprise environments and they lead to domain admin.

The ESC1 Misconfiguration and Why It Is Everywhere

The most commonly exploited class is ESC1: a certificate template that allows requesters to specify a Subject Alternative Name and is available to low-privileged domain users.

When a certificate template has these properties, any authenticated user can request a certificate claiming to be any other user - including domain administrators. They use that certificate to authenticate as the administrator. They get domain admin. The entire attack runs in under a minute once the misconfiguration is identified.

This misconfiguration appears so frequently because it is easy to create accidentally. The Subject Alternative Name setting is a legitimate feature used by some applications that need to authenticate as service accounts or impersonate users. Administrators who configured those templates years ago often enabled the setting and set the permissions broadly because they needed it to work, and they did not realize what they were enabling for any authenticated user.

Certify, the tool from SpecterOps, and Certipy, a Python port with expanded capabilities, can enumerate ADCS configurations in minutes and identify vulnerable templates immediately. The scanning step is not sophisticated. The findings it produces frequently are.

The Other Misconfiguration Classes

ESC1 gets the most attention, but the full set covers different flavors of the same core problem: certificates that grant more than intended to more principals than intended.

ESC2 covers templates where the certificate can be used for any purpose rather than just the intended one. Combined with permissive enrollment settings, this creates similar privilege escalation paths. ESC3 involves certificate templates that allow enrollment agents to request certificates on behalf of other principals, enabling impersonation through a more indirect route.

ESC4 and ESC7 cover access control issues on templates and the CA itself - scenarios where lower-privileged users can modify template settings or the CA configuration in ways that enable the attacks above. ESC6 involves a CA setting that allows requesters to specify subject information in the request, with implications similar to ESC1.

ESC8 is structurally different. It is an NTLM relay attack against the web enrollment interface that ADCS provides. If HTTP enrollment is enabled and NTLM authentication is not hardened, an attacker who can relay NTLM authentication from a privileged account - which coercion techniques like PetitPotam can force - can obtain a certificate for that account and authenticate as it. This attack path runs from network position to domain admin without requiring any pre-existing foothold on a domain-joined machine.

Why Assessments Miss It

Standard internal penetration testing methodology evolved around specific attack patterns: password spraying, Kerberoasting, AS-REP roasting, SMB relay, BloodHound path analysis. These techniques are well-documented, tool-supported, and expected in an assessment deliverable. ADCS analysis was not part of the standard checklist until recently.

Assessors who learned their methodology before 2022, or who are following a checklist built at that time, may not include ADCS enumeration as a matter of course. The tool support is there now. The awareness is not universal.

There is also a scope issue. Some assessments explicitly limit testing to a predefined set of systems or techniques, and PKI infrastructure may fall outside the agreed scope. This is a conversation worth having before the engagement begins, not after the report is delivered. If you are scoping an internal assessment and your environment includes an enterprise CA, ADCS analysis should be explicitly in scope and explicitly expected.

What to Actually Look For

Running Certipy against an environment takes a few minutes and produces output that clearly flags vulnerable template configurations. The first question is whether any templates allow Subject Alternative Name specification by low-privileged users. The second is whether the web enrollment interface is accessible and accepts NTLM authentication without hardening.

If you are reviewing your own environment rather than running a penetration test, the same tools work defensively. Microsoft has published guidance on identifying and remediating ADCS misconfigurations, and several of the ESC classes can be addressed by adjusting template permissions or disabling specific CA settings.

The access control list review for templates and the CA itself is less automated but equally important. Any template where Domain Users or Authenticated Users has Enroll permission should be reviewed to confirm that the permissions are intentional and that the template configuration does not create unintended privilege escalation paths. The templates to scrutinize most carefully are the ones that predate your current security team - the ones that someone configured for a specific application need and then never revisited.

The Practical Upshot

ADCS misconfigurations are not obscure. They are in the standard toolkit of every capable red team working Windows environments. If your last internal penetration test did not include ADCS enumeration, you have a gap - not because the assessment was otherwise poor, but because the field moved and this is what current methodology looks like.

The remediation is usually not complex. Disable the dangerous settings on the handful of templates that have them, tighten enrollment permissions, and disable web enrollment if the organization does not use it. The attack surface is real and well-understood. The prerequisite to fixing it is knowing it exists, which is why the assessment needs to go looking.