How do you detect AD CS ESC1?

Detect AD CS ESC1 by enabling CA auditing and joining issuance to use. On the CA, review Event 4887 and the CA database for certificates whose requester differs from the subject alternative name. On the Domain Controller, look for 4768 events with pre-authentication type 16 (PKINIT) for privileged accounts and match the certificate serial to the issuance. Alert on 5136 changes to template flags such as msPKI-Certificate-Name-Flag, and fix the templates themselves with approval or removal of the enrollee-supplied subject.

Detecting AD CS ESC1: Certificate Templates That Let You Choose Who You Are

In an ESC1 attack, a low-privilege user enrolls in a template where the enrollee supplies the subject alternative name, then uses the certificate to authenticate as a privileged account. The issuance is logged on the CA, and the use is logged on the Domain Controller. Joining the two gives a reliable detection if CA auditing is on.

Signals at a Glance

Signal	Where	ATT&CK
Certificate issued where requester differs from the SAN identity	CA 4886 / 4887, CA database	T1649
Request attributes carrying SAN:upn or SAN:dns	CA Security 4887	T1649
PKINIT TGT request (pre-auth type 16) for a privileged account from a workstation	DC Security 4768	T1649
Template flag changes that let the enrollee supply the subject	DC Security 5136	T1649
Template with client-auth EKU, low-privilege enroll and no approval	Certify, Certipy, PSPKIAudit	T1649

CA Issuance and the PKINIT Logon

Enable CA auditing for certificate requests and issued certificates first; without it the CA is silent. Event ID 4887 (certificate services approved a request and issued a certificate) lists the requester, request attributes and subject. The subject alternative name usually lives in the certificate extensions, so pull it from the CA database as well; the attributes field only shows a SAN that was passed as a request attribute. Start with the log view:

SecurityEvent
| where EventID == 4887 and Computer has "CA"   // tune/validate: your CA hostnames
| extend d = parse_xml(EventData).EventData.Data
| mv-apply item = d on (
    summarize kv = make_bag(bag_pack(tostring(item["@Name"]), tostring(item["#text"]))))
| extend Requester = tostring(kv.Requester), Attributes = tostring(kv.Attributes),
         Subject = tostring(kv.Subject), RequestId = tostring(kv.RequestId)
| where Attributes has "SAN:" or Attributes has "san:"
| project TimeGenerated, Computer, RequestId, Requester, Subject, Attributes
// tune/validate: confirm the field names against one of your own 4887 events.

The strongest corroboration is on the Domain Controller. A certificate used for logon produces a 4768 with pre-authentication type 16 and the certificate serial. Match the serial to the issuance, then compare the account that logged on with the account that requested:

SecurityEvent
| where EventID == 4768 and PreAuthType == "16"
| project LogonTime = TimeGenerated, DC = Computer, Account = TargetUserName,
          SrcIp = IpAddress, CertIssuerName, CertSerialNumber
// Join to the CA export of Requester by serial number: a privileged Account
// whose certificate was requested by a different identity is the ESC1 signature.
// tune/validate: exclude smart-card logons by known admin workstations.

Template Changes and Hygiene

Fix the cause as well as detecting the use. Changes to template flags are directory writes, so they appear as 5136 when change auditing is enabled on the Certificate Templates container:

title: Certificate Template Allows Enrollee-Supplied Subject
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5136
    ObjectClass: 'pKICertificateTemplate'
    AttributeLDAPDisplayName:
      - 'msPKI-Certificate-Name-Flag'
      - 'msPKI-Enrollment-Flag'
      - 'pKIExtendedKeyUsage'
  condition: selection
level: high
# tune/validate: review every hit; the dangerous state is the
# ENROLLEE_SUPPLIES_SUBJECT bit together with a client-authentication EKU.

Audit templates regularly with Certify, Certipy or PSPKIAudit and remove enrollment rights from broad groups.
Turn on manager approval or remove the enrollee-supplied subject flag on any template with a client-authentication EKU.
Enable Audit Certification Services on every CA and forward the events with the rest of your Security logs.

Vetted sources

Use the SigmaHQ and Elastic AD CS rules, the Splunk ESCU certificate-services analytics, SpecterOps Certified Pre-Owned research and Microsoft’s AD CS hardening guidance. Baseline your own environment — auto-enrollment and device certificates produce many 4887 events, so scope alerts to client-authentication templates and privileged SANs.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

CA Issuance and the PKINIT Logon

Template Changes and Hygiene

Build Detections That Fire

Active Directory Attack Detection

Detection Hub

AD CS ESC8 Detection