Active Directory Certificate Services Attacks

What AD CS Is and Why It's a Modern Attack Surface

What AD CS Provides

Active Directory Certificate Services is Microsoft's implementation of a Public Key Infrastructure (PKI) built into Active Directory. Organizations deploy it to issue their own X.509 certificates internally rather than paying a public certificate authority for every certificate they need.

A single AD CS deployment can issue certificates for a wide range of purposes: TLS for internal web servers, code signing, smart card logon, Wi-Fi and VPN client authentication, and, critically for this chapter, general user and computer authentication to the domain itself.

Why Certificates Attract Attackers

That last use case is what makes AD CS interesting to an attacker. A certificate that carries the Client Authentication Extended Key Usage (EKU) can be used to authenticate to Active Directory in place of a password, through a process built on the same PKINIT extension to Kerberos that smart card logon relies on.

In practice, a certificate can function as a durable, portable credential. Whoever holds it can authenticate as the identity embedded in that certificate, in some cases without ever knowing that identity's actual password.

Certificates are also attractive because of an asymmetry in how organizations audit their environments. Security teams have gotten reasonably disciplined about reviewing Domain Admins membership, nested group membership, and GPO-linked privilege.

Far fewer teams have ever inventoried their certificate templates, reviewed who holds enrollment rights on those templates, or checked their Certificate Authority's own access control list. AD CS was, for most of its existence, treated as invisible infrastructure that quietly issued certificates and was never revisited after initial deployment. That combination, strong authentication power plus weak audit visibility, is exactly the profile of a high-value, under-defended attack surface.

The Certified Pre-Owned Research

The 2021 "Certified Pre-Owned" research from SpecterOps changed how the offensive and defensive community treats AD CS. It formally documented a family of misconfiguration classes, labeled ESC1 through ESC8 (Escalation), each describing a distinct way a certificate template, a CA's configuration, or a CA's own access controls can be abused to escalate privilege or persist in a domain.

Since that publication, AD CS abuse has become a standard step in modern AD-focused penetration tests and a documented technique in real intrusions, precisely because so many production environments were deployed years before this research existed and have never been reviewed against it.

Misconfiguration, Not a Vulnerability

It is worth being precise about what AD CS abuse actually is: in almost every ESC case, there is no vulnerability being exploited in the traditional sense, no patch that fixes it outright. These are misconfigurations, permission and template settings that deviate from a secure default, usually introduced through convenience decisions made during initial deployment or through delegated administration that grew too permissive over time.

That also means the fix is available to every organization today, without waiting on a vendor, and this chapter spends real time on exactly what that fix looks like.

Certificate Templates and Enrollment Rights

A certificate template is a policy object stored in Active Directory that defines the rules for a category of certificate the CA is willing to issue. When a user or computer requests a certificate, they request it against a specific template, and the CA issues (or refuses) the certificate based on that template's rules combined with the requester's enrollment rights.

Enrollment Rights: Who Can Even Ask

Enrollment rights are the access control layer that determines who is allowed to request a certificate from a given template in the first place. Templates carry their own ACL, separate from the permissions on the CA itself, and that ACL grants specific security principals rights such as Enroll or AutoEnroll.

In a well-run environment, sensitive templates, particularly any template capable of producing a certificate with client authentication capability, are restricted to a small, deliberate set of principals. In practice, many environments accumulate templates where Domain Users or Authenticated Users hold enrollment rights, often because a template was cloned from a default and nobody revisited the ACL afterward.

Why This Combination Is the Root Cause

This is the root cause underneath nearly every ESC technique in this chapter: enrollment rights that are broader than they should be, applied to a template whose other settings make that broad access dangerous. A template with a dangerous setting but locked-down enrollment rights held only by a trusted admin group is low risk. The identical template with Domain Users granted Enroll is a direct privilege escalation path.

Certificate template review, in other words, means looking at the combination of what a template allows and who can request it, not either one in isolation.

Publish State and Delegation Also Matter

Templates also carry a publish state. A template can exist as a configured object in AD without being published for issuance by any CA, in which case no one can request from it regardless of its settings or ACL. Part of a proper AD CS audit is confirming which templates are actually published and enrollable on production CAs, since a dangerously configured but unpublished template is not currently exploitable, while the same template published even on one CA in the forest is.

Because certificate templates are AD objects, they are also subject to standard AD delegation. Anyone with sufficient rights over the template object itself, through delegated write access, can edit the template's settings directly, potentially converting a currently safe template into a vulnerable one.

This connects certificate template security to the same object-level access control discipline that governs every other sensitive object in the domain, and it is the basis for one of the escalation techniques described later in this chapter.

ESC1: Misconfigured Templates Enabling Impersonation

ESC1 is the most direct and most commonly cited AD CS escalation. It is the combination of three template properties that together let a low-privileged requester become anyone.

The Three Conditions That Have to Line Up

1. Enrollee Supplies Subject is enabled. Technically the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag, visible in the certificate template management console as "Supply in the request" under the Subject Name tab. When enabled, the requester, not Active Directory, decides what identity the resulting certificate represents, including its Subject Alternative Name (SAN).
2. A Client Authentication capable EKU is present. Either Client Authentication or the Kerberos PKINIT-specific Smartcard Logon EKU. This is what makes the resulting certificate usable to actually log on to the domain as the identity it names, rather than being limited to something like code signing or document encryption.
3. Enrollment rights are broad, with no approval gate. An ordinary low-privileged account, commonly Domain Users or Authenticated Users, can request from the template at all, and no manager approval requirement stands in the way of automatic issuance.

How the Escalation Plays Out

When all three conditions line up, a low-privileged domain user can request a certificate from the template and simply specify a Domain Admin's User Principal Name in the SAN field of the request. The CA issues a valid, correctly signed certificate that authenticates as that Domain Admin, because nothing in the template stopped the requester from claiming that identity, and enrollment rights let them make the request in the first place.

The resulting certificate is not a forgery in the way a Golden Ticket is a forgery. It is a completely legitimate, CA-signed certificate. That is precisely what makes ESC1 so effective and so quiet at the moment of abuse: the CA did exactly what it was configured to do.

The problem is entirely in the configuration, not in any flaw in the issuance process itself. Once obtained, the certificate can be used to authenticate as the impersonated account through Kerberos PKINIT, yielding a TGT for that account without ever touching its actual password or hash.

Why It's Easy to Find in an Audit

ESC1 templates are the easiest class of AD CS misconfiguration to find in an audit, because both conditions, Enrollee Supplies Subject and an authentication EKU, are readable attributes on the template object, and enrollment rights are a readable ACL. Any tooling built to enumerate AD CS, offensive or defensive, treats ESC1 discovery as close to a solved problem.

The fact that it remains one of the most commonly found misconfigurations in real assessments says more about how rarely these templates get reviewed than about how hard the issue is to detect.

ESC8: NTLM Relay to AD CS Web Enrollment

ESC8 is a different category of AD CS attack entirely: it does not depend on a misconfigured certificate template at all. Instead it targets the CA's HTTP-based enrollment interface, commonly reachable as the certsrv web application.

AD CS can optionally expose enrollment over HTTP so that clients that cannot use the native RPC/DCOM enrollment path, such as non-domain-joined or cross-forest systems, can still request certificates through a web form. By default, this web enrollment endpoint accepts NTLM authentication.

Why NTLM to This Endpoint Is Dangerous

NTLM, on its own, is a relayable authentication protocol: a machine authenticating with NTLM to one destination can have that authentication attempt intercepted and forwarded (relayed) to a different destination by an attacker positioned in the middle. The second destination has no reliable way to tell the difference unless specific protections are in place.

Two protections normally defend against this: NTLM signing, which most services require by default, and Extended Protection for Authentication (EPA), which cryptographically binds the authentication to the specific TLS channel it arrived on so a relayed attempt over a different channel fails. The AD CS web enrollment endpoint has historically shipped without EPA enabled and without requiring signing, leaving it exposed to relay by default.

The Attack Chain

1. Coerce a high-value machine account. An attacker forces or lures a machine account, very often a domain controller itself, into authenticating to an attacker-controlled listener, using any of several well-documented coercion methods that abuse Windows RPC interfaces.
2. Relay the captured authentication. The attacker relays that captured NTLM authentication attempt straight to the vulnerable web enrollment endpoint instead of letting it reach its intended destination.
3. Request a certificate as the coerced machine. Because the CA's default machine certificate template grants client authentication capability to computer accounts, the attacker walks away with a valid certificate for that domain controller's own machine account.
4. Authenticate as the coerced machine. The obtained certificate can then be used to authenticate as that domain controller.

Why ESC8 Is Significant

ESC8 does not require the defender to have made a certificate template mistake at all. It requires only that the web enrollment role is installed and running with its default authentication posture, which is common because organizations often enable it for a single legitimate business need and never revisit its authentication hardening afterward.

This makes it one of the more environment-agnostic AD CS attack paths, since it depends on how the CA's web service is configured rather than on any one template's settings.

Mitigation

Mitigation centers on two controls confirmed by Microsoft guidance and consistently cited across defensive AD CS research: requiring Extended Protection for Authentication on both Certificate Authority Web Enrollment and Certificate Enrollment Web Services, and requiring HTTPS with NTLM relay protections enabled, or removing NTLM as an accepted authentication method for these endpoints entirely, restricting them to Kerberos. Where the web enrollment role is not actively required, removing it entirely closes the exposure outright.

Other ESC Techniques, Briefly

ESC1 and ESC8 are the two techniques covered in mechanical depth in this chapter because they are the most consistently documented and the most commonly encountered in practice. The broader ESC family named in the original "Certified Pre-Owned" research and extended by subsequent community research covers several other distinct misconfiguration categories, and it is worth knowing the general shape of each even without full operational depth on all of them.

Some numbering and detail below reflects how the community has documented these since the original 2021 paper and should be treated as a general map rather than an exhaustive technical reference; verify specifics against current SpecterOps, GhostPack Certify, or Certipy documentation before relying on any one detail operationally.

ESC2 Through ESC7 at a Glance

The Detection and Offensive Tooling Landscape

A handful of purpose-built tools defined how both attackers and defenders interact with AD CS, and knowing their names is genuinely useful even for a purely defensive analyst. The same tools blue teams use to audit their own exposure are the tools an intruder is likely to run first.

The Two Core Tools

• Certify was released by GhostPack alongside the original SpecterOps research. It was the first tool built specifically to enumerate AD CS certificate authorities and templates and flag which ones matched known ESC abuse conditions.
• Certipy was developed independently and has become the more commonly referenced tool in current writeups and assessments. It performs the same enumeration role, identifying vulnerable templates, CA configuration flags, and CA-level access control issues, and additionally supports requesting certificates, performing NTLM relay to AD CS web enrollment for ESC8-style attacks, and using an obtained certificate to authenticate.

Certipy's output is frequently the first thing a penetration tester or red team operator runs against an unfamiliar AD environment, specifically because AD CS misconfigurations are so common and so high-impact when found.

The Defensive Framing

An internal security team can and should run this same class of tooling against their own environment on a recurring basis, the same way vulnerability scanning or BloodHound-style AD relationship mapping already happens on a schedule. Finding a vulnerable ESC1 template through your own audit, before an attacker or pentester finds it for you, is the entire point of these tools existing in the open.

Treat AD CS enumeration as a standing item in any AD security assessment, not a one-time check.

Beyond Dedicated AD CS Tools

General AD attack path mapping tools that already ingest certificate template and CA object data (the kind of relationship-graphing tooling covered conceptually alongside the attack path thinking in this module) increasingly surface ESC-style paths automatically as part of broader privilege escalation graphs.

That reflects how thoroughly certificate abuse has been absorbed into mainstream AD attack path analysis rather than remaining a niche, separate concern.

Detection Strategy for AD CS Abuse

Chapter 6 covered the Windows Security event logging pipeline in depth, and AD CS abuse leaves signal in that same pipeline. This requires enabling certificate issuance auditing specifically, which is not part of every default logging baseline.

The starting point for any AD CS detection program is confirming that CA-level auditing is actually turned on, since without it, certificate issuance events simply do not exist to analyze.

The Three Signal Categories

Certificate Issuance: The Highest-Value Signal

Certificate issuance itself is the highest-value signal. Every certificate a CA issues can be logged, and the detail that matters most is the relationship between the account that requested the certificate and the identity embedded in that certificate's SAN.

Building a baseline of which accounts request from which templates, and alerting on deviation, particularly first-time enrollment against a sensitive template, is one of the more durable detections available here because it does not depend on knowing every possible ESC variant in advance.

Web Enrollment Access Patterns

Web enrollment access patterns deserve their own monitoring line, separate from native enrollment, precisely because of ESC8. Unusual CertSrv access should feed into the same detection logic that already watches for NTLM relay behavior more broadly.

A domain controller's machine account requesting a certificate through web enrollment is a pattern worth an alert on its own, since domain controllers have no ordinary reason to self-enroll through that specific endpoint.

Template and CA Object Modification

Template and CA object modification events matter as much as issuance events, because ESC4 and ESC7 style abuse happens upstream of any certificate being issued at all. These are exactly the kind of low-volume, high-signal AD object changes that Chapter 6's object auditing guidance applies to directly.

As with the Chapter 8 techniques, none of these signals are meaningful as a single isolated event. A certificate issuance event is normal, routine AD CS activity happening constantly in any functioning environment. What separates a real detection from noise is context: does the requester's privilege level match the issued identity, does the enrollment path match how that account normally enrolls, and does the template or CA configuration match a known-good baseline you have actually established through a prior audit.

Hardening AD CS as a Tier 0 Asset

The single most important mental shift for defending AD CS is treating the Certificate Authority itself as Tier 0 infrastructure, equivalent in sensitivity to a domain controller, rather than as a background service that happens to run somewhere in the environment.

A compromised CA, or a CA whose configuration lets an attacker impersonate arbitrary identities, provides an attacker with a path to domain-wide compromise that is functionally comparable to compromising a domain controller directly. Any organization that restricts DC logon rights, patches DCs aggressively, and monitors DC activity closely but leaves its CA server administered casually has a real gap between its stated tiering model and its actual practice.

The Practical Hardening Sequence

1. Audit certificate templates. Enumerate every published template, identify which ones carry a client authentication capable EKU, and for each of those, review both the Enrollee Supplies Subject setting and the full enrollment rights ACL. Any template combining requester-supplied identity, an authentication EKU, and broad enrollment rights should be treated as an active ESC1 finding and remediated immediately, either by removing the offending setting, tightening enrollment rights to a genuinely minimal set of principals, or unpublishing the template if it serves no active business need.
2. Harden the web enrollment surface. Apply the ESC8 mitigations described earlier: enabling and requiring Extended Protection for Authentication, disabling NTLM in favor of Kerberos where feasible, and removing the web enrollment role where it is not actually needed. These should be standard configuration rather than an exception applied only after a finding. Because these settings are rarely revisited after initial deployment, a scheduled recurring review is more reliable than a one-time hardening pass.
3. Lock down access control on the CA and PKI objects. This needs the same delegation discipline covered in Chapter 8's DCSync section: know exactly which principals hold ManageCA, ManageCertificates, or write access on template and PKI container objects, and treat membership in those roles with the same scrutiny given to Domain Admins. A dedicated CA administration group, separate from general-purpose administrative groups, with logon restricted to a hardened administrative workstation, keeps CA management from inheriting broad domain privilege it does not need.

This chapter's hardening guidance is really a specific application of a broader model: the Tiered Administration approach that separates infrastructure by sensitivity and restricts credential exposure across tiers. Chapter 11 covers that model in full, including how delegation abuse more generally undermines tiering even when each individual delegation looked reasonable in isolation, and how to design and audit a tiering model that actually holds up against determined privilege escalation attempts, AD CS included.