ADCS Certificate Request Audit: Parsing Logs to Catch Unauthorized Enrollment

Active Directory Certificate Services generates a dense audit trail, but most environments leave at least half of it uncollected. Certificate templates that permit Subject Alternative Name (SAN) overrides, low-approval enrollment, or overly broad enrollment rights are the entry point for privilege escalation chains documented under MITRE ATT&CK T1649 (Steal or Forge Authentication Certificates). Catching abuse before an attacker converts a rogue certificate into a Kerberos TGT requires three things: the right audit policy, a log aggregation pattern that survives CA restarts, and detection logic that keys on behavioral signals rather than just raw event counts.

Enabling the Right Audit Policy on the CA

Windows Server 2022 Certificate Authority audit logging is off by default for several subcategories. Before any SIEM query matters, confirm the CA is emitting the events you need.

Run the following on each CA host:

certutil -setreg CA\AuditFilter 127
net stop certsvc && net start certsvc

The value 127 enables all seven audit flags: Start/Stop, Backup/Restore, Certificate Issued, Certificate Revoked, Certificate Pending, Certificate Denied, and Configuration Change. Many hardening guides only set 6 (Issued and Revoked), which silently drops denied and pending requests. Denied requests are high-signal events for template abuse attempts.

Verify the policy took effect:

certutil -getreg CA\AuditFilter

Also confirm the Windows Advanced Audit Policy subcategory "Object Access > Certification Services" is set to "Success and Failure" on the CA via auditpol /get /subcategory:"Certification Services".

Critical Event IDs and What They Tell You

All ADCS audit events land in Security on the CA host. These are the ones that matter for unauthorized enrollment detection:

For template abuse specifically (ESC1-class attacks), the most actionable pair is 4886 + 4887 where the SAN in the issued certificate differs from the requester's own UPN. That condition means a requester enrolled on behalf of another identity, which is the core of ESC1 exploitation.

Log Aggregation Patterns for Multi-CA Environments

Enterprises running an offline root CA, one or more issuing CAs, and a policy CA face a collection problem: each CA is a separate Windows event source, and WEF (Windows Event Forwarding) subscriptions break silently when the CA service restarts unless you use a push-based collector subscription.

Recommended architecture:

1. WEF push subscription from each CA to a dedicated collector, forwarding only the Security channel filtered to Event IDs 4886-4890 and 4899-4900. Filtering at the source reduces collector load by roughly 80% compared to forwarding the full Security log on a busy issuing CA.
2. Structured enrichment at the collector: parse the Request.RequesterName, Certificate.SerialNumber, Certificate.Template, and Certificate.SubjectPublicKeyInfo fields from the event XML before forwarding to your SIEM. These fields are buried in EventData and most SIEM parsers do not extract them by default.
3. Retention: keep raw CA Security logs for at least 90 days on the collector. Certificate-based persistence is often discovered weeks after initial compromise, and you need the original 4887 events to reconstruct the timeline.

For Splunk environments, the XmlKvMode setting in props.conf extracts ADCS EventData child elements cleanly. For Microsoft Sentinel, the SecurityEvent table captures these events when the CA is onboarded via the Log Analytics agent or AMA, but you must validate the EventData column is populated and not truncated, since the SAN field in 4887 can exceed the default field width in some agent versions.

Detection Rules: Behavioral Logic That Reduces Noise

Raw event volume is a poor signal. A busy issuing CA in a large enterprise can emit thousands of 4887 events per hour during patch cycles. These rule shapes cut through that noise:

Rule 1: SAN mismatch on issued certificate Trigger when the SubjectAltName field in a 4887 event contains a UPN that does not match the RequesterName. This is a near-zero false-positive rule in most environments. Legitimate SAN-override workflows are rare and should be pre-approved and documented.

Rule 2: Template probe pattern Three or more 4888 (denied) events from the same RequesterName against three or more distinct templates within a 10-minute window. Attackers enumerate templates by attempting enrollment and observing denials.

Rule 3: Template ACL change followed by rapid enrollment A 4900 event followed by a 4887 event on the same template within 30 minutes, where the requester in 4887 is not a CA admin. This catches the pattern of an attacker modifying enrollment permissions and immediately exploiting them.

Rule 4: Machine account enrolling a user template A 4887 where RequesterName ends in $ (machine account) but the issued certificate's Subject contains a user UPN. Machine accounts should not be enrolling user certificates; this is a strong indicator of relay-based abuse (ESC8 pattern).

Retrievy's ADCS check surfaces misconfigured templates that make rules 1 and 4 possible in the first place, so detection and posture hardening work together rather than in sequence.

Operationalizing Alerts Without Alert Fatigue

Detection rules are only useful if the alert queue stays actionable. Three practices keep ADCS alerting from drowning your SOC:

• Baseline per template, not per CA. A template used for 802.1X machine authentication will generate thousands of legitimate 4887 events daily. A template used for admin smartcard logon should generate fewer than 20. Set thresholds at the template level.
• Enrich alerts with template ACL state. An alert on a suspicious 4887 is far more actionable if the analyst can immediately see whether the template permits SAN overrides and who has enrollment rights. Pulling this from a nightly certutil -v -dstemplate export and joining it to alert context cuts triage time significantly.
• Suppress known-good service accounts. Certificate auto-enrollment for web servers and domain controllers produces legitimate high-volume 4887 events. Maintain a suppression list of service account UPNs and the templates they are authorized to use, and exclude matching pairs from Rules 1 through 4.

The combination of complete audit policy configuration, structured log aggregation, and behavioral detection logic converts ADCS from a blind spot into a monitored control. Certificate-based attacks are attractive precisely because many environments treat the CA as infrastructure rather than a security-critical system. Treating its audit log with the same rigor as a domain controller's Security event stream closes that gap.