Key takeaways
- ESC1 is a misconfigured AD CS template that lets a low-privilege user enrol and supply an arbitrary subject, so they can request a certificate that names any account.
- Because the certificate carries a client authentication purpose, the attacker presents it to a domain controller and receives a Kerberos ticket as a domain admin, with no password reset and no exploit code.
- Five template conditions have to line up at once. Break any one and the chain fails; the enrollee-supplied subject flag is the setting to remove first.
- The entire path runs from a standard domain user, which is why it is a routine and high-impact finding on an internal infrastructure test.
A template that trusts the requester to name the account
Active Directory Certificate Services issues certificates that Windows treats as identity. A certificate that carries a client authentication purpose can be presented to a domain controller in place of a password, through the Kerberos PKINIT extension. ESC1 is the name for a certificate template that lets the wrong person decide whose identity a certificate carries.
This is not a software bug and there is no CVE for it. It is a configuration a template can be published with, and it turns one low-privilege domain account into a domain admin without touching a password or running exploit code. On an internal infrastructure pentest it is among the first things worth checking, because the payoff is total and the requirement is only a standard user account that any employee already holds.
It sits in the Through stage of the Unified Kill Chain, the privilege escalation and credential access work that follows a foothold. It belongs next to the other ways one domain account becomes many, such as Kerberoasting a service account.
In
Initial foothold
One low-privilege domain user
Through
Discover template
Enumerate AD CS for a weak template
Escalate privilege
Request a certificate as a domain admin
Credential access
TGT and NT hash for that admin
Out
Domain compromise
Act with domain admin rights
The chain, from one domain user to domain admin
The attacker starts with one domain account, the kind granted to any employee. That is the assumed-breach starting point, and it can also be reached by the earlier links in a chain, for example AS-REP roasting an account with pre-authentication disabled.
With that account, the attacker asks the certificate authority to issue a certificate from a vulnerable template and names a domain admin as the subject. The CA does not check whether the requester is that admin. It signs a certificate that says the requester is.
The certificate now proves the admin's identity to anything that trusts the CA. The attacker presents it to a domain controller over PKINIT and receives a Kerberos ticket-granting ticket for the admin, and with it the account's NT hash. From there the attacker can request tickets for any service the admin can reach.
No password was reset, no service crashed, and no malware ran. The domain controller did exactly what it was built to do with a validly issued certificate, which is why the abuse is quiet and why it is caught at issue time rather than at use.
$ certipy req -u [email protected] -p 'REDACTED' \
-ca 'CORP-CA' -template 'VulnUserAuth' \
-upn '[email protected]' -dc-ip 10.0.0.10
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Got certificate with UPN '[email protected]'
[*] Saved certificate and private key to 'administrator.pfx'$ certipy auth -pfx administrator.pfx -dc-ip 10.0.0.10
[*] Using principal: [email protected]
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'administrator.ccache'
[*] Got hash for '[email protected]': aad3b435b51404eeaad3b435b51404ee:<redacted>
The conditions a template has to meet
A template is only dangerous when several settings line up at once. Miss any one and the chain does not run, which is why ESC1 is precise to describe and cheap to fix once found. The weakness maps to CWE-295, improper certificate validation, and to CWE-269, improper privilege management, and MITRE ATT&CK tracks the abuse as steal or forge authentication certificates, T1649.
The condition that does the damage is the enrollee-supplied subject. When a template is set to build its subject from the request rather than from the directory, the requester chooses whose name goes on the certificate. Combined with a client authentication purpose and open enrolment, that choice is a choice of who to become, and no later control in the flow second-guesses it.
The table below is the checklist a tester works through, and the same list a template owner reviews before publishing. The right-hand column is the remediation, one entry per condition, because removing any single one closes the path.
| Condition | What it means | How to remove it |
|---|---|---|
| Open enrolment | A broad group such as Domain Users may enrol | Restrict enrolment to a named, purpose-built group |
| Enrollee supplies subject | The requester names the subject, not the CA | Clear the flag so the CA builds the subject from AD |
| Authentication purpose | Client Authentication, Smart Card Logon or Any Purpose | Remove authentication EKUs the template does not need |
| No manager approval | Certificates issue with no human review | Require manager approval on sensitive templates |
| No authorised signature | No countersignature is demanded on the request | Require one or more authorised signatures |
Finding it before an attacker does
A discovery pass enumerates every template the CA publishes and reports which ones an unprivileged user could abuse. It runs from the same position an attacker holds, a single domain account, and needs no elevated rights to read the template configuration out of the directory.
The output names the template, the group that can enrol, the authentication purpose and the subject flag, and it labels the finding as ESC1. A tester reads it, confirms the enrolment path by hand, and reports the exact template rather than a general warning, which is what tells a template owner what to change. Scoping this into an engagement is covered in how to buy an infrastructure pentest.
Confirming the finding matters as much as flagging it. A template can list an authentication purpose and still be safe if enrolment is genuinely locked down, so a tester verifies the enrolment path by hand and requests a benign certificate for a controlled account to prove issuance, never a real administrator. Running that test against a documented method keeps it repeatable and defensible, and the technical guide to information security testing, NIST SP 800-115, sets out how a controlled test is scoped and evidenced.
$ certipy find -u [email protected] -p 'REDACTED' \
-dc-ip 10.0.0.10 -vulnerable -stdout
[*] Finding certificate templates
[*] Finding enabled certificate templates
...
Template Name : VulnUserAuth
Enrollment Rights : CORP\Domain Users
Client Authentication : True
Enrollee Supplies Subject : True
Requires Manager Approval : False
[!] Vulnerabilities
ESC1 : Enrollee supplies subject and can request an authentication certificateWhat breaks the chain
Every fix removes one of the conditions. The cheapest complete fix is to clear the enrollee-supplied subject flag on any template that carries an authentication purpose, so the CA builds the subject from the directory instead of trusting the request. Where a template genuinely needs a requester-supplied subject, require manager approval or an authorised signature so nothing issues unreviewed, and restrict enrolment to a named group rather than Domain Users. The same internal foothold an attacker uses here is often the one an LLMNR poisoning to SMB relay capture provides, so the account you are protecting the CA from may already be in reach.
The issuance leaves a record. With CA auditing enabled the certificate authority writes event 4886 when it receives a request and 4887 when it issues, both carrying the requester and the requested subject. A certificate whose subject names an administrator but whose requester is an ordinary account is the pattern to alert on, and it is a signal your own environment produces rather than one you have to buy. Reviewing published templates on a schedule keeps a fixed one from being recreated by a later change.
Turning that signal into a rule your team owns, and rehearsing the alert against a live attempt, is the work of a purple teaming session. A detection that fires the moment a mismatched certificate is issued turns the most dangerous template abuse in the domain into a contained, visible incident.
Why this matters for UAE enterprises
Active Directory is the identity backbone of most large organisations in the UAE, and AD CS is commonly deployed alongside it to issue certificates for VPNs, Wi-Fi, smart cards and internal services. That makes ESC1 a realistic path to full domain control inside banks in the DIFC and ADGM, government suppliers in Dubai, and healthcare providers in Abu Dhabi, wherever a certificate template has been published without a careful review of who may enrol and who names the subject.
The relevant obligations already sit in the frameworks these entities answer to. The Central Bank of the UAE binds licensed financial institutions, the Dubai Electronic Security Centre binds Dubai government entities and their suppliers, ADHICS governs Abu Dhabi healthcare, and the UAE Information Assurance Regulation published through NESA applies federally. Each expects access control and privilege management to be tested and evidenced, and a domain-admin path opened by one template is exactly the kind of finding an internal assessment is meant to surface. An organisation operating across Dubai and Abu Dhabi should confirm its certificate templates are reviewed in both, since a single misconfigured template replicated across a forest is a single point of total compromise.
Frequently asked questions
What is ADCS ESC1?
ESC1 is a misconfigured Active Directory Certificate Services template. It lets a low-privilege user enrol for a certificate and supply an arbitrary subject, including a domain admin's name, while the template also permits client authentication. The user requests a certificate as that admin and then authenticates to the domain as them. It is a configuration weakness, not a software vulnerability, so there is no patch and no CVE.
Do you need domain admin rights to exploit ESC1?
No. The whole point of ESC1 is that it starts from one standard domain user, the level of access any employee holds. That single account enrols for the certificate and becomes a domain admin. The lack of any privilege requirement is what makes it a high-severity finding.
How does ESC1 differ from Kerberoasting?
Both start from one domain account, but they attack different things. Kerberoasting requests service tickets and cracks them offline to recover a service account password, which depends on that password being weak. ESC1 needs no cracking: the certificate authority issues a certificate that directly authenticates as a chosen account, so a strong password does not help. ESC1 is usually faster and more reliable when the template is present.
How does ESC1 differ from ESC8?
ESC1 abuses a template that lets the enrollee name the subject, so the attacker requests a certificate as an admin directly. ESC8 abuses the CA's web enrolment endpoint by relaying an NTLM authentication, often from a coerced domain controller, to obtain a certificate. ESC1 is a template configuration flaw; ESC8 is an interface and relay flaw. They are numbered together because both were catalogued in the same research on AD CS.
Which certificate template setting causes ESC1?
The decisive setting is enrollee-supplied subject, shown as the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag, which lets the requester name the subject instead of the CA building it from Active Directory. It becomes exploitable when the template also allows a client authentication purpose and is open to a broad enrolment group. Clearing that flag on authentication templates removes the path.
How do you detect ESC1 in an environment?
Enumerate every published template and check five settings: who can enrol, whether the enrollee supplies the subject, whether an authentication purpose is present, whether manager approval is required, and whether an authorised signature is required. A template with open enrolment, enrollee-supplied subject and an authentication purpose, and no approval or signature, is vulnerable. Certificate discovery tools flag this pattern automatically and label it ESC1.
What logs show an ESC1 attack?
With CA auditing enabled the certificate authority writes Security event 4886 when a request is received and 4887 when a certificate is issued, both recording the requester and the requested subject. The tell is a mismatch: a certificate whose subject is an administrator but whose requester is an ordinary user account. Alerting on that mismatch catches the abuse at the moment of issue.
Does disabling the certificate authority fix ESC1?
It is rarely the right fix, because AD CS is load-bearing for many services that depend on issued certificates. The targeted fix is to correct the vulnerable template: clear the enrollee-supplied subject flag, tighten enrolment, or require approval. That closes ESC1 while leaving legitimate certificate issuance working.
