Threat Hunting Exercise: Analyzing AD CS ESC1 Certificate Template Abuse Dataset

This hunt covers a modern, high-impact AD attack path: a simulated Windows Security + Certificate Services log dataset (adcs_esc1_certificate_template_abuse_2022-09-08T111500.json) capturing T1649: Steal or Forge Authentication Certificates, where an adversary exploits a misconfigured Active Directory Certificate Services template (the well-known "ESC1" pattern: enrollee-suppliable Subject Alternative Name + client-auth EKU + low-privilege enroll rights) to request a certificate impersonating a Domain Admin account, then authenticates as that account without ever touching its password or hash.

Step 1: Hypothesis Formation

Hypothesis: A low-privileged domain user requests a certificate from a vulnerable template (e.g., a custom "VPN-User" template with CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT enabled), supplying a Subject Alternative Name (SAN) of administrator@theshire.local or another privileged UPN, receives a valid certificate, and uses it (via Rubeus or certreq) to request a Kerberos TGT (PKINIT) as the impersonated privileged account. Indicators:

• Certificate Services log (Event 4886/4887 on the CA, or Security 4768 with certificate-based pre-auth) showing a certificate request/issuance where the requesting account differs from the certificate's Subject/SAN.
• CA event showing issuance from a template with msPKI-Certificate-Name-Flag allowing enrollee-supplied subject (a configuration weakness, not itself an event, but worth confirming during triage).
• Security 4768 (TGT request) shortly after certificate issuance, with CertificateIssuerName/CertificateSerialNumber populated (PKINIT authentication) for the privileged account, originating from the low-privileged user's workstation.
• No corresponding legitimate smartcard/certificate-logon history for that privileged account from that workstation.

Null Hypothesis: Legitimate smartcard/certificate-based authentication rollout for privileged accounts, issued through an approved, properly-scoped template. Invalidate via the requesting principal's identity not matching the certificate subject, and the template's known misconfiguration (enrollee-suppliable SAN combined with broad enroll permissions for low-privilege groups like "Domain Users").

Rationale: AD CS misconfigurations (the ESC1-ESC8 family cataloged by SpecterOps' Certified Pre-Owned research) are now one of the most common paths to domain compromise in real assessments, and complement this series' Kerberoasting and DCSync hunts as a third distinct route to the same objective: acting as Domain Admin.

Step 2: Data Sources and Scope

• Sources: Windows Certificate Services logs (CertificateServicesClient-Lifecycle-System, CA Event 4886/4887); Security (4768 TGT/PKINIT, 4672 special privileges); Sysmon (1 proc create for certreq/Rubeus, 3 net connect to CA on 445/RPC).
• Scope: ~2022-09-08T11:15:00-11:17:30 UTC; Requesting host: WORKSTATION19.theshire.local; Requesting account: jbrown (standard domain user); Impersonated account: administrator@theshire.local; CA: MORDORCA.theshire.local.
• SIEM Queries (Splunk/ELK):
• Subject mismatch: index=certsvc EventID=4887 | where RequesterName!=CertificateSubject
• PKINIT anomaly: index=security EventID=4768 CertificateIssuerName=* | where TargetUserName="administrator" AND IpAddress!="<known admin workstation>"
• Tooling: index=sysmon EventID=1 CommandLine="certreq" OR CommandLine="Rubeus" OR CommandLine="-altname"

Step 3: Key Findings

Parsed events (8 shown) confirm a textbook ESC1 exploitation: certificate request with a spoofed SAN, issuance from a vulnerable template, and successful PKINIT authentication as Administrator.

Validation:

• Timeline: Certificate request → issuance → PKINIT TGT → DCSync-style replication, all within 90 seconds - a fully automated tool chain (Certipy/Rubeus-style), not manual exploration.
• False Positives: jbrown holds no smartcard/PKI enrollment agent role and has no legitimate reason to request a certificate naming a different account's UPN; the VPN-User template was never intended for administrative authentication per its documented purpose.
• Correlation: CertificateSerialNumber ties the certificate request directly to the subsequent PKINIT authentication and all follow-on Administrator-context activity - an unambiguous, fully attributable chain.

Step 4: Recommendations & Next Steps

• Response: Revoke the issued certificate (SerialNumber 3F0A...) immediately via the CA; fix the vulnerable template (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT off, or restrict enrollment rights); reset the krbtgt account twice (standard post-DCSync-exposure procedure); audit all templates for the ESC1-ESC8 misconfiguration family using a tool like Certipy or PSPKIAudit.
• Detection: Sigma: title: AD CS ESC1 Exploitation → selection: EventID=4886 RequesterName != RequestedSAN OR selection: EventID=4768 CertificateIssuerName=* AND TargetUserName in (privileged_accounts) AND IpAddress not in known_admin_hosts.
• Pro Tip: AD CS is frequently deployed once and never re-audited - run a certificate-template misconfiguration audit as a standing quarterly hunt, not just a one-time assessment; template drift (a well-meaning admin adding enrollee-supplied-subject to "make VPN easier") is how these gaps reappear.

Hypothesis confirmed - ESC1 certificate template abuse leading to full domain compromise via certificate-based Administrator impersonation! This is now one of the highest-priority hunts to run in any AD CS-enabled environment, alongside the Kerberoasting and DCSync hunts already in this series.