Active Directory Certificate Services v1 Template EoP — Forged EKU Yields Domain Admin (CVE-2024-49019)
Default version-1 AD CS certificate templates that allow "Supplied in the request" subject names let any user who can enrol issue a certificate as any principal — including a domain administrator. TrustedSec published the "EKUwu" technique. Apply the November 2024 cumulative update and audit templates immediately.
An authenticated low-privilege user — or any compromised user account — can enrol against a vulnerable v1 template, request a certificate as `Administrator@domain.local` with the Client Authentication EKU, and use it to authenticate as Domain Admin. This is a one-shot privilege escalation to full domain compromise that leaves only certificate-issuance audit trails (which most organisations do not actively monitor).
AD CS version-1 certificate templates with "Source of subject name" set to "Supplied in the request" allow the requester to specify both the subject and arbitrary Extended Key Usages (EKUs). If broad enrolment permissions exist on such a template, a low-privilege user can request a certificate bearing the EKUs and subject of a privileged account, then use that certificate to authenticate as that account via PKINIT or schannel. Affected: every Windows Server with AD CS deployed (2008 SP2 through 2025) prior to the November 2024 Patch Tuesday and not properly hardened.
Probably yes if any of these apply:
Affected OS versions
TrustedSec disclosed the AD CS misconfiguration class — including CVE-2024-49019 — under the name "EKUwu" in late 2024. Microsoft's November 2024 update tightens the validation logic, but the long-term fix requires explicit template hardening: removing broad enrolment permissions, adding request signature or certificate-manager approval requirements, and deleting unused v1 templates. AD CS-based privilege escalation chains (ESC1–ESC15) remain the single most productive technique for red teams in Active Directory environments since Certified Pre-Owned (2021).
Manual remediation steps
⏱ 2–4 hours including template review and rebootIdentify vulnerable v1 templates
# On a domain-joined host with the ADCS RSAT module:
Get-CATemplate | Where-Object { $_.Version -eq 1 } |
Select-Object Name, OID, Version
# Use Certify.exe (Ghostpack) or PSPKIAudit to enumerate enrol permissions
# and "Supplied in the request" templates:
Invoke-PSPKIAudit # https://github.com/GhostPack/PSPKIAudit
Apply the November 2024 cumulative update on every AD CS server
CVE-2024-49019 to find the current superseding cumulative for your OSHarden vulnerable templates (required even after patch)
# In the Certificate Templates console (certtmpl.msc):
# 1. For any v1 template still in use, change "Subject Name" tab from
# "Supply in the request" to "Build from this Active Directory information".
# 2. Or remove the template from issuance entirely if not actively required.
# 3. Restrict "Enroll" permissions to specific groups — never to "Authenticated
# Users" or "Domain Users".
# 4. For templates that must allow request-supplied subjects, require
# certificate manager approval or additional request signatures.
Verify
# Confirm AD CS server build is at or above November 2024 level:
(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").UBR
# Re-run PSPKIAudit and confirm no v1 "Supplied in the request" templates
# remain with broad enrol grants.
No tested PowerShell script for this entry yet. We’re prioritising automation based on user demand.
References