Search/ GitHub
PW-016Attack pathCertificate Services (AD CS)

AD CS ESC3: enrollment agent abuse

Accounts outside Tier Zero can become enrollment agents and request logon certificates on behalf of anyone.

Category
Attack Path
Severity
At least High.
Typical owner
PKI / AD CS administrators
Data needed
AD CS objects (templates, CAs and their enrollment agent restrictions), from SharpHound, RustHound-CE or the built-in collector*.
MITRE ATT&CKT1649
Most useful toDefensive engineersIdentity and access engineersOffensive operators
On this page

In plain language

Enrollment agents exist so that a trusted team, such as the one issuing smart cards, can request certificates on behalf of other people. An agent certificate is therefore powerful: with it you can request a logon certificate for any user, Domain Admins included.

When ordinary accounts can enroll for an agent certificate, and the CA doesn't restrict which agents may act for whom, anyone with those accounts can sign in as anyone. This is ESC3 in SpecterOps' Certified Pre-Owned.

What Pathwarden flags

Accounts and groups outside Tier Zero can enroll in a template that issues enrollment agent certificates (Certificate Request Agent EKU, or any purpose). With such a certificate they can request a second, logon-capable certificate on behalf of any other user, and the CA where that second template is published does not restrict which agents may do this. Both CAs are trusted by domain controllers for logon.

How attackers use it

This is ESC3 from SpecterOps' "Certified Pre-Owned". Enrollment agents exist so a smart card team can issue cards for other people. An attacker who can enroll as an agent (tools such as Certipy automate both steps) first gets an agent certificate, then requests an authentication certificate "on behalf of" a Domain Admin and logs on as them with PKINIT. Version 1 templates such as the built-in User template accept on-behalf-of requests from any agent by design, which is why unrestricted agents are dangerous.

Find it with Pathwarden

Data needed: AD CS objects (templates, CAs and their enrollment agent restrictions), from SharpHound, RustHound-CE or the built-in collector*.

In the web UI or the HTML report, open the Findings tab and expand PW-016: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:

Shell
# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-016
# the step-by-step guide on this page, offline
pathwarden guide PW-016
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-016

Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.

Before you change anything

  • Identify who holds valid agent certificates today: in certsrv.msc > Issued Certificates, filter on the agent template, or run certutil -config "<CAHost>\<CAName>" -view -restrict "CertificateTemplate=<AgentTemplateOID>" -out "RequestID,RequesterName,NotAfter"
  • Find out whether anyone legitimately enrolls on behalf of others (smart card issuance stations, a badge or MFA team). Those few accounts are the only ones that should keep the agent template.
  • Check which templates the agents need to enroll for (usually a smart card logon template), and for which users.

How to fix it

  1. Open certsrv.msc, right-click the CA > Properties > Enrollment Agents tab.
  2. Select Restrict enrollment agents.
  3. Under Enrollment agents, add only the group of legitimate agents and remove Everyone.
  4. Under Certificate Templates, add only the templates they need to issue (for example the smart card logon template) and remove <All>.
  5. Under Permissions, allow only the users they should enroll for (for example a smart card users group) and deny privileged groups such as Domain Admins and Enterprise Admins.
  6. Click OK. Repeat on every CA that publishes the target template.

Option B: Lock down the agent template

  1. certtmpl.msc > agent template > Properties > Security tab: remove Enroll (and Full Control, which includes it) from broad groups, grant it only to the legitimate agent group, which the PKI administrators manage.
  2. Issuance Requirements tab: tick CA certificate manager approval so each agent certificate is reviewed.
  3. If nobody uses enrollment agents, unpublish the agent template (certsrv.msc > Certificate Templates > Delete) and revoke outstanding agent certificates.

Then: review certificates already issued

Certificates issued before the fix stay valid. In certsrv.msc > Issued Certificates, check the certificates issued on behalf of others for requests nobody expected, and revoke them.

PowerShell / certutil

PowerShell
# Templates the CA issues; confirm the agent template is (or is no longer) listed
certutil -config "<CAHost>\<CAName>" -CATemplates

# Unpublish the agent template if it is not needed
certutil -config "<CAHost>\<CAName>" -SetCATemplates -<AgentTemplate>

# Revoke an outstanding agent certificate by serial number (reason 4 = superseded)
certutil -config "<CAHost>\<CAName>" -revoke <SerialNumber> 4

Verify the fix

  • certsrv.msc > CA Properties > Enrollment Agents shows "Restrict enrollment agents" with only the intended agents, templates and users.
  • A test on-behalf-of request from a non-agent account (or for a Domain Admin) is denied.
  • Collect again (or use Retest on the finding) and confirm the finding ID is gone. Note that restrictions are only detected when the collector reads them from the CA registry (SharpHound reports this; some collectors do not).

Roll back

Select "Do not restrict enrollment agents" on the Enrollment Agents tab, or restore the template's Security and Issuance Requirements settings, or re-publish the template with certutil -config "<CAHost>\<CAName>" -SetCATemplates +<AgentTemplate>.

References

  1. SpecterOps, Certified Pre-Owned (ESC3)specterops.io
  2. Microsoft, Certificate template conceptslearn.microsoft.com
  3. SpecterOps: Certified Pre-Owned (blog post)specterops.io
  4. SpecterOps BloodHound docs: ADCSESC3bloodhound.specterops.io
  5. MITRE ATT&CK T1649: Steal or Forge Authentication Certificatesattack.mitre.org

Very new and undergoing testing. These features haven't received a lot of testing yet. Try them out and let us know what's working.

↑↓ to moveEnter to openEsc to close