Inside AD CS Escalation: Unpacking Advanced Misuse Techniques and Tools

How template misconfigurations and shadow credentials are redefining privilege escalation in modern PKI infrastructure

Executive Summary

Active Directory Certificate Services (AD CS) remains a foundational component of Windows enterprise infrastructure, managing the public key infrastructure (PKI) that underpins authentication and encryption across networks. Despite its critical role, AD CS is frequently undermined by insecure default configurations and inherent design complexities, creating a high-impact attack surface that is often under-monitored by security teams. Recent analysis from Unit 42 and Cyber Security Review highlights that adversaries are increasingly leveraging template misconfigurations and shadow credential misuse to escalate privileges and impersonate privileged accounts.

Unlike traditional exploitation vectors that rely on zero-day vulnerabilities or complex malware payloads, AD CS attacks predominantly exploit native certificate issuance mechanisms. By abusing overly permissive enrollment rights and misconfigured templates, attackers can issue certificates for high-value targets, establish persistence, and move laterally with minimal detection. These weaknesses are actively being weaponized by both financially motivated ransomware groups and state-sponsored actors, making AD CS a pivotal vector in modern threat campaigns.

Attack Surface

High-Impact

Misconfigured templates and enrollment rights enable rapid privilege escalation.

Detection Gap

Under-Monitored

Native certificate issuance often bypasses traditional endpoint and network controls.

Threat Actors

Ransomware & APTs

Financially motivated and state-sponsored groups actively exploit AD CS weaknesses.

Technical Analysis

The exploitation of AD CS centers on the abuse of certificate templates and enrollment permissions. Unit 42's analysis identifies two primary techniques: template misconfigurations and shadow credential misuse. These techniques allow attackers to issue certificates that grant access to domain controllers, enterprise admins, or other privileged entities without requiring their passwords.

Root Cause: Design Complexity and Default Configurations

AD CS suffers from a complex design where certificate templates define the properties of issued certificates, including enrollment permissions, key usage, and subject alternatives. Insecure default configurations, such as the SubCA and DomainController templates, often have Enroll permissions granted to Authenticated Users. This allows any domain user to request a certificate for these templates, provided the template is enabled and not expired.

Additionally, the introduction of shadow credentials allows an attacker to add a key to an object without knowing the current password. This technique bypasses the need for the msDS-KeyCredentialLink attribute to be writable by the user, enabling privilege escalation even when password changes are restricted.

Attack Chain Execution

The exploitation chain typically follows a sequence of reconnaissance, template abuse, and certificate issuance. The following table outlines the key steps in the AD CS escalation chain.

AD CS Escalation Execution Chain

Key steps from reconnaissance to privilege escalation

1. Reconnaissance	Identify enabled templates with permissive enrollment rights using tools like `certify.exe` or `certipy.exe`.
2. Template Misconfiguration	Abuse templates with `msPKI-Certificate-Name-Flag` set to `ENROLLEE_SUPPLIES_SUBJECT` or `msPKI-Enrollment-Flag` allowing user enrollment.
3. Shadow Credential Misuse	Add a key to a target object using `msDS-KeyCredentialLink` to enable password-less authentication.
4. Certificate Issuance	Request and receive a certificate for the target user or computer, leveraging the misconfigured template or shadow credential.
5. Privilege Escalation	Use the certificate to authenticate as the privileged account, gaining access to domain controllers or sensitive services.

Key Configuration Parameters

Several AD CS configuration parameters play a critical role in enabling exploitation:

msPKI-Certificate-Name-Flag: Controls the subject name requirements. Values like ENROLLEE_SUPPLIES_SUBJECT allow the requester to specify the subject, enabling impersonation.
msPKI-Enrollment-Flag: Determines enrollment permissions. Flags such as INCLUDE_SYMMETRIC_ALGORITHMS can allow weaker key exchange methods.
msPKI-Certificate-Policy: Defines the policies associated with a template. Misconfigurations here can allow unauthorized policy enrollment.

Identify Vulnerable Templates. Use certipy find to list templates with Enroll permissions for Authenticated Users.
Check Template Properties. Verify msPKI-Certificate-Name-Flag and msPKI-Enrollment-Flag for exploitable settings.
Test Shadow Credentials. Attempt to add a key to a target user using certipy shadow auto to confirm shadow credential abuse.
Request Certificate. Issue a certificate for the target using the identified template or shadow credential.
Authenticate. Use the certificate to authenticate via kerberos or s4u2self for further escalation.

Impact Assessment

The impact of AD CS exploitation extends beyond simple privilege escalation. By issuing certificates for privileged accounts, attackers can impersonate domain admins, enterprise admins, or even the domain controller itself. This enables unauthorized access to critical services, data exfiltration, and long-term persistence.

Unit 42 observations indicate that these weaknesses are actively exploited by financially motivated ransomware groups and state-sponsored actors. Ransomware groups use AD CS to quickly escalate privileges and encrypt critical systems, while APTs leverage certificate-based persistence to maintain access over extended periods.

Defender Advantages

Behavioral detection can identify anomalous enrollment requests.
Shadow credential monitoring reveals unauthorized key additions.
Template auditing allows proactive identification of misconfigurations.

Attacker Gains

Native certificate issuance bypasses many endpoint detection tools.
Shadow credentials enable password-less authentication.
Template misconfigurations allow impersonation of high-value targets.

Detection & Response

Effective detection of AD CS exploitation requires monitoring enrollment events, certificate usage, and shadow credential additions. Unit 42 emphasizes behavioral detection as a key strategy for identifying AD CS attacks.

Indicators of Compromise (IOCs)

Unusual Enrollment Requests: High volume of certificate requests from a single user or computer.
Shadow Credential Additions: New keys added to msDS-KeyCredentialLink attribute.
Certificate Usage: Certificates used for authentication to domain controllers or critical services.
Template Abuse: Enrollment of templates with ENROLLEE_SUPPLIES_SUBJECT flag.

Illustrative Detection Rules

A single rule cannot cover the AD CS attack surface — the techniques in the chain above leave fingerprints in at least four different Windows event sources (DC security log, CA operational log, Kerberos logon log, endpoint process telemetry). The Sigma-style rules below pair each escalation primitive with the high-fidelity event it generates, plus the false-positive filters and tuning guidance needed to keep them deployable. All rules are illustrative and should be baselined against legitimate Windows Hello for Business activity and your CA enrollment cadence before production use.

Logging prerequisites: Confirm that Audit Directory Service Changes (subcategory) is enabled on domain controllers and that the CA role’s Microsoft-Windows-CertificationAuthority/Operational channel is forwarded to your SIEM. By default, neither is collected and these rules will be silent until both are turned on.

Rule 1 — Shadow credential write to msDS-KeyCredentialLink (DC Event ID 5136). This is the canonical detection for the Whisker / ntlmrelayx --shadow-credentials / certipy shadow auto primitive. The high-signal anomaly is a third-party principal writing the attribute — not the target object writing its own key (the legitimate Windows Hello for Business pattern).

title: Shadow Credentials Added to AD Object (msDS-KeyCredentialLink)
id: a3c1f5d8-adcs-shadow-cred-add
status: experimental
description: >
  Detects a write to the msDS-KeyCredentialLink attribute that is not
  consistent with legitimate Windows Hello for Business enrollment.
  Adversaries (Whisker, ntlmrelayx --shadow-credentials, certipy shadow)
  add a key credential to a target principal to obtain a Kerberos TGT
  via PKINIT without knowing the target's password.
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5136
    AttributeLDAPDisplayName: msDS-KeyCredentialLink
    OperationType: '%%14674'        # "Value Added"
  filter_self_enroll:
    # Legitimate WHfB: the target object writes its own key (subject == target).
    SubjectUserName|fieldref: ObjectDN
  filter_known_whfb_service:
    SubjectUserSid: 'S-1-5-18'          # NT AUTHORITY\SYSTEM on the user's own host
    ObjectClass: user
  condition: selection and not (filter_self_enroll or filter_known_whfb_service)
fields:
  - SubjectUserName
  - SubjectDomainName
  - ObjectDN
  - OperationType
falsepositives:
  - WHfB enrollment with a non-default identity provider topology — baseline first.
  - Administrative resets of WHfB credentials by a help-desk tier.
level: high
tags:
  - attack.credential_access
  - attack.privilege_escalation
  - attack.t1556.005           # Modify Authentication Process: Reversible Encryption / KeyCredential
  - attack.t1649               # Steal or Forge Authentication Certificates
references:
  - https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab
  - https://github.com/eladshamir/Whisker

Rule 2 — PKINIT TGT request that follows a shadow-credentials write (DC Event ID 4768 with CertificateIssuerName populated). The certificate gets used here, typically within seconds-to-minutes of the credential add. Correlating 4768 PKINIT events against the prior 5136 stream gives you the full kill chain rather than two isolated anomalies.

title: Kerberos PKINIT Pre-Auth to High-Value Account
id: 7b2e1990-adcs-pkinit-priv
status: experimental
description: >
  Detects a Kerberos AS-REQ that was authenticated by certificate (PKINIT)
  for a high-value principal. After shadow-credentials abuse or ESC1/ESC8
  template misuse, the attacker authenticates by presenting the new
  certificate — this rule catches the use, not the issuance.
logsource:
  product: windows
  service: security
detection:
  pkinit_auth:
    EventID: 4768
    CertificateIssuerName|exists: true       # PKINIT was used
  high_value_target:
    TargetUserName|contains:
      - 'admin'
      - 'da-'
      - 'ea-'
      - 'svc-tier0'
      - 'krbtgt'
  # Tune: replace the contains list with an explicit list of Tier-0 SAMAccountNames
  # taken from your tiering model. Smartcard-logon users for those accounts should
  # be enumerated and excluded by CertificateSerialNumber.
  condition: pkinit_auth and high_value_target
fields:
  - TargetUserName
  - CertificateIssuerName
  - CertificateSerialNumber
  - IpAddress
falsepositives:
  - Tier-0 staff using smartcards — baseline by CertificateSerialNumber.
level: high
tags:
  - attack.credential_access
  - attack.lateral_movement
  - attack.t1649

Rule 3 — Certificate template created or modified (CA Event IDs 4898–4900). ESC1-style template weaponization requires an attacker (or a coerced PKI admin) to flip ENROLLEE_SUPPLIES_SUBJECT, grant Enroll to Authenticated Users, or relax client authentication EKUs. Any template change outside an approved maintenance window deserves investigation.

title: AD CS Certificate Template Created or Modified
id: f08c6f12-adcs-template-mod
status: experimental
description: >
  Detects creation, modification, or security-descriptor change on an AD CS
  certificate template. Templates are the policy backbone of CA enrollment;
  unauthorized changes are the lead indicator of ESC1/ESC2/ESC3 weaponization.
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID:
      - 4898   # Template loaded
      - 4899   # Template updated
      - 4900   # Template security descriptor updated
  filter_maintenance_window:
    # Suppress during sanctioned change windows — wire your CMDB / change-ticket system
    # into this filter rather than hard-coding times.
    ChangeApproved: true
  condition: selection and not filter_maintenance_window
fields:
  - SubjectUserName
  - TemplateName
  - TemplateOID
level: medium
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1649

Rule 4 — ESC1 high-fidelity: certificate issued whose SAN does not match the requester (CA Event ID 4887). This is the smoking gun for ESC1: an unprivileged principal authenticates to the CA, and the issued certificate names a different (privileged) account in the Subject Alternative Name. The match runs on the CA’s Microsoft-Windows-CertificationAuthority/Operational channel, which captures the issued SAN value.

title: AD CS Certificate Issued with SAN Mismatching Requester (ESC1)
id: 2a91ee44-adcs-esc1-san-mismatch
status: experimental
description: >
  Detects a certificate issued whose Subject Alternative Name (UPN, dNSName, or
  otherName) does not match the requesting principal. This is the canonical
  signal for ESC1 abuse: the attacker uses ENROLLEE_SUPPLIES_SUBJECT to request
  a certificate naming Administrator, krbtgt$, or another Tier-0 account while
  authenticated as a low-privilege user.
logsource:
  product: windows
  service: Microsoft-Windows-CertificationAuthority/Operational
detection:
  cert_issued:
    EventID: 4887                # Certificate Services issued a certificate
  # Field-correlation pseudocode: implement in your SIEM's DSL.
  # Splunk: where like(RequesterName, "%" . SubjectAltName_UPN . "%") = 0
  # KQL:    where not (RequesterName has SubjectAltName_UPN)
  condition: cert_issued and RequesterName != SubjectAltName_UPN
fields:
  - RequesterName
  - SubjectAltName_UPN
  - TemplateName
  - CertificateSerialNumber
falsepositives:
  - A small set of legitimate service-account templates allow SAN override —
    enumerate those templates explicitly and exclude by TemplateName.
level: high
tags:
  - attack.privilege_escalation
  - attack.t1649

Rule 5 — Endpoint tool indicators (Microsoft Defender for Endpoint / Sentinel KQL). The escalation primitives are usually executed from a foothold endpoint. Catching the tooling on that endpoint — certify.exe, certipy, Whisker, PSPKIAudit — gives the SOC a hunt that fires before any DC-side telemetry shows the attack.

// AD CS attack-tool indicators on endpoints — KQL (Defender for Endpoint / Sentinel)
DeviceProcessEvents
| where Timestamp > ago(30d)
| where ProcessCommandLine has_any (
    "certify.exe", "Certify.exe",
    "certipy", "Certipy",
    "Whisker", "ShadowCred",
    "PSPKIAudit", "Get-CertificateTemplate",
    "msDS-KeyCredentialLink",
    @"certutil -enrolPolicyServer",
    @"certutil -urlcache",
    @"Add-ADComputerServiceAccount"
  )
| where not (InitiatingProcessFileName in ("MsSense.exe", "MpCmdRun.exe"))
| project Timestamp, DeviceName, AccountName, FileName,
          ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Correlation guidance for the SOC analyst:

The chain detection that matters most: a Rule 1 (shadow-cred write to msDS-KeyCredentialLink) followed within ~10 minutes by a Rule 2 (PKINIT TGT for the same target). The two events on their own are noisy; the sequence is high-confidence compromise.
For ESC1: a Rule 5 (certify.exe / certipy on an endpoint) followed by a Rule 4 (SAN mismatch on the CA) is the deterministic ESC1 chain. Either alone warrants triage; together, they warrant containment.
Time-of-day baselining matters. Most AD CS-relevant administrative activity (template changes, CA service restarts, WHfB enrollment) clusters during business hours. Anomalies are far more meaningful at 02:00 local.
Pair with certipy find -vulnerable output on a regular cadence. Detection without a clean baseline of which templates are exploitable today means analysts can’t triage the alerts. Re-run weekly and feed the vulnerable template list into Rule 4’s allow/deny logic.

"Behavioral detection for defenders is critical to identifying AD CS attacks that rely on native certificate issuance." — Unit 42

Mitigation & Remediation

Remediating AD CS vulnerabilities involves reviewing template configurations, restricting enrollment rights, and monitoring for shadow credential misuse. The following actions should be prioritized by security teams.

Audit Certificate Templates. Regularly review templates for permissive enrollment rights and exploitable flags.
Restrict Enrollment Permissions. Remove Enroll permissions from Authenticated Users where possible.
Enable Shadow Credential Monitoring. Monitor msDS-KeyCredentialLink attribute changes for unauthorized key additions.
Implement Certificate Revocation. Ensure CRL and AIA configurations are correct to allow timely revocation of compromised certificates.
Deploy Behavioral Detection. Use SIEM or EDR tools to detect anomalous enrollment and authentication patterns.

Strategic Context

As organizations continue to adopt digital transformation strategies, the intersection of cybersecurity and compliance creates a complex landscape where AD CS plays a pivotal role. The SEC's new cybersecurity disclosure rules, mandating a four-day reporting window for material incidents, place additional pressure on security teams to quickly identify and respond to AD CS attacks. Effective incident response requires the ability to rapidly analyze certificate enrollment data and determine the impact of compromised certificates.

Strategic Insight

AD CS: The Identity Backbone Under Siege

AD CS is no longer just a PKI component; it is a critical identity backbone that, when misconfigured, can undermine the entire enterprise security posture. The shift towards native certificate issuance exploitation highlights the need for defenders to move beyond traditional vulnerability management and embrace behavioral detection and template auditing.

As ransomware groups and APTs continue to weaponize AD CS weaknesses, organizations must prioritize AD CS hygiene, enforce least-privilege enrollment, and monitor for shadow credential abuse to maintain a robust defense-in-depth strategy.

Timeline

2026-05-11

AD CS Analysis Published. Unit 42 and Cyber Security Review publish analysis on AD CS escalation techniques.

2026-05-12

Article Visibility. Cyber Security Review post becomes widely visible, highlighting template misconfigurations and shadow credentials.

2026-05-14

Linux Kernel Vulnerability. New vulnerability discovered in Linux kernel, exposing systems to elevated privilege execution.

2026-05-15

OpenAI TanStack Compromise. Attackers steal internal credentials and rotate signing certificates for desktop products.

Karma-X Blog