Hardening AD CS: Blue Team Defense Guide
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 --> DomainAccessHardened 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:
## 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 = 2in registryHKLM\SYSTEM\CurrentControlSet\Services\Kdc). This forces the KDC to match certificates against the object'saltSecurityIdentitiesmapping or object SID extension (OID1.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):
## 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#
- Query Active Directory Certificate Services Database: Locate the serial number and request details on the Enterprise CA:
certutil -view -restrict "CertificateTemplate=CustomUserAuth" -out "SerialNumber,RequesterName,CommonName,NotAfter"
- Revoke the Compromised Certificate Immediately:
Revoke the certificate using Reason Code 1 (
CRL_REASON_KEY_COMPROMISE):
certutil -revoke <SERIAL_NUMBER> 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:
certutil -CRL
Phase 2: Active Session Termination & Account Containment#
- 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.
- Audit
altSecurityIdentitieson Target Active Directory Objects: Verify whether the adversary established certificate persistence by writing explicit X.509 mappings to domain user attributes:
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#
- SpecterOps: Certified Pre-Owned - Abusing Active Directory Certificate Services
- Microsoft Security Guidance: KB5014754 - Certificate-based Authentication Changes on Windows Domain Controllers
- Microsoft Learn: Securing PKI - Active Directory Certificate Services Hardening Guidance
- MITRE ATT&CK Technique T1649: Steal or Forge Authentication Certificates
Comments
Post a Comment