ADCS Threat Hunting Playbook

Most AD CS security guidance is reactive: a vulnerability gets disclosed, a patch ships, and you check whether you were exposed. Threat hunting is the opposite posture, proactively going looking for signs of abuse in your own environment on a schedule, whether or not anything has triggered an alert yet. This is a structured playbook of specific, testable hunt hypotheses across the five areas that matter most: certificate request anomalies, template modifications, CA configuration changes, suspicious enrollments, and the event correlations that tie them together.

This playbook operationalizes the patterns covered in ADCS Attack Path Visualization for Defenders and the event data covered in Microsoft ADCS Event IDs 4886-4889 Explained into actual, repeatable hunts.

TL;DR: Key Takeaways

Threat hunting means investigating on a schedule, not waiting for an alert: every hunt below is something your team should run periodically, independent of whether anything has fired a warning.
The Requester-versus-identity mismatch is the single highest-value signal across nearly every category: it shows up in certificate request anomalies, suspicious enrollments, and event correlation hunts alike, because it’s the common thread behind most certificate-based privilege escalation.
Template and CA configuration changes are infrequent enough that any unexpected one deserves scrutiny, these aren’t high-volume events, which makes anomalies in them unusually low-noise, high-signal findings.
A positive hunt finding is a lead, not a conclusion, escalate it into a full investigation rather than treating the hunt itself as the final word.

How to Use This Playbook

Every hunt below follows the same structure: a specific hypothesis about attacker behavior, the data sources needed to test it, the actual hunt logic, what a positive finding indicates, and the appropriate response. Run each on a defined cadence, document results even when a hunt comes back clean, that clean result is your baseline for detecting future drift.

Hunt Category 1: Certificate Request Anomalies

Hunt 1.1, Requester-to-identity mismatch: hypothesis: a request was submitted by one account but claims an identity, via Subject or SAN, belonging to a different, more privileged account. Data sources: events 4886, 4887, and 4889. Logic: compare the Requester field against Subject and SAN content on every request. A positive finding indicates a documented certificate-based privilege escalation pattern, escalate immediately to a full investigation.
Hunt 1.2, offline template abuse from unexpected accounts: hypothesis: an account without a legitimate need to supply its own subject is enrolling against a template configured to allow it. Data sources: certificate template configuration and issuance events. Logic: cross-reference which accounts have used enrollee-supplied-subject templates against your documented list of accounts that should have that capability. A positive finding indicates either legitimate scope creep worth correcting or active misuse.
Hunt 1.3, denial rate concentration: hypothesis: an account is probing for a template or configuration that will accept a malicious request. Data sources: event 4888 (and correlated 4868), grouped by requester. Logic: flag any account whose denial count over a rolling window significantly exceeds your environment’s baseline. A positive finding indicates active probing behavior worth investigating regardless of whether any single request ultimately succeeded.

Hunt Category 2: Template Modifications

Hunt 2.1, unexpected ACL changes on templates: hypothesis: a principal without a legitimate delegation reason has modified a template’s security descriptor, granting itself or another account enrollment rights. Data sources: Active Directory object change auditing on certificate template objects. Logic: alert on any WriteDACL, WriteOwner, or GenericAll grant appearing on a template outside a documented change window. A positive finding indicates the directory-level escalation path covered in our attack path guidance.
Hunt 2.2, schema or EKU changes on previously safe templates: hypothesis: a template that didn’t previously allow enrollee-supplied subjects or a client authentication EKU has been modified to add either. Data sources: certificate template configuration snapshots, compared against a maintained baseline. Logic: diff current template configuration against your last known-good baseline on a recurring schedule. A positive finding indicates either an undocumented legitimate change or a template being deliberately weakened.
Hunt 2.3, undocumented new templates: hypothesis: a new template has been published to a CA’s issuance list without going through your normal change process. Data sources: certutil -CATemplates output, compared against your documented issuance baseline. Logic: flag any template present in the current issuance list that isn’t in your baseline. A positive finding indicates either a process gap or an unauthorized change.

Hunt Category 3: CA Configuration Changes

Hunt 3.1, dangerous policy flag changes: hypothesis: a CA-wide flag like EDITF_ATTRIBUTESUBJECTALTNAME2 or EDITF_ATTRIBUTEENDDATE has been enabled, either to solve an immediate problem or as part of active compromise. Data sources: CA configuration-change events and periodic certutil -getreg policy\EditFlags checks. Logic: alert on any change to these specific flags, since legitimate use is rare and each one has serious, well-documented downstream risk. A positive finding indicates CA-wide exposure that needs immediate remediation, covered in our SAN extension guide.
Hunt 3.2, reduced audit visibility: hypothesis: someone has lowered the CA’s own AuditFilter setting specifically to reduce the trail their subsequent actions would leave. Data sources: event 4885, which logs changes to the audit filter itself. Logic: alert on any 4885 event, since a legitimate reason to reduce audit scope is rare and this is exactly the kind of self-referential control worth monitoring closely, covered in our audit logging guide. A positive finding demands immediate investigation of everything that happened both before and after the change.
Hunt 3.3, unexpected CA-level permission grants: hypothesis: an account without a legitimate administrative role has been granted Manage CA or Manage Certificates rights directly on the CA object. Data sources: CA security configuration, reviewed against your documented list of authorized administrators. Logic: diff current CA-level permissions against baseline on a recurring schedule. A positive finding indicates a broader exposure than any single template misconfiguration, since it grants control across every template the CA hosts.

Hunt Category 4: Suspicious Enrollments

Hunt 4.1, enrollment agent scope violations: hypothesis: an account holding enrollment agent rights is requesting certificates on behalf of accounts outside its documented, intended scope. Data sources: enrollment agent restriction configuration and certificate issuance events showing the on-behalf-of relationship. Logic: cross-reference actual on-behalf-of requests against the documented list of accounts a given agent should be able to act for. A positive finding indicates the enrollment agent abuse pattern covered in our attack path guidance.
Hunt 4.2, NDES enrollment anomalies: hypothesis: certificates are being issued through NDES without a corresponding, valid challenge password lifecycle, suggesting authentication bypass. Data sources: NDES/CA issuance events correlated against the expected challenge-password request-and-use pattern. Logic: flag successful enrollments that don’t correlate cleanly with a legitimate password generation and single use. A positive finding indicates the kind of tampering covered in our NDES hardening and monitoring guides, most notably EnforcePassword being disabled.
Hunt 4.3, domain controller identity requested through an unexpected path: hypothesis: a certificate carrying a domain controller’s identity was requested by an account or from infrastructure that isn’t that actual domain controller. Data sources: certificate issuance events, correlated with Active Directory computer account creation events and network listener activity on unexpected hosts. Logic: flag any certificate whose Subject or SID resolves to a known domain controller identity where the Requester doesn’t match. A positive finding indicates the exact pattern covered in our guide to determining whether your CA was exploited via Certighost, and should be treated as a potential full domain compromise.

Hunt Category 5: Event Correlations

Hunt 5.1, issuance-to-authentication correlation: hypothesis: a suspicious certificate was actually used for authentication, not just issued. Data sources: event 4887 (issuance) correlated with event 4768 (Kerberos TGT request) where PreAuthType equals 16, indicating certificate-based authentication. Logic: for any certificate flagged by another hunt in this playbook, check whether it was subsequently used to authenticate, and from where. A positive finding significantly raises the severity and urgency of whatever underlying finding triggered the check.
Hunt 5.2, serial number chronology consistency: hypothesis: a certificate’s embedded Request ID doesn’t fit sensibly relative to its claimed issuance date, suggesting database manipulation or a restored/rolled-back database. Data sources: certificate serial numbers, decoded per our serial number generation guide, compared against issuance timestamps. Logic: for any certificate under investigation, confirm its Request ID falls where it should relative to certificates issued immediately before and after it chronologically. A positive finding suggests tampering or an inconsistent restore, worth investigating independently of whatever prompted the original review.
Hunt 5.3, configuration-change-to-issuance timing correlation: hypothesis: a suspicious certificate was issued shortly after a CA or template configuration change that expanded what was possible. Data sources: CA configuration change events (4890-4898 range) cross-referenced against issuance timestamps. Logic: for any certificate flagged elsewhere in this playbook, check whether a configuration change occurred in the preceding hours or days that could explain how it became possible. A positive finding ties a specific change to a specific outcome, which is usually the fastest path to root cause.

Building This Into a Recurring Hunting Program

Run high-frequency hunts (request anomalies, suspicious enrollments) on a tight schedule, weekly or more often, given how quickly certificate issuance volume accumulates in an active environment.
Run lower-frequency hunts (template and CA configuration changes) monthly or quarterly, these change infrequently enough that a tighter cadence adds little value, but any finding at all deserves full attention given how rare legitimate changes to these areas actually are.
Document every hunt’s outcome, including clean results, a documented clean baseline is what makes the next run’s comparison meaningful, this is exactly the discipline covered in our continuous risk assessment guidance.
Define your escalation path before you need it, a positive finding from any hunt in this playbook should move directly into the investigation methodology covered in our CertiGhost and event ID guidance, not sit as an isolated data point.

How Encryption Consulting Can Help

Running this playbook well requires both the AD CS domain knowledge to interpret findings correctly and the operational discipline to execute hunts on a genuine, recurring schedule rather than only after something has already gone wrong.

Encryption Consulting’s PKI Services team supports this directly:

Threat hunting program design: building this playbook’s hunts into your actual SIEM and operational cadence, tailored to your specific hierarchy and templates.
Baseline establishment: documenting your current template, permission, and configuration state as the reference point every future hunt compares against.
Hunt finding investigation support: escalating and working through positive findings with the correlation discipline a real investigation requires.
Detection logic implementation, turning the hunt logic in this playbook into scripted, repeatable queries against your actual data sources.
Ongoing program maturity, integrated into your broader continuous PKI risk assessment practice as new patterns and disclosures emerge.

If you want this playbook actually running against your environment on a real schedule, our PKI Services team can build and operate it with you.

Conclusion

AD CS threat hunting isn’t fundamentally different from hunting anywhere else in your environment, it’s a set of specific, testable hypotheses about how an attacker would actually behave, run proactively rather than waiting for an alert. The five categories here, certificate request anomalies, template modifications, CA configuration changes, suspicious enrollments, and event correlations, cover the ground that matters most, and the Requester-versus-identity mismatch running through nearly all of them is the single highest-value pattern to build detection around first. Run these hunts on a real schedule, document clean results as your baseline, and escalate positive findings into full investigations rather than letting them sit as isolated data points.

Want this threat hunting playbook actually running against your environment? Talk to our PKI Services team about building and operating it. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What is a hunt hypothesis in the context of AD CS threat hunting? A specific, testable statement about a particular way an attacker might abuse AD CS, paired with the exact data sources and logic needed to confirm or rule it out. Unlike waiting for an alert, a hunt hypothesis is investigated proactively, on a schedule, whether or not anything has triggered a warning.

What is the single most useful data field for AD CS threat hunting? The relationship between the Requester field and the Subject or SAN content of a certificate request. A mismatch between who submitted a request and the identity it claims to represent is one of the most reliable, low-noise indicators of certificate-based privilege escalation across nearly every known technique.

How often should AD CS threat hunts be run? On a defined, recurring schedule, not only in response to a specific vulnerability disclosure or incident. Template and CA configuration changes in particular happen infrequently enough that a hunt run monthly or quarterly can catch drift long before it’s exploited.

How is threat hunting different from the detection logic in an AD CS attack path guide? Attack path guidance explains how misconfigurations chain into privilege escalation. A threat hunting playbook turns that understanding into specific, repeatable hypotheses your team actually runs against real data on a schedule, whether or not any alert has fired.

What should happen when an AD CS threat hunt returns a positive finding? Escalate to a full investigation rather than treating the hunt itself as conclusive. A positive finding from a hunt hypothesis is a strong lead, not a confirmed incident, and should be worked through the same evidence-preservation and correlation discipline used in a dedicated incident investigation.