Detecting AD CS Abuse (ESC1–ESC8)

AD CS abuse turns a misconfigured certificate template into a path from any domain user to Domain Admin — and it is now a standard step in ransomware playbooks, not just a pentest finding. The SpecterOps “Certified Pre-Owned” research catalogued the escalation paths as ESC1 through ESC8 (since extended to ESC16). Detecting them means auditing certificate-request events that most SOCs never collect, and the fix is template hardening. This guide ships both.

AD CS abuse maps to MITRE ATT&CK T1649 — Steal or Forge Authentication Certificates, yielding T1078 — Valid Accounts. It is the certificate-services sibling of NTLM relay (which feeds ESC8) and Kerberoasting in the Active Directory attack surface.

What is AD CS abuse?

Active Directory Certificate Services issues the certificates a domain uses for authentication. When a certificate template is misconfigured, a low-privileged user can request a certificate that authenticates them as someone far more powerful — up to a domain controller. Because a certificate is a valid authentication credential, the attacker then requests a Kerberos ticket as that identity and owns the domain. No password cracking, no malware — just a certificate request the CA should have refused.

The “Certified Pre-Owned” whitepaper named eight escalation paths; the two you most need to detect are ESC1 (enrollee-supplied subject name) and ESC8 (NTLM relay to web enrollment), both called out by name in the 2024 Five Eyes joint advisory.

What are the main AD CS escalation paths?

The unifying weakness is the template and enrollment configuration: who can request what, and whether the requester controls the identity the certificate asserts. That is exactly what the detection and the hardening target.

The full ESC reference

The catalogue has grown well past the original eight. Most write-ups stop at ESC8, which leaves a long tail of paths that automated auditing tools already check for and that most blue teams have never heard of. Here is the whole set, with what each one actually requires.

Read the right-hand column rather than the numbers. The paths cluster into four owners — the template, the CA configuration, an ACL, and the enrollment service — and each cluster has a different fix and a different person who has to approve it. An audit that reports “ESC1, ESC4 and ESC9 present” is really reporting one finding: nobody owns certificate templates.

Two of these deserve specific attention because they are silent. ESC9 and ESC16 both work by removing the SID security extension — the very mechanism Microsoft added to fix Certifried. A template with CT_FLAG_NO_SECURITY_EXTENSION, or a CA with the extension disabled globally, issues certificates that map by name alone, which quietly re-opens the impersonation path on a fully patched domain. Patching is necessary and not sufficient; the configuration has to hold too.

How to detect AD CS abuse

The signal lives in AD CS audit events — and most environments do not collect them. Turn on Event IDs 4886 (certificate requested) and 4887 (certificate issued); the enhanced versions now include the SAN, template, and requester, which is everything the detection needs.

title: AD CS Certificate Request With Mismatched Subject Alternative Name
id: 9b2f4c81-darkpwn-illustrative
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4886
  san_present:
    Attributes|contains: 'SAN:'
  filter_self:
    SubjectUserName|expand: '%SAN_UPN%'   # SAN matches the requester
  condition: selection and san_present and not filter_self
falsepositives:
  - Legitimate enrollment agents requesting on behalf of users (allowlist them)
level: high

How do you actually turn on certificate auditing?

The most common reason an AD CS detection never fires is that the events do not exist. CA auditing is off by default and needs two separate switches, on the CA itself:

1. Enable the audit filter on the CA. certutil -setreg CA\AuditFilter 127 turns on all auditing categories. The change requires a restart of the Certificate Services service before it takes effect — a step that is skipped often enough to be worth calling out, because the command succeeds and nothing happens.
2. Enable the audit subcategory. Under advanced audit policy, Object Access → Certification Services must be enabled for success. Without it, the CA-side filter produces nothing, and vice versa. Both are required; neither is sufficient.
3. Verify with a test enrollment. Request any certificate and confirm a 4886 and a 4887 appear with the template name and SAN populated. If the SAN field is empty, you are on the older event format and the ESC1 detection cannot work as written.
4. Ship the events off the CA. A CA compromised via ESC7 can clear its own logs. Forwarding is what makes the audit trail survive the attack it is meant to detect.

How do you detect certificate use, not just issuance?

Requests and issuance are half the picture. An attacker who obtained a certificate months ago — or who compromised the CA and issued one without going through the normal request path — leaves nothing in 4886/4887 when they actually use it. The second detection watches authentication.

Event ID 4768 (a Kerberos TGT was requested) includes certificate information fields — issuer, serial number, and thumbprint — whenever PKINIT certificate-based authentication is used. On a typical domain, certificate-based TGT requests are rare and predictable: smart-card users and a small set of service accounts. That makes the anomaly cheap to define.

• Certificate authentication from an account that has never used it. Build a 30-day baseline of which accounts authenticate with certificates. A first-ever certificate TGT for a privileged account is a high-fidelity signal on its own.
• Certificate authentication from an unexpected host. A domain admin’s certificate presented from a workstation rather than a management jump host.
• A TGT request whose certificate serial has no matching 4887. The certificate was issued outside the audited path — which means either auditing was off when it was issued, or the CA itself was used directly. Both are incidents.

That third check is the one worth building. Correlating issuance against use turns two mediocre signals into one strong one, and it catches the CA-compromise case that request monitoring structurally cannot.

How to audit your own AD CS for these paths

Before you detect abuse, find the vulnerable templates in an authorized review:

1. Enumerate templates — certutil -v -template, or run Certipy (certipy find), Locksmith, or PSPKIAudit to flag ESC1–ESC16 automatically.
2. Flag enrollee-supplies-subject templates that also have an authentication EKU and allow low-privileged enrollment.
3. Check web enrollment for NTLM-without-EPA (ESC8) and RPC without packet privacy (ESC11).
4. Confirm patch state for CVE-2022-26923 — both KDC and CA must be patched, and issued certs should carry the SID extension.

Why is detection the secondary control here?

This guide ships a detection, and the detection is not the main control. AD CS abuse is a configuration vulnerability, not a behavioural one, and that changes the economics substantially.

An ESC1 template is exploitable by every domain user, every day, until somebody changes it. A detection tells you it happened; the audit tells you it can happen and lets you remove the path entirely. For most techniques the ratio between those two is debatable. Here it is not: one afternoon with Certipy or Locksmith closes escalation paths that no amount of alerting will prevent, and the finding is a fixed list rather than an ongoing stream.

Two further reasons the alert is weaker than it looks:

• The false-positive profile is genuinely awkward. Enrollment agents legitimately request certificates on behalf of other identities — that is their entire function — and so do NDES/SCEP for device enrollment and some autoenrollment flows for machine certificates. Each is a legitimate SAN mismatch. Allowlisting them is correct and it also carves a hole in exactly the shape of the attack, so the allowlist itself needs review.
• Detection arrives after the credential exists. A certificate is valid for its lifetime, frequently a year or more. By the time the alert fires, the attacker holds a durable credential that survives password resets, which is the specific property that makes this technique attractive to ransomware operators in the first place.

Run the audit first. Then build the detection for what the audit could not remove — the templates a business process genuinely requires, and the possibility that the CA itself is compromised.

How do you respond to a confirmed AD CS escalation?

The instinct is to revoke the certificate. That is necessary and it is not close to sufficient, and the gap is where responses go wrong.

1. Identify what the certificate asserts — the SAN, the template, and the requester. The SAN is the identity the attacker can become, and it determines everything downstream.
2. Revoke the certificate and publish an updated CRL. Do this, but do not treat it as containment: KDC revocation checking for PKINIT is limited in common configurations, and a Kerberos ticket already obtained with that certificate remains valid for its own lifetime regardless of the certificate’s status.
3. Invalidate the tickets, not just the certificate. Any TGT already issued has to age out or be invalidated. If the impersonated identity was a domain controller or a Tier 0 account, assume domain compromise and plan a double krbtgt rotation with the appropriate interval between rotations.
4. Fix the template that allowed it, immediately and before the incident closes. Otherwise the attacker simply re-requests, and the second certificate is indistinguishable from a legitimate enrollment.
5. Audit every certificate issued from that template since the earliest plausible compromise. One abused template usually means several issued certificates, and the others are still valid.
6. Check for ESC7 as a follow-on. An attacker with domain privileges frequently grants themselves ManageCA to establish durable access to the CA, which survives the template fix.
7. Treat the CA as compromised if the abuse path involved CA rights. Rebuilding a CA is a project; discovering six months later that it was never trustworthy is worse.

Step 3 is the one most often missed. Revocation addresses the credential; it does nothing about the authentication that credential already produced, and the attacker’s foothold lives in the second thing.

How to harden AD CS

• Patch CVE-2022-26923 (and CVE-2024-49019) on every CA and DC — KEV-listed.
• Set the machine-account quota to 0 where users have no need to join hosts (limits Certifried).
• Treat the CA as Tier 0 infrastructure, with offline root CA and strict admin separation.

How do you verify the hardening actually held?

AD CS hardening has an unusually bad habit of quietly reverting. Templates get duplicated for a new project and the copy inherits the old settings; a vendor’s installer creates its own template with permissive defaults; someone grants an application team enrollment rights to unblock a deployment. Every one of those is a reasonable action taken by a competent person, and each can reopen a path that was closed six months ago.

Treat verification as recurring rather than as a project close-out:

• Re-run the template audit on a schedule, not once. Certipy and Locksmith are fast enough to run monthly, and the output is diffable — what you care about is the change since last time, not the absolute list.
• Alert on template creation and modification itself. Changes to certificate template objects in AD are rare, high-consequence, and easy to watch. A new template appearing is worth a ticket regardless of who created it.
• Watch enrollment-permission changes, which is the most common way a hardened template becomes exploitable again without the template itself being edited.
• Confirm the SID extension on a sample of recently issued certificates, rather than trusting that the patch level implies it. This is a two-minute check that catches the ESC9 and ESC16 configurations directly.
• Verify auditing is still on after every CA change. Service restarts, migrations, and CA upgrades have all been observed to reset audit configuration, and the failure is silent — the detection simply stops producing events and nobody notices until they need it.

The pattern to internalise is that this attack surface is defined by configuration, and configuration drifts. A control you verified once is a control you believed in once. The teams that keep AD CS closed are the ones that turned the audit into a recurring job with an owner, which costs an hour a month and is the difference between a closed path and a path that was closed in March.

Common AD CS detection mistakes

• No certificate-request auditing. Without Events 4886/4887, the entire attack surface is invisible.
• Auditing requests but not the SAN. Enable the enhanced events that include it.
• Hardening ESC1 but leaving web enrollment. ESC8 stays open.
• Patching only the CA. Certifried needs both KDC and CA patched.
• Enabling auditing on one CA. Multi-tier PKI is normal, and an issuing CA nobody remembered is the one an attacker will find. Audit configuration is per-CA and needs verifying per-CA.
• Leaving the logs on the CA. ESC7 grants an attacker administrative rights over the CA, which includes its event log. Forward the events or lose them exactly when they matter.
• Stopping the audit at ESC8. ESC9 through ESC16 are the paths that survive a patched, hardened-looking environment, and the tooling already checks for them at no extra cost.
• Assuming the Certifried patch worked. Verify that issued certificates actually carry the SID security extension. A template flag or a CA-wide setting can suppress it on a fully patched domain, which is what ESC9 and ESC16 are.
• Monitoring issuance but never authentication. Event 4768 with certificate fields is what catches a certificate issued before your auditing was turned on, or issued by a compromised CA that never generated a 4886.
• Allowlisting enrollment agents and never revisiting it. The allowlist is shaped exactly like the attack. It needs an owner and a periodic review, not a one-time exception.
• Treating revocation as containment. The certificate is revoked; the Kerberos ticket it produced is not, and that ticket is the attacker’s actual access.

AD CS abuse detection checklist

1. Enable AD CS audit Events 4886 and 4887 (enhanced, with SAN) on every CA.
2. Alert on certificate requests where the SAN does not match the requester (ESC1).
3. Alert on NTLM authentication to the web enrollment interface (ESC8).
4. Audit all templates with Certipy/Locksmith/PSPKIAudit for ESC1–ESC16.
5. Harden templates: no enrollee-supplied SAN, manager approval, no Any Purpose EKU.
6. Enforce KB5014754 strong certificate binding (Full Enforcement).
7. Remove web enrollment or enforce HTTPS + EPA; patch CVE-2022-26923 on CA and DC.
8. Treat the CA as Tier 0; set machine-account quota to 0 where appropriate.

The takeaway

Detecting AD CS abuse means turning on certificate-request auditing (Events 4886/4887 with the SAN) and alerting on the ESC1 SAN mismatch and ESC8 web-enrollment relay, while hardening templates and enforcing strong certificate binding. Audit your own templates first. Continue with NTLM relay detection, Kerberoasting and detecting DCSync attacks, or browse the full Detection Engineering pillar.