Hardening AD CS: Blue Team Defense Guide

Article Hero

Overview & Defensive Context#

In this morning's offensive breakdown, we demonstrated how adversaries exploit Active Directory Certificate Services (AD CS) ESC1 to achieve instant domain escalation. When an Enterprise Certificate Authority (CA) publishes certificate templates configured with Client Authentication Extended Key Usages (EKUs) and the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag, unprivileged domain users can request certificates specifying arbitrary Subject Alternative Names (SANs) such as Administrator@corp.local. Armed with the forged certificate, attackers initiate Kerberos PKINIT (RFC 4556) to harvest administrative Ticket Granting Tickets (TGTs) and domain controller NT hashes.

Standard endpoint detection and response (EDR) agents and perimeter firewalls frequently fail to intercept ESC1 abuse because the entire attack leverages legitimate Windows management protocols (MS-WCCE over RPC/DCOM) and native Kerberos authentication. Furthermore, because the issued certificate originates from a trusted Enterprise CA listed in NTAuthCertificates, the Domain Controller treats the resulting PKINIT exchange as an authorized smart card logon.

[!IMPORTANT] Defending Active Directory PKI against ESC1 requires eliminating enrollee-supplied subject flags on authentication-capable templates, restricting enrollment DACLs to tightly scoped security groups, enforcing CA manager approval gates, and deploying real-time detection rules across Windows Event IDs 4887 (Certificate Issued) and 4768 (Kerberos TGT Request).


Architecture Hardening: Multi-Layered AD CS Defense Pipeline#

Hardening AD CS demands establishing verification gates across template definitions, enrollment authority policies, and Kerberos KDC certificate mapping configurations.

flowchart TD
    subgraph EnrollmentBoundary [Client Enrollment Ingress]
        EnrolleeRequest["Client Certificate Signing Request (CSR)"]
        DACLCheck{"Template DACL Check: Permitted Group?"}
        DropUnauthorized["Reject: Access Denied (E_ACCESSDENIED)"]
    end

    subgraph PolicyEngine [CA Template Policy Engine]
        SubjectFlagCheck{"msPKI-Certificate-Name-Flag: Supplies Subject?"}
        SanitizeSubject["Force Subject from Active Directory Attributes"]
        ApprovalGate{"Manager Approval Required?"}
        HoldPending["Hold in CA Pending Queue (CT_FLAG_PEND_ALL_REQUESTS)"]
    end

    subgraph IssuanceAndAuth [Issuance & Kerberos Validation]
        CAIssue["Enterprise CA Signs Certificate with Strong Mapping"]
        KDCAuth{"KDC PKINIT Validation (KB5014754 / Full Enforcement)"}
        DomainAccess["Authorized Domain Kerberos Session"]
    end

    EnrolleeRequest --> DACLCheck
    DACLCheck -->|Unprivileged Enrollee Blocked| DropUnauthorized
    DACLCheck -->|Authorized Enrollee| SubjectFlagCheck
    SubjectFlagCheck -->|CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT Detected| SanitizeSubject
    SanitizeSubject --> ApprovalGate
    ApprovalGate -->|Approval Required| HoldPending
    ApprovalGate -->|Pre-Approved Template| CAIssue
    CAIssue --> KDCAuth
    KDCAuth --> DomainAccess

Hardened Template & PKI Configurations#

To remediate vulnerable templates, administrators must modify Active Directory schema attributes via PowerShell and the Certificate Templates MMC console (certtmpl.msc).

1. Stripping Enrollee Supplies Subject via PowerShell#

The following PowerShell command removes the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bitmask (0x00000001) from target templates, forcing the CA to construct the Subject and SAN exclusively from Active Directory directory attributes:

POWERSHELL
## Import Active Directory module and query vulnerable template
Import-Module ActiveDirectory

$TemplateName = "CustomUserAuth"
$TemplateDN = "CN=$TemplateName,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local"

## Read current certificate name flags
$CurrentFlags = (Get-ADObject -Identity $TemplateDN -Properties "msPKI-Certificate-Name-Flag")."msPKI-Certificate-Name-Flag"

## Bitwise AND with inverted 0x1 to clear CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT
$NewFlags = $CurrentFlags -band (-bnot 0x00000001)

## Set flag: Subject will now be populated from Active Directory
Set-ADObject -Identity $TemplateDN -Replace @{"msPKI-Certificate-Name-Flag" = $NewFlags}
Write-Host "[+] Successfully remediated msPKI-Certificate-Name-Flag on $TemplateName"

[!TIP] Ensure that Microsoft security update KB5014754 is configured in Full Enforcement Mode (StrongCertificateBindingEnforcement = 2 in registry HKLM\SYSTEM\CurrentControlSet\Services\Kdc). This forces the KDC to match certificates against the object's altSecurityIdentities mapping or object SID extension (OID 1.3.6.1.4.1.311.25.2), neutralizing unmapped SAN impersonation.


Production Detection Queries#

Security Operations Centers (SOC) must correlate CA issuance logs with Domain Controller Kerberos authentication telemetry to detect forged certificate usage.

1. Production Sigma Rule: Suspicious AD CS Certificate Issuance with Mismatched SAN#

The following Sigma rule detects Windows Event ID 4887 on the Certificate Authority when a certificate is issued with a Subject Alternative Name differing from the requesting account:

title: Suspicious AD CS Certificate Issued with Mismatched Subject Alternative Name
id: c3d1e2f4-8a9b-4c5d-9e1f-7b6a5c4d3e21
status: production
description: Detects certificate issuance via AD CS where the requester user identity does not match the Subject Alternative Name attributes.

references:
  - https://posts.specterops.io/certified-pre-owned-d95910965cd2
  - https://attack.mitre.org/techniques/T1649/
logsource:
  product: windows
  service: security
detection:
  selection_event:
    EventID: 4887 # Certificate Services approved and issued a certificate
  selection_template:
    Attributes|contains:
      - 'CertificateTemplate:CustomUserAuth'
      - 'CertificateTemplate:User'
  selection_san:
    Attributes|contains:
      - 'san:'
      - 'upn='
  filter_machine_auto:
    Requester|endswith: '$'
  condition: selection_event and selection_template and selection_san and not filter_machine_auto
falsepositives:
  - Legitimate automated provisioning agents requesting certificates on behalf of users (NDES / SCEP)
level: high
tags:
  - attack.credential_access
  - attack.privilege_escalation
  - attack.t1649

2. Detecting PKINIT Authentication Anomalies (Event ID 4768)#

On Domain Controllers, monitor for Kerberos TGT requests using PKINIT (PreAuthType: 16or17):

POWERSHELL
## Query Domain Controller security event log for PKINIT logons
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4768
} | Where-Object {
    $_.Properties[4].Value -eq 16 -and $_.Properties[0].Value -eq 'Administrator'
} | Select-Object TimeCreated, @{N='User';E={$_.Properties[0].Value}}, @{N='IP';E={$_.Properties[9].Value}}

Enterprise Mitigation Matrix#

Securing enterprise Active Directory PKI requires combining template hardening, cryptographic binding, and administrative enrollment gating:

Defense Control Technical Implementation Operational Blast Radius Performance Overhead Security Guarantee
Clear ENROLLEE_SUPPLIES_SUBJECT Configure msPKI-Certificate-Name-Flag to build subject from AD attributes Low (ensures user certificates match authenticated callers) Zero runtime overhead Eliminates arbitrary UPN/SAN spoofing on user templates
KB5014754 Full Enforcement Enforce strong certificate mapping (StrongCertificateBindingEnforcement = 2) Moderate (requires auditing older machine certificates for SID extensions) Zero Prevents authentication if certificate lacks valid SID mapping or explicit altSecurityIdentities
Enrollment DACL Restructuring Remove Domain UsersandAuthenticated Users from template permissions Low (restricts enrollment to specific security groups) Zero Prevents unauthorized accounts from generating certificate requests
CA Manager Approval Gate Enable CT_FLAG_PEND_ALL_REQUESTS on sensitive authentication templates Moderate (introduces manual or automated approval step) Administrative latency Stops automated instant credential harvesting by holding requests in pending state

Incident Response & Verification Playbook#

When an alert flags an unauthorized ESC1 certificate issuance, incident responders must execute this containment and revocation playbook:

Phase 1: Rapid Triage & Certificate Revocation#

  1. Query Active Directory Certificate Services Database: Locate the serial number and request details on the Enterprise CA:
BASH
certutil -view -restrict "CertificateTemplate=CustomUserAuth" -out "SerialNumber,RequesterName,CommonName,NotAfter"
  1. Revoke the Compromised Certificate Immediately: Revoke the certificate using Reason Code 1 (CRL_REASON_KEY_COMPROMISE):
BASH
certutil -revoke <SERIAL_NUMBER> 1
  1. Publish an Immediate Certificate Revocation List (CRL): Force the CA to publish an updated Base and Delta CRL to LDAP and HTTP distribution points:
BASH
certutil -CRL

Phase 2: Active Session Termination & Account Containment#

  1. Reset the Target Administrator Account Password Twice: Performing two consecutive password resets invalidates the Kerberos Ticket Granting Service keys (KRBTGT) and flushes existing Kerberos ticket validation.
  2. Audit altSecurityIdentities on Target Active Directory Objects: Verify whether the adversary established certificate persistence by writing explicit X.509 mappings to domain user attributes:
POWERSHELL
Get-ADUser -Identity "Administrator" -Properties altSecurityIdentities | Select-Object altSecurityIdentities

[!CAUTION] Revoking a certificate in AD CS does not automatically terminate active Kerberos TGT sessions previously issued by the KDC. Defenders must purge active Kerberos tickets and reset target account passwords to sever active access.


Authoritative Technical References#

Comments