Nyx Learning AD CS abuse · Part 2 of 3
AD CS abuse · Part 2 of 3

AD CS abuse, Part 2: the CA, access control, and relay

ESC5–ESC8 and ESC11, certificate theft, and golden-certificate persistence

Generated Thursday, October 8, 2026 · Depth: deep · ESC6 (EDITF_ATTRIBUTESUBJECTALTNAME2) post-May-2022 behaviour, ESC7 (ManageCA/ManageCertificates, the SubCA approval path), ESC8 (web-enrollment relay) and ESC11 (ICPR RPC relay, IF_ENFORCEENCRYPTICERTREQUEST) checked against the ly4k/Certipy wiki, SpecterOps/Certify docs, and Compass Security's 2022 ICPR-relay research. THEFT1–THEFT5 and the golden certificate / DPERSIST1–3 checked against SpecterOps' Certified Pre-Owned (2021). CA key protection (HSM/TPM), EPA, and coercion (PetitPotam/EFSRPC, printer bug/MS-RPRN) checked against vendor and tool documentation. Strong-mapping interactions follow Part 1's KB5014754 research. Event IDs (4876/4877 CA backup, 4882/4890 CA security, 4886/4887 request/issue) per Microsoft AD CS auditing; ESC numbering is informal and varies by source.

01

Start here

Roadmap for this series
  1. Part 1: Templates and the escalation primitives. Public Key Infrastructure (PKI) and Active Directory Certificate Services (AD CS) foundations, how a certificate authenticates, certificate-to-account mapping and the 2022–2025 strong-mapping hardening, and the template attacks ESC1–ESC4.
  2. Part 2 (this page): The Certificate Authority (CA), access control, and relay. ESC5 (PKI object Access Control Lists (ACLs)), ESC6 (the CA-wide Subject Alternative Name (SAN) flag), ESC7 (dangerous CA permissions), ESC8 and ESC11 (relaying authentication into AD CS), certificate theft (THEFT1–5), and golden-certificate persistence.
  3. Part 3: Defeating the mapping, and the newer escalations. ESC9, ESC10, ESC13, ESC14, ESC15/EKUwu and ESC16 (stripping or dodging the Security Identifier (SID) extension), ESC17, and the full hardening and remediation program.
Highlight key
the term being defined
Key term: bold with a highlighter swash. A concept's defining phrase.
how something works
Mechanism: wavy underline. How a piece works or relates to another.
Risk: what makes an attack possible
Risk: warm highlight with a dashed edge. Attack prerequisites and dangerous conditions.
Fix: the mitigation to apply
Fix: solid green underline. A mitigation or configuration change.
Verify: how to confirm it worked
Verify: green underline with a check. How to prove a fix works.
only if, by default
Qualifier: bold italic. A word that changes the claim.
4769
Technical literal: monospace chip. Commands, settings, event IDs, exactly as typed.

Plain English first

Part 1 was about one certificate template being too generous. This part is about the certificate authority itself. Four things make the CA a target even when every template is clean: Risk: a server-wide flag that weakens all templates at once, who is allowed to administer the CA, the network endpoints that accept certificate requests, and above all the CA's private key, the one secret that makes every certificate trustworthy.

The headline attacks here reach domain admin without cracking a password. One relays a domain controller's own authentication to the CA to get a credential for it. Another steals the CA's signing key and Risk: forges certificates for anyone, for years. If Part 1 showed how a bad form lets you print a fake badge, Part 2 shows how to compromise the badge office itself.

The analogy: compromising the badge office

Keep the badge-printer picture from Part 1, and now walk into the office that runs it. Risk: A manager override switch lets any request carry any name (that's the CA-wide SAN flag). The office has Risk: supervisors who can approve any request (CA officers). It has Risk: an after-hours mail slot that takes requests from anyone who posts through it (the relay endpoints). And in the safe sits the master die that stamps every badge genuine (the CA private key). Steal the die and you don't need the office any more: you can stamp real badges forever, from anywhere, until the whole design is recalled.

Why it matters now

Attacker

The CA-side attacks are the Risk: most reliable AD CS paths in 2026, because many don't depend on the strong-mapping enforcement that blunted classic ESC1. A relay from a coerced Domain Controller (DC) is Risk: unauthenticated-to-domain-admin, and a stolen CA key is persistence that survives password and krbtgt resets.

Defender

These fixes are concrete and mostly free: Fix: remove the SAN flag, restrict CA officers and admins, enforce Extended Protection for Authentication (EPA) or remove web enrollment, set the ICertPassage Remote Protocol (ICPR) encryption flag, and, the big one, Fix: put the CA private key in an Hardware Security Module (HSM) and manage the CA as Tier 0. Template scans won't find these, so they need their own review.

If you remember only 5 things

  1. The CA is Tier 0, and its key is the crown jewel. Whoever can export the CA private key can Risk: forge certificates for anyone, for years. An Fix: HSM-backed, non-exportable key is the single highest-value control in this part.
  2. Relay turns a network foothold into domain admin. Coerce a DC, relay to web enrollment (ESC8) or the ICPR Remote Procedure Call (RPC) interface (ESC11), get a DC certificate, and Risk: DCSync the domain, no password needed.
  3. CA admin rights are privileged, separately from enrollment. Risk: ManageCA and ManageCertificates enable ESC7; the SubCA-approve path needs no service restart.
  4. ESC6 is a force-multiplier, not a standalone win today. Alone it maps back to the requester post-2022; paired with a SID-strip (Part 3) it spoofs SANs CA-wide.
  5. Certificate persistence needs special eviction. A golden certificate survives resets and krbtgt rotation; removing it means Fix: reissuing the CA and re-enrolling, so prevention beats response.
02

Core concepts

Twelve ideas, from "the Certificate Authority (CA) as a target" to how strong mapping shapes which CA-side attacks still impersonate. Open "Go deeper" for expert detail.

01Widening the target: the Certificate Authority (CA), not just the templatePart 2 moves from template settings to the certificate authority itself: its configuration, permissions, enrollment endpoints and private key.
In plain terms

Part 1's ESC1–ESC4 were all about one template being too generous. These attacks are about the CA as a whole: a dangerous server flag, who can administer the CA, the ways to reach it over the network, and the master key that makes every certificate trustworthy.

Example

No single template is misconfigured, but the CA has a flag that lets anyone add a name to any request, or an operator account an attacker can take over.

TechnicalGo deeper

This matters because template fixes don't touch these. Risk: A CA-wide flag affects every template at once, CA permissions are a separate Access Control List (ACL) from template ACLs, and the enrollment endpoints and CA key are infrastructure, not policy. The common thread: the CA is a Tier 0 system, and most of this part is about treating it like one, not like an app server.

02The Certificate Authority (CA)'s configuration and the Subject Alternative Name (SAN) flag (ESC6)A CA policy flag, EDITF_ATTRIBUTESUBJECTALTNAME2, lets requesters supply a SAN on any request, CA-wide.
In plain terms

ESC1 needed a template that allowed enrollee-supplied subject. This flag does the same thing for the whole CA at once: with it set, you can add "I am the administrator" to a request for almost any template, even normal ones.

Example

A CA has the flag enabled from an old troubleshooting session. An attacker requests from the ordinary User template but attaches a SAN naming a domain admin.

TechnicalGo deeper

Check it with certutil -getreg policy\EditFlags; Certipy's find reports it as "User Specified SAN: Enabled." Since the May 2022 patch, ESC6 is mostly neutralised on its own, because the CA still stamps the requester's Security Identifier (SID) into the certificate, so strong mapping binds it back to the attacker, the same dynamic as ESC1. Its danger today is in combination: Risk: ESC6 plus a SID-extension-stripping technique (ESC9/ESC16, Part 3) re-enables impersonation CA-wide. Fix: remove the flag, restart the CA service, and revoke anything issued while it was set.

03The Certificate Authority (CA)'s permission model (ManageCA and ManageCertificates)The CA has its own Access Control List (ACL); ManageCA and ManageCertificates are its administrative rights, and either enables ESC7.
In plain terms

Separate from who can enroll, the CA itself has administrators (ManageCA, the full CA admin) and certificate managers (ManageCertificates, the "CA officer" who approves requests). Hand either to the wrong person and they can escalate.

Example

A monitoring account was granted ManageCertificates years ago so it could approve requests. An attacker who takes that account can approve a request they shouldn't.

TechnicalGo deeper

Risk: ManageCA can change CA configuration (via SetConfigEntry), including enabling the ESC6 Subject Alternative Name (SAN) flag, and can Risk: grant itself ManageCertificates (add itself as an officer). Risk: ManageCertificates can approve pending or previously failed requests. The reliable ESC7 path when you can't restart the CA service: use ManageCA to enable the built-in SubCA template, submit a request (it goes pending), then use ManageCertificates to approve that failed request, yielding a Subordinate CA certificate you can use broadly. Certipy enumerates and modifies CA rights directly.

04The enrollment endpoints: Hypertext Transfer Protocol (HTTP) and Remote Procedure Call (RPC)The Certificate Authority (CA) accepts requests over HTTP (web enrollment, Certificate Enrollment Web Service (CES)) and RPC (ICPR), and both can be relay targets.
In plain terms

Besides the normal in-domain request path, Active Directory Certificate Services (AD CS) can expose web pages and an RPC service to take certificate requests. Those listeners accept Windows authentication, which an attacker can relay from someone else.

Example

The CA runs the "Certificate Services Web Enrollment" role at http://ca/certsrv, which accepts NT LAN Manager (NTLM), so authentication aimed elsewhere can be forwarded to it.

TechnicalGo deeper

Web Enrollment (/certsrv, endpoints like certfnsh.asp) Risk: accepts NTLM over plain HTTP by default, with no channel binding, which is the ESC8 surface. The ICPR RPC interface is the ESC11 surface when Risk: packet privacy isn't enforced (IF_ENFORCEENCRYPTICERTREQUEST unset). Both exist so clients and non-domain devices can enroll; both are optional roles/settings, so the first question in a review is whether they're even needed.

05NT LAN Manager (NTLM) relay and coercion, applied to Active Directory Certificate Services (AD CS)Relay forwards someone else's authentication to the Certificate Authority (CA); coercion forces a chosen machine to authenticate on command.
In plain terms

If you can make a privileged computer (a domain controller) try to authenticate to you, and then pass that authentication on to the CA's enrollment endpoint, the CA issues you a certificate as that computer. AD CS is a favourite relay destination because the payoff is a logon credential.

Example

The attacker triggers PetitPotam against a Domain Controller (DC), the DC authenticates to the attacker over Encrypting File System Remote Protocol (EFSRPC), and the attacker relays it to web enrollment to get a certificate for the DC's machine account.

TechnicalGo deeper

Coercion tools (PetitPotam over EFSRPC, the printer bug over MS-RPRN, Coercer) make a target authenticate; the relay (Impacket ntlmrelayx) forwards it. A certificate for a Risk: domain controller's machine account authenticates as that DC, enabling DCSync and full compromise, so ESC8/ESC11 turn an unauthenticated network position into domain takeover. This connects directly to the Kerberos series' delegation and coercion material; the fixes overlap (Extended Protection for Authentication (EPA), Server Message Block (SMB)/Lightweight Directory Access Protocol (LDAP) signing, patching coercion).

06Public Key Infrastructure (PKI) object access control (ESC5)ESC5 is write control over the Active Directory (AD) objects and host that Active Directory Certificate Services (AD CS) depends on, beyond templates.
In plain terms

The certificate system is more than templates. There's the Certificate Authority (CA)'s own AD object, the list of trusted issuers, the CA computer account, and the CA server itself. Control any of them and you can subvert issuance.

Example

A stale admin group has WriteDacl on the CA's enrollment-services object, or local admin on the CA server, so an attacker through that group can reconfigure issuance.

TechnicalGo deeper

The objects live under CN=Public Key Services,CN=Services in the configuration partition: the Enrollment Services (CA) objects, NTAuthCertificates (trusted issuers), Certification Authorities (root trust), plus the CA's computer object and the host's local admin. Risk: Control of the CA host is game over (it exposes the private key). ESC5 is really "the ACL-edge problem from the attack-paths note, pointed at PKI objects." Verify: Enumerate these Access Control Lists (ACLs) alongside template ACLs; BloodHound models several as nodes and edges.

07The Certificate Authority (CA) private key: the crown jewelThe CA's private key is what signs every certificate; whoever holds it can forge any identity.
In plain terms

Every certificate the CA issues is trusted because the CA signed it with its private key. That key lives on the CA server. If an attacker copies it, they can sign their own certificates for anyone, with no request to the CA at all.

Example

An attacker with admin on the CA exports the CA certificate and its private key, then walks away with the power to mint certificates offline.

TechnicalGo deeper

By default the key is stored in software, protected by machine Data Protection API (DPAPI), and Risk: exportable by a CA administrator (or extractable via Cryptographic API (CAPI)/Cryptography API: Next Generation (CNG) patching). An Fix: Hardware Security Module (HSM) or TPM-backed key is non-exportable, which is the main defense. Protecting this key is the difference between a contained incident and a years-long persistence problem, because unlike a password or the krbtgt key, rotating a CA key means reissuing the CA, a disruptive Public Key Infrastructure (PKI) operation.

08Certificate and key theft (THEFT1–THEFT5)Theft is stealing existing certificates and their private keys, or deriving credentials from them.
In plain terms

Rather than making a new malicious certificate, an attacker can steal ones that already exist, from the user store, the machine store, files on disk, or by converting a certificate into a password hash.

Example

An attacker on a workstation exports a user's client-auth certificate and private key, then replays it from anywhere until it expires.

TechnicalGo deeper

The catalogued categories: THEFT1 interactive export via the crypto Application Programming Interfaces (APIs) (Cryptographic API (CAPI)/Cryptography API: Next Generation (CNG) patched if the key is marked non-exportable); THEFT2/THEFT3 pulling keys from user or machine Data Protection API (DPAPI) (SharpDPAPI, Mimikatz; machine store needs SYSTEM); THEFT4 collecting .pfx/.p12 files left on disk and shares; THEFT5 using a certificate to recover the account's NT LAN Manager (NTLM) hash via Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (UnPAC-the-hash, from Part 1). Fix: Hardware-backed keys defeat the passive ones; the rest are a monitoring and least-privilege problem.

09Golden certificates and forgingA golden certificate is a certificate forged offline with the stolen Certificate Authority (CA) private key, for any account.
In plain terms

With the CA's private key, an attacker signs their own certificates without touching the CA. They can mint a logon certificate for any user or computer, including a domain admin, and it's fully trusted.

Example

An attacker who exfiltrated the CA key uses ForgeCert or Certipy to forge a certificate for the Administrator, then authenticates with Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) whenever they want back in.

TechnicalGo deeper

This is the premier Active Directory Certificate Services (AD CS) persistence (the paper's DPERSIST1). Forged certificates Risk: carry whatever Security Identifier (SID) and identity the attacker chooses, so they beat strong mapping, and they're valid until the CA certificate expires (often 5–10 years) or is revoked. Related persistence: Risk: adding a rogue CA to NTAuthCertificates so attacker-signed certs are trusted (DPERSIST2), and planting a backdoor misconfiguration for re-escalation (DPERSIST3). Response can't be a password reset; it's Fix: revoking/reissuing the CA and rebuilding trust.

10Why certificate persistence is uniquely durableCertificate-based access survives the usual eviction steps: password resets, and even krbtgt rotation.
In plain terms

In a normal Active Directory (AD) compromise you reset passwords and rotate the Kerberos master key to kick the attacker out. Certificates don't care about either. A valid certificate keeps authenticating, and a forged one keeps working until the Certificate Authority (CA) key itself is replaced.

Example

A team double-rotates krbtgt and resets every password, then watches the attacker log back in with a forged certificate the next day.

TechnicalGo deeper

The eviction hierarchy: a stolen user certificate dies on Fix: revocation or expiry; a golden certificate dies only when Fix: the CA certificate is rotated/reissued, which invalidates all certificates it signed and forces re-enrollment. That's why Active Directory Certificate Services (AD CS) belongs in incident-response playbooks explicitly: Verify: hunt issued and forged certificates, check NTAuthCertificates, and verify the CA key's integrity, not just rotate secrets.

11Runtime attacks vs static misconfigurationsESC8/ESC11 are runtime relay attacks; the others are static misconfigurations you can enumerate.
In plain terms

Most Escalations (ESCs) are a setting you can read and flag ahead of time. Relay attacks are different: they happen live, by catching and forwarding authentication, so they don't show up as a bad template, and the graph tools model them only partly.

Example

A scan shows no vulnerable templates, but web enrollment is on with NT LAN Manager (NTLM), so a relay from a coerced Domain Controller (DC) still yields domain compromise.

TechnicalGo deeper

This changes how you test and defend. Verify: Enumeration finds ESC5/6/7 (and template ESCs); Verify: ESC8/ESC11 need you to check the endpoints and coercion exposure, because a clean template scan isn't a clean bill of health. BloodHound models some CA-side edges (ADCSESC6a/b, ADCSESC7, GoldenCert), but relay exposure is a property of the network and endpoints, not just the directory, so confirm it live.

12The CA-side mapping and enforcement recapStrong mapping shapes which CA-side attacks still impersonate, just as it did for ESC1.
In plain terms

The 2022–2025 enforcement that neutralised classic ESC1 also affects these. Where an attack makes the Certificate Authority (CA) stamp the attacker's own Security Identifier (SID), strong mapping binds it back to the attacker; where the certificate is issued for the victim or forged outright, it doesn't help.

Example

ESC6 alone maps back to the attacker under enforcement, but a golden certificate forged with the attacker's chosen SID authenticates as the victim regardless.

TechnicalGo deeper

Quick rule: attacks that spoof a name but carry the requester's SID (ESC6, and ESC8/ESC11 when requesting as yourself) are blunted by enforcement unless paired with a SID-strip (Part 3). Risk: Attacks that issue for the victim or forge the SID (ESC7 SubCA, ESC8 as the coerced machine, golden certificates) impersonate regardless. This is why Part 3's mapping-defeat techniques matter, and why the CA-side attacks that don't depend on mapping are the most reliable today.

03

Visual map

Step through the ESC8 relay to a domain-controller certificate, the ESC7 SubCA approval path, the ESC6 CA-wide Subject Alternative Name (SAN) flag, and the golden-certificate forge. Verify: Each step names the defense that breaks it.

The CA-side attacks at a glance

ESC5ESC6ESC7ESC8ESC11
TargetPublic Key Infrastructure (PKI) objects / Certificate Authority (CA) hostCA policy flagCA permissionsWeb enrollment (HTTP)ICertPassage Remote Protocol (ICPR) (RPC)
Root causeWrite Access Control List (ACL) or local adminEDITF_ATTRIBUTESUBJECTALTNAME2ManageCA / ManageCertificatesNT LAN Manager (NTLM) over HTTP, no Extended Protection for Authentication (EPA)Packet privacy not enforced
Attacker actionReconfigure issuance / take keyAdd a SAN to any requestSubCA + approveCoerce + relay to /certsrvCoerce + relay over RPC
Blunted by Full Enforcement?NoYes, aloneNo (issued for victim)No (as coerced machine)No (as coerced machine)
Primary fixLock PKI ACLs; CA as Tier 0Remove flag, restart, revokeRestrict CA rightsEPA + Hypertext Transfer Protocol Secure (HTTPS) / remove roleSet IF_ENFORCEENCRYPTICERTREQUEST

ManageCA vs ManageCertificates

ManageCAManageCertificates
Role nameCA administratorCA officer
Can change CA config (SetConfigEntry)Risk: Yes (e.g. enable the SAN flag)No
Can grant itself the other rightRisk: Yes (add itself as officer)No
Can approve pending / failed requestsNo (by itself)Risk: Yes
ESC7 roleEnable SubCA templateApprove the SubCA request

Certificate theft and persistence

TechniqueWhat it isMain defense
THEFT1Interactive export of cert + key (Cryptographic API (CAPI)/Cryptography API: Next Generation (CNG) patched if non-exportable)Fix: Hardware-backed keys
THEFT2 / THEFT3Pull keys from user / machine Data Protection API (DPAPI) (machine needs SYSTEM)Least privilege, Endpoint Detection and Response (EDR), hardware keys
THEFT4Collect .pfx / .p12 files on disk and sharesRemove key files; scan shares
THEFT5Certificate → NTLM hash via Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (UnPAC-the-hash)Limit who holds auth certs
Golden cert (DPERSIST1)Forge offline with the stolen CA keyFix: HSM-protected CA key
Rogue CA (DPERSIST2)Add attacker CA to NTAuthCertificatesVerify: Audit NTAuthCertificates
04

Technical deep dive

Technical

Under the hood

ESC6: the CA-wide Subject Alternative Name (SAN) flag, in context

EDITF_ATTRIBUTESUBJECTALTNAME2 lives in the Certificate Authority (CA)'s policy module EditFlags (certutil -getreg policy\EditFlags). When set, the CA copies a requester-supplied SAN onto the issued certificate Risk: for any template, reproducing the ESC1 primitive CA-wide. Since the May 2022 update, the CA still adds the requester's own Security Identifier (SID) in the security extension, so under Full Enforcement the certificate maps back to the attacker, the same dynamic as classic ESC1. Its modern value is as a force-multiplier: combined with a SID-extension-stripping technique from Part 3, Risk: it enables SAN spoofing across every template at once. Remove the flag, restart certsvc, and revoke anything issued while it was set.

ESC7: the two CA rights and the SubCA path

The CA's own security descriptor grants roles independent of template enrollment. ManageCA (CA administrator) can change configuration via ICertAdminD2::SetConfigEntry, including enabling the SAN flag, and can Risk: add itself as a certificate manager. ManageCertificates (CA officer) can approve, issue or deny requests. The reliable escalation, which avoids needing to restart the CA service:

  1. With ManageCA, enable the built-in SubCA template on the CA.
  2. Request a certificate from SubCA. It can't be auto-issued, so it lands in the pending/failed queue.
  3. With ManageCertificates, Risk: approve (issue) that failed request, yielding a Subordinate CA certificate.

Because the SubCA certificate is issued for the target identity, the SID extension is legitimate and strong mapping doesn't stop it. Certipy's ca subcommand enumerates rights, adds officers, enables templates and issues requests.

ESC8 and ESC11: relaying into Active Directory Certificate Services (AD CS)

AD CS exposes two optional request surfaces that accept Windows authentication:

  • Web Enrollment (/certsrv, endpoints like certfnsh.asp) Risk: accepts NT LAN Manager (NTLM) over plain Hypertext Transfer Protocol (HTTP) with no channel binding. That's ESC8.
  • ICertPassage Remote Protocol (ICPR) (the MS-ICPR Remote Procedure Call (RPC) interface) is relayable when Risk: packet privacy isn't enforced (IF_ENFORCEENCRYPTICERTREQUEST unset). That's ESC11, and it survives removing web enrollment.

The chain is the same for both: coerce a privileged machine to authenticate, then relay that authentication to the CA and request a certificate as the coerced principal.

  1. Coerce. PetitPotam (over Encrypting File System Remote Protocol (EFSRPC)), the printer bug (MS-RPRN), or Coercer makes a Domain Controller (DC) authenticate outbound.
  2. Relay. Impacket ntlmrelayx forwards the DC's NTLM to the CA endpoint.
  3. Request. Ask for a certificate from a machine template as the DC's account.
  4. Impact. Risk: A DC certificate authenticates as the DC via Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), enabling DCSync and full domain compromise.

This is why AD CS is a prized relay destination: the payoff is a durable logon credential for a Tier 0 principal. The defenses overlap with the Kerberos series: Extended Protection for Authentication (EPA) and Hypertext Transfer Protocol Secure (HTTPS) (channel binding), disabling NTLM on the endpoint, enforcing Server Message Block (SMB)/Lightweight Directory Access Protocol (LDAP) signing, patching coercion, and removing unused roles.

ESC5: the broader Public Key Infrastructure (PKI) object surface

ESC5 is write control over the objects AD CS depends on, beyond templates, under CN=Public Key Services,CN=Services:

  • the Enrollment Services object (the CA itself),
  • NTAuthCertificates (the issuers trusted for logon),
  • the Certification Authorities container (root trust),
  • the CA's computer account, and
  • local admin on the CA host.

Any write or admin control here subverts issuance; Risk: control of the CA host exposes the private key directly. In practice ESC5 is the attack-paths note's ACL-edge problem aimed at PKI, so enumerate these Access Control Lists (ACLs) alongside template ACLs. BloodHound models several as nodes and edges.

The CA private key and golden certificates

Every issued certificate is trusted because the CA signed it. By default the CA key is software-stored, protected by machine Data Protection API (DPAPI), and Risk: exportable by a CA administrator (or extractable by patching Cryptographic API (CAPI)/Cryptography API: Next Generation (CNG)). With the key, an attacker forges certificates offline, Risk: choosing the identity and the SID, so forged certs beat strong mapping and leave Verify: no 4887 issuance record. This is DPERSIST1, the golden certificate. Forged certs are valid until the CA certificate expires (often 5–10 years) or is reissued. The defense that actually closes it is a Fix: non-exportable key in an Hardware Security Module (HSM)/Trusted Platform Module (TPM).

Eviction and the mapping recap

A stolen user certificate dies on revocation or expiry. A golden certificate dies only when Fix: the CA certificate is rotated/reissued, which invalidates everything it signed and forces re-enrollment, and the responder must also Verify: check NTAuthCertificates for rogue CAs (DPERSIST2). On mapping: attacks that spoof a name while carrying the requester's SID (ESC6, relay-as-self) are blunted by enforcement unless paired with a SID-strip; attacks that issue for, or forge as, the victim (ESC7 SubCA, ESC8/ESC11 as the coerced machine, golden certificates) impersonate regardless, which is why they're the reliable ones today.

Common misconceptions

MisconceptionReality
"No vulnerable templates means we're safe."ESC6/ESC7 are CA-wide, and Risk: ESC8/ESC11 are runtime relay, invisible to a template scan.
"We removed web enrollment, relay is handled."Risk: ESC11 relays over RPC unless IF_ENFORCEENCRYPTICERTREQUEST is set.
"ManageCertificates is harmless, it only approves."Approving a self-submitted SubCA request is Risk: a path to a CA certificate.
"ESC6 is always critical."Alone it maps back to the requester post-2022; critical when paired with a SID-strip.
"We reset passwords and rotated krbtgt, we're clean."A golden certificate Risk: survives both; eviction is CA reissue.
"The CA is just another server."It can mint credentials for anyone; it's Fix: Tier 0.

Finding the CA-side exposure

# CA config, rights, web endpoints and ESC6 flag (read-only)
certipy find -u user@corp.example -p '***' -dc-ip 10.0.0.1 -stdout

# The ESC6 flag and the ICPR encryption flag, directly
certutil -config 'CA-HOST\CA-NAME' -getreg policy\EditFlags
certutil -config 'CA-HOST\CA-NAME' -getreg CA\InterfaceFlags   # IF_ENFORCEENCRYPTICERTREQUEST

# Is web enrollment answering? (relay surface)
#   a request to http://CA-HOST/certsrv/ that returns a 401/200 means it's live
05

Attacker's view

Attacker

Attacker's view, for defenders

Covered at the level needed to recognise, test for and explain each path: the exact condition, what makes it vulnerable, the evidence it leaves, and how it reads as a finding. Tool names are given for detection and lab work; weaponized relay and forging syntax is omitted. The Certipy wiki and an authorized lab are the place for hands-on practice.

ESC5: control of Public Key Infrastructure (PKI) objects or the Certificate Authority (CA) hostATT&CKT1649 Steal or Forge Authentication Certificates · T1222 Permissions Modification
How it works

The attacker holds write control over an Active Directory Certificate Services (AD CS) object or the CA server outside the templates: the CA's enrollment-services object, the trusted-issuer store, the CA computer account, or local admin on the CA host. From there they reconfigure issuance or take the private key.

Prerequisites

Risk: A write Access Control Entry (ACE) on a PKI object (WriteDacl, WriteOwner, GenericAll) or administrative access to the CA server.

What makes an environment vulnerable

Stale delegations and over-broad local-admin on the CA; Risk: the CA treated as an ordinary server rather than Tier 0. The same ACL-edge hygiene problem from the attack-paths note, pointed at PKI.

Tools

BloodHound (models several PKI objects and edges), Certipy (find shows CA Access Control Lists (ACLs)), PowerView; for host compromise, the usual lateral-movement toolset.

# Recognise: enumerate CA and PKI object permissions (read-only)
certipy find -u user@corp.example -p '***' -dc-ip 10.0.0.1 -stdout
DefenderEvidence it leaves

Verify: 5136 changes to PKI objects under CN=Public Key Services, local-admin logons to the CA host, and any CA private-key export or backup activity.

ExecutiveAs a pentest finding

"Non-PKI principals can modify the certificate authority's configuration or access the CA host." Critical; it reaches the CA key. Retest: PKI object ACLs and CA local admin restricted to the PKI Tier 0 group.

ESC6: the CA-wide Subject Alternative Name (SAN) flagATT&CKT1649 Steal or Forge Authentication Certificates
How it works

The Certificate Authority (CA) has EDITF_ATTRIBUTESUBJECTALTNAME2 set, so it honours a requester-supplied SAN on any template. The attacker adds a privileged User Principal Name (UPN) to an ordinary request.

Prerequisites

Risk: The SAN flag enabled on the CA, plus enroll rights on any client-auth-capable template. For impersonation to succeed today, the Security Identifier (SID) extension must be absent or defeated.

What makes an environment vulnerable

CAs where the flag was set for a legacy app or during troubleshooting and never removed. Since May 2022 the flag alone usually isn't enough, but it is CA-wide and a force-multiplier with Part 3's SID-strip techniques.

Tools

Certipy (find reports "User Specified SAN: Enabled"; req with a chosen -upn/-sid), certutil -getreg policy\EditFlags.

certutil -config 'CA-HOST\CA-NAME' -getreg policy\EditFlags   # inspect the flag
DefenderEvidence it leaves

Verify: 4887 where an issued SAN differs from the requester, across many template types (not just one), which points at a CA-wide cause.

ExecutiveAs a pentest finding

"The CA accepts attacker-specified identities on any request." High to critical, critical when combined with a SID-strip. Retest: flag removed (certutil -setreg, CA service restarted) and offending certificates revoked.

ESC7: dangerous Certificate Authority (CA) permissions (ManageCA / ManageCertificates)ATT&CKT1649 Steal or Forge Authentication Certificates · T1222 Permissions Modification
How it works

The attacker controls a principal with CA administrative rights. ManageCA changes CA config and can grant itself ManageCertificates; ManageCertificates approves pending or failed requests. The reliable path: enable the SubCA template with ManageCA, submit a request (it fails to pending), then approve it as an officer.

Prerequisites

Risk: ManageCA or ManageCertificates on the CA, held directly or through a group.

What makes an environment vulnerable

CA officer/admin rights granted broadly or to service and monitoring accounts; Risk: help-desk or app accounts made CA officers for convenience.

Tools

Certipy (ca to enumerate and modify CA rights, add officers, enable templates, and approve requests), Certify.

# Recognise these CA-management actions
certipy ca -ca CORP-CA -list-templates
certipy ca -ca CORP-CA -issue-request <id>   # officer approves a pending request
DefenderEvidence it leaves

CA configuration changes and officer-list changes; Verify: 4890/4882 CA security/role changes, a pending request being issued (4887) shortly after a config change, and SubCA template enablement.

ExecutiveAs a pentest finding

"CA administrative rights allow self-service issuance of privileged certificates." Critical. Retest: ManageCA/ManageCertificates restricted to named Public Key Infrastructure (PKI) admins, and the SubCA template disabled or locked down.

ESC8: NT LAN Manager (NTLM) relay to web enrollmentATT&CKT1649 Steal or Forge Authentication Certificates · T1557 Adversary-in-the-Middle · T1187 Forced Authentication
How it works

The attacker coerces a privileged machine to authenticate, then relays it to the Certificate Authority (CA)'s Hypertext Transfer Protocol (HTTP) web-enrollment endpoint, requesting a certificate as that machine. A certificate for a Domain Controller (DC)'s machine account leads to DCSync and domain compromise.

Prerequisites

Risk: Web Enrollment enabled and accepting NTLM without channel binding, plus a coercion trigger and a relayable privileged account (often a DC).

What makes an environment vulnerable

The Certificate Services Web Enrollment role left on, Risk: HTTP with NTLM and no Extended Protection for Authentication (EPA), and unpatched coercion (PetitPotam, printer bug). Common because the role is installed and forgotten.

Tools

Impacket ntlmrelayx (Active Directory Certificate Services (AD CS) mode), coercion via PetitPotam / Coercer / the printer bug, Certipy to use the resulting certificate.

# Recognise the pattern (coerce → relay → cert). Endpoints: /certsrv/certfnsh.asp
# ntlmrelayx targeting http://CA/certsrv with a machine/DC template
DefenderEvidence it leaves

Verify: A DC machine-account certificate request from the relay host (4886/4887), inbound coercion Remote Procedure Call (RPC) (Encrypting File System Remote Protocol (EFSRPC), MS-RPRN), and a later Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (4768) for the DC account from an unusual source.

ExecutiveAs a pentest finding

"An unauthenticated attacker can obtain a domain-controller certificate via coercion and relay." Critical; it's network-position-to-domain-admin. Retest: EPA and Hypertext Transfer Protocol Secure (HTTPS) enforced (or web enrollment removed), NTLM disabled on the endpoint, coercion patched, and the path fails.

ESC11: NT LAN Manager (NTLM) relay to the ICertPassage Remote Protocol (ICPR) Remote Procedure Call (RPC) endpointATT&CKT1649 Steal or Forge Authentication Certificates · T1557 Adversary-in-the-Middle · T1187 Forced Authentication
How it works

The RPC sibling of ESC8. When the Certificate Authority (CA)'s ICPR interface doesn't enforce packet privacy, the attacker relays coerced authentication to it over RPC/Distributed Component Object Model (DCOM) and gets a certificate, even with web enrollment removed.

Prerequisites

Risk: IF_ENFORCEENCRYPTICERTREQUEST not set on the CA (encryption not enforced for ICPR), plus coercion and a relayable account.

What makes an environment vulnerable

CAs hardened against ESC8 by removing web enrollment but Risk: leaving the RPC request path unencrypted. Easy to miss because it isn't a visible web page.

Tools

Impacket ntlmrelayx (ICPR/RPC mode), the same coercion tools, Certipy. Research by Compass Security (2022).

certutil -getreg CA\InterfaceFlags   # check IF_ENFORCEENCRYPTICERTREQUEST
DefenderEvidence it leaves

Verify: Certificate requests over RPC/DCOM from a relay host, coercion traffic, and a Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) for the relayed account. Fewer web-server logs than ESC8, so RPC and CA issuance logs matter more.

ExecutiveAs a pentest finding

"The CA's RPC request interface is relayable." Critical, same impact as ESC8. Retest: IF_ENFORCEENCRYPTICERTREQUEST set (certutil -setreg, service restarted) and the relay fails.

Certificate and private-key theft (THEFT1–THEFT5)ATT&CKT1552.004 Private Keys · T1555 Credentials from Password Stores · T1649 Steal or Forge Authentication Certificates
How it works

The attacker steals existing certificates and their private keys, from the user or machine store, from files, or by converting a certificate to an NT LAN Manager (NTLM) hash via Public Key Cryptography for Initial Authentication in Kerberos (PKINIT).

Prerequisites

Access to the store or files: Risk: an interactive session or user Data Protection API (DPAPI) keys (user certs), SYSTEM (machine certs), or file access to .pfx files.

What makes an environment vulnerable

Risk: Software-stored (exportable) private keys, no hardware protection, .pfx files left on shares, and privileged certs cached on ordinary hosts.

Tools

Mimikatz (crypto::capi/crypto::cng to unlock non-exportable keys), SharpDPAPI, Certipy, Rubeus/Kekeo (PKINIT to New Technology (NT) hash).

# THEFT5: a certificate recovers the account's NT hash via PKINIT (UnPAC-the-hash)
certipy auth -pfx victim.pfx -dc-ip 10.0.0.1
DefenderEvidence it leaves

Verify: DPAPI master-key access, Local Security Authority Subsystem Service (LSASS) access (EDR), and exports from the certificate store; a certificate authenticating from an unexpected host.

ExecutiveAs a pentest finding

"Privileged certificates and keys are recoverable from endpoints." Severity follows the account. Retest: Fix: hardware-backed non-exportable keys, .pfx files removed, and Tier 0 certs kept off lower-tier hosts.

Golden certificate (Certificate Authority (CA) key theft and forging)ATT&CKT1649 Steal or Forge Authentication Certificates · T1552.004 Private Keys
How it works

With admin on the CA, the attacker exports the CA certificate and its private key, then forges certificates offline for any account, choosing the identity and Security Identifier (SID) so they beat strong mapping.

Prerequisites

Risk: Administrative access to the CA host and a software-stored (exportable) CA key.

What makes an environment vulnerable

Risk: A CA private key not protected by an Hardware Security Module (HSM)/Trusted Platform Module (TPM); a CA host that isn't Tier 0-hardened. Any ESC5/ESC7 path that reaches the host enables this.

Tools

Certipy (ca -backup to extract the key; forge to mint certificates), ForgeCert, Mimikatz.

# Recognise: extracting the CA key, then offline forging
certipy ca -backup -ca CORP-CA ...     # exfiltrate CA cert + key
certipy forge -ca-pfx ca.pfx -upn administrator@corp.example ...
DefenderEvidence it leaves

Verify: CA private-key export/backup events (4876/4877), certificate-store access on the CA, and later Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) logons for accounts that never enrolled, with no matching 4887 (because the cert was forged, not issued).

ExecutiveAs a pentest finding

"The CA private key is exposed, enabling forged certificates for any identity." Critical, and a persistence crisis: eviction requires Fix: reissuing the CA, not password resets. Retest: CA key moved to an HSM, CA host hardened, and key exposure confirmed remediated.

How CA-side findings chain

  1. Enumerate the Certificate Authority (CA), not just templates: config flags, CA rights, web/Remote Procedure Call (RPC) endpoints, Public Key Infrastructure (PKI) object Access Control Lists (ACLs), and host access.
  2. Pick the path that ignores mapping: ESC7 SubCA, or relay as a coerced Domain Controller (DC), or (with host access) the CA key, Risk: none of which strong mapping stops.
  3. Reach the objective: a DC or admin certificate, then Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) and DCSync; or the CA key, then offline forging.
  4. Consider persistence: a golden certificate or a rogue CA in NTAuthCertificates is Risk: durable beyond normal eviction.
  5. Report by reach and durability: CA-side findings are usually critical, and the golden-certificate case is a persistence crisis, not just an escalation.
06

Defender's playbook

Defender

The strategy: treat the Certificate Authority (CA) as Tier 0, Fix: protect the private key in hardware, restrict CA admin and officer rights, close or harden the relay endpoints, remove the Subject Alternative Name (SAN) flag, and audit issuance so forged and misissued certificates stand out.

Quick wins (days)

  1. Check for the ESC6 flag and the ICertPassage Remote Protocol (ICPR) encryption flag, and fix both. If the SAN flag is set, remove it, restart, and Verify: revoke certificates issued while it was on.
    certutil -config 'CA-HOST\CA-NAME' -getreg policy\EditFlags
certutil -config 'CA-HOST\CA-NAME' -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST
net stop certsvc && net start certsvc
  2. Harden or remove web enrollment (ESC8): Fix: enforce Hypertext Transfer Protocol Secure (HTTPS) with Extended Protection for Authentication (EPA) (channel binding) and disable NT LAN Manager (NTLM) on the endpoint, or remove the role if unused.
  3. Restrict CA rights (ESC7): remove ManageCA and ManageCertificates from service, monitoring and help-desk accounts; Fix: leave only named Public Key Infrastructure (PKI) admins and audit the officer list.
  4. Patch coercion: apply the PetitPotam/printer-bug patches, Fix: disable the Print Spooler where unneeded, and enforce Server Message Block (SMB) and Lightweight Directory Access Protocol (LDAP) signing, so there's nothing to relay.
  5. Lock PKI object Access Control Lists (ACLs) (ESC5): restrict write on the objects under CN=Public Key Services and local admin on the CA host to the PKI Tier 0 group.
  6. Turn on CA auditing so you get 4886/4887 and the CA security events; Verify: you cannot detect most of this without it.

Longer-term fixes (weeks to months)

  1. Move the CA private key into an Hardware Security Module (HSM) (or at least ensure a TPM-backed, non-exportable key). Fix: This is the single highest-value control; it defeats golden certificates even if the host is compromised.
  2. Manage the CA as Tier 0: dedicated admins, a privileged management path/Privileged Access Workstation (PAW), restricted local admin, and monitoring on par with a domain controller.
  3. Protect endpoint keys: prefer non-exportable, hardware-backed keys for high-value certificates so THEFT1–3 fail; keep Tier 0 certs off lower-tier hosts.
  4. Sweep for key material: hunt .pfx/.p12 files on shares and endpoints (THEFT4) and remove them.
  5. Add Active Directory Certificate Services (AD CS) to the Incident Response (IR) playbook: Verify: how to detect forged certs, check NTAuthCertificates, and reissue the CA if the key is compromised.
  6. Continuous checking: schedule Certipy/BloodHound collection and alert when a CA flag, right, endpoint or NTAuthCertificates entry changes.

Detection signals

SignalSourceAlert on
4876 / 4877: CA backup started / completedCA Security logVerify: Any CA private-key backup/export outside a planned task
4882 / 4890: CA security / officer settings changedCA Security logChanges to ManageCA, ManageCertificates, or officer restrictions (ESC7 setup)
4886 / 4887: certificate requested / issuedCA Security logIssued SAN ≠ requester (ESC6), a Verify: Domain Controller (DC) machine-account cert from a non-DC relay host (ESC8/11), SubCA issuance
Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) logon with no matching 4887DC + CA logs correlatedVerify: A forged (golden) certificate, issued by no one
5136 on PKI objectsDC Security log (directory-change auditing)Changes to NTAuthCertificates, the CA object, or its Discretionary Access Control List (DACL) (ESC5, DPERSIST2)
Coercion Remote Procedure Call (RPC) + relayNetwork, Microsoft Defender for Identity (MDI)Encrypting File System Remote Protocol (EFSRPC) / MS-RPRN to an unexpected host, then a cert request from that host
MDI AD CS alertsMicrosoft Defender for IdentitySuspicious enrollment, relay, and CA-key activity

Verify the fix worked

  1. Re-check EditFlags (no SAN flag) and InterfaceFlags (IF_ENFORCEENCRYPTICERTREQUEST set); Verify: re-run certipy find and confirm ESC5/6/7 no longer flag.
  2. From an unauthenticated position, confirm the relay fails against both web enrollment and ICPR (coordinate the test).
  3. Confirm ManageCA/ManageCertificates are limited to named PKI admins and the SubCA template is disabled or locked.
  4. Confirm the CA key is non-exportable (HSM/Trusted Platform Module (TPM)) and that Verify: a key-export attempt fails and alerts.
  5. Confirm CA auditing is on and that a test misissue raises the 4887-subject-mismatch alert.

Why remediation stalls, and workable compromises

ObjectionWorkable compromise
"We can't move the CA key to an HSM yet."Short-term: lock down CA local admin hard and alert on 4876/4877; Fix: plan the HSM for the next CA refresh, and never defer it on a new build.
"We need web enrollment for some clients."Keep it, but Fix: enforce HTTPS + EPA and disable NTLM; that removes the relay without removing the feature.
"Enforcing ICPR encryption might break old clients."Test, then set the flag; most modern clients already use packet privacy. The exposure is CA-wide, so it's worth the test cycle.
"The CA team is separate and busy."Scope it to the handful of flagged items (flag, rights, endpoints, key) and a joint review, not the whole PKI.
"Removing CA officer rights breaks an approval workflow."Move approvals to a named admin on a PAW; if automation is required, Fix: scope it and monitor 4882/4887.
"Reissuing the CA is too disruptive to consider."You only need it if the key is compromised. Fix: Prevent that with an HSM so you never have to.
07

Executive brief

Executive

The risk in plain language

Our certificate service, the system behind Wi-Fi, Virtual Private Network (VPN) and smart cards, has a few weak points on the server itself, separate from the "forms" we discussed before. The most serious: if an attacker copies the server's Risk: master key, they can forge valid credentials for anyone, for years, and ordinary cleanup won't remove them. A second, Risk: an attacker can trick a core server into logging in and redirect that to the certificate service to mint an administrator credential, with no password involved.

Business impact

  • A path from a normal network foothold to Risk: full control of the Windows environment, the precondition for ransomware and mass data theft.
  • If the master key is stolen, Risk: persistent access that survives our normal incident recovery, potentially forcing us to rebuild part of the certificate system.
  • The certificate service turns out to be as powerful as our most critical servers, Risk: but is often managed with less care.

What drives likelihood

  • A master key stored in software rather than tamper-proof hardware, so it can be copied.
  • Administrative rights on the certificate service handed to service or support accounts.
  • Network request points left open to an older, forwardable login style.
  • No monitoring of certificate issuance or key access, so abuse looks routine.

Cost of inaction

The fixes are configuration plus one piece of hardware: protect the master key in a tamper-proof module, tighten who administers the service, and close the relay. Leaving them means any phishing success is Risk: a short step from total, durable compromise of a system most organizations don't watch, and the worst-case cleanup is Risk: a certificate-system rebuild.

What good looks like

  • The master key is Fix: in tamper-proof hardware and can't be copied out.
  • Only a Fix: small, named team can administer the certificate service.
  • The request endpoints require Fix: modern, protected logins, or are turned off.
  • The service is Fix: monitored like a domain controller, and we're Verify: alerted on key access and trust changes.

Questions executives ask

Part 1 was about templates. What's different about these attacks?

"These target the certificate server itself, not just one of its forms. A single server-wide setting, who administers the server, how it's reachable over the network, and above all its master key. Fixing them protects the whole service at once, and it's why we insist the certificate server be treated like our most critical systems."

You said an attacker could take over the domain without any password. How?

"One way: we force a domain controller to introduce itself to us, then forward that introduction to the certificate server, which hands us a credential for that domain controller. Risk: No password is ever involved. It works because the server accepts an older, forwardable kind of login. The fix is to require a modern, tamper-proof login on that server, or turn off the feature we don't need."

What is a 'golden certificate' and why does it scare you?

"If an attacker copies the certificate server's master key, they can forge credentials for anyone, forever, Risk: without asking the server. Resetting passwords won't help, because these aren't passwords. Cleaning it up can mean rebuilding part of the certificate system. That's why protecting that one key, ideally in tamper-proof hardware, is the highest-value thing we can do here."

If this happened, could we just reset credentials like a normal breach?

"No, and that's the point. Risk: Certificates survive password resets and even our Kerberos master-key rotation. A forged one keeps working until we replace the certificate server's own key, which invalidates everything it signed and forces everyone to re-enroll. It's doable, but it's a project, so prevention is far cheaper."

What would protect the master key?

"Storing it in a hardware security module, a tamper-proof device that Fix: never lets the key be copied out. New or rebuilt certificate servers should use one. Combined with treating that server like a domain controller, locked down and watched, it closes the worst outcome."

How do we know if we're exposed to the relay attack?

"We check two things: whether the certificate server's web and network request points accept the old login style without protection, and whether our domain controllers can be tricked into logging in somewhere. Verify: Both are quick to verify, and both have concrete fixes we can apply and re-test."

Presenting this finding to leadership

  1. Headline: "An attacker could forge credentials for anyone by stealing one key, or mint an admin credential by relaying a server's login, Risk: with no password cracked."
  2. Make it concrete: name the exposed key or right and what it reached; show the forged or relayed logon.
  3. Set the fix in proportion: tamper-proof hardware for one key, plus configuration, and treating the service as a crown jewel.
  4. The ask: fund the hardware module, restrict administration, close the relay, and add monitoring of issuance and key access.
08

Talk the talk

Jargon decoder

ESC6

A CA-wide flag that lets any requester add a Subject Alternative Name to a request.

"The Certificate Authority (CA) has ESC6 enabled; user-specified Subject Alternative Name (SAN) is on for every template."

ESC7

Abuse of Certificate Authority (CA) administrative rights (ManageCA / ManageCertificates) to issue privileged certificates.

"That service account has ManageCertificates, so ESC7 via the SubCA path is open."

ESC8

Relaying coerced NT LAN Manager (NTLM) authentication to the Certificate Authority (CA)'s Hypertext Transfer Protocol (HTTP) web-enrollment endpoint.

"Web enrollment is on with NTLM, classic ESC8; coerce a Domain Controller (DC) and relay."

ESC11

The same relay as ESC8 but to the Certificate Authority (CA)'s ICertPassage Remote Protocol (ICPR) Remote Procedure Call (RPC) interface.

"They removed web enrollment but didn't enforce RPC encryption, so ESC11 still works."

ManageCA

The Certificate Authority (CA) administrator right: change configuration and grant other CA rights.

"With ManageCA you can flip the Subject Alternative Name (SAN) flag or make yourself an officer."

ManageCertificates

The Certificate Authority (CA) officer right: approve, issue or deny pending certificate requests.

"ManageCertificates lets you approve the failed SubCA request you submitted."

Coercion

Forcing a chosen machine to authenticate on command, e.g. PetitPotam.

"We coerced the Domain Controller (DC) over Encrypting File System Remote Protocol (EFSRPC) to feed the relay."

NT LAN Manager (NTLM) relay

Forwarding someone else's authentication to a target that accepts it.

"ntlmrelayx forwarded the Domain Controller (DC)'s auth straight to the Certificate Authority (CA)."

Extended Protection for Authentication (EPA)

Extended Protection for Authentication: channel binding that defeats relay.

"Turn on EPA at the enrollment endpoint and ESC8 dies."

Golden certificate

A certificate forged offline with the stolen Certificate Authority (CA) private key, for any identity.

"If they got the CA key, assume golden certificates and plan a reissue."

Certificate Authority (CA) private key

The key the CA signs every certificate with; the crown jewel.

"Is the CA key in an Hardware Security Module (HSM), or exportable software storage?"

Hardware Security Module (HSM)

A hardware module that keeps keys non-exportable.

"The Certificate Authority (CA) key is in an HSM, so a golden-certificate forge isn't possible."

Data Protection API (DPAPI)

The Windows service encrypting stored secrets, including certificate keys.

"We pulled the user's cert from DPAPI with SharpDPAPI."

SubCA template

The built-in Subordinate Certificate Authority (CA) template, central to the ESC7 approval trick.

"Enable SubCA with ManageCA, request, then approve as an officer."

Smart questions to ask

Sysadmins

  • Is the Certificate Authority (CA) private key in an Fix: Hardware Security Module (HSM)/Trusted Platform Module (TPM), or software-exportable?
  • Is EDITF_ATTRIBUTESUBJECTALTNAME2 set, and is IF_ENFORCEENCRYPTICERTREQUEST enforced?
  • Who holds ManageCA and ManageCertificates, and Risk: is the officer list audited?
  • Is web enrollment on, and does it Fix: require Hypertext Transfer Protocol Secure (HTTPS) + Extended Protection for Authentication (EPA) with NT LAN Manager (NTLM) disabled?
  • Do you audit CA issuance (4886/4887) and Verify: key backup (4876/4877)?
  • Do you alert on changes to Verify: NTAuthCertificates and the CA object?

Executives

  • Is our certificate service's master key Fix: protected in tamper-proof hardware?
  • Do we manage that service with the same care as a domain controller?
  • If it were abused, could we detect it and recover without rebuilding?

Coworkers

  • Did we validate the relay live, or just note the endpoint is on?
  • Is this ESC6 finding standalone or paired with a SID-strip for impersonation?
  • If we reached CA admin, did we confirm Risk: the key is exportable before claiming golden-cert risk?

Say this, not that

Not this

"The Certificate Authority (CA) has a bad template."

Say this

"The CA has a server-wide flag (ESC6); it affects every template, so it's not a template fix."

Not this

"Someone has admin on the Certificate Authority (CA), so what."

Say this

"CA admin means they can export the signing key and forge certificates for anyone; it's domain-control-equivalent."

Not this

"We removed web enrollment, so relay is handled."

Say this

"That closes ESC8, but ESC11 relays over Remote Procedure Call (RPC) unless we enforce the ICertPassage Remote Protocol (ICPR) encryption flag."

Not this

"Reset the admin passwords to contain it."

Say this

"If the Certificate Authority (CA) key leaked, resets won't help; we revoke and reissue the CA, then re-enroll."

Not this

"The monitoring account just approves certs."

Say this

"That's ManageCertificates; with it they can approve a SubCA request and become an admin (ESC7)."

Not this

"ESC6 is critical because of the Subject Alternative Name (SAN) flag."

Say this

"ESC6 alone maps back to the requester post-2022; it's critical when paired with a SID-strip, so rate it in context."

Not this

"The Certificate Authority (CA) is just another Windows server."

Say this

"The CA is Tier 0; put the key in an Hardware Security Module (HSM) and manage the host like a domain controller."

Same point, two audiences

The Certificate Authority (CA) private key is the crown jewel.
Executive

"One key on the certificate server lets you create any credential. Protect it in tamper-proof hardware and the worst case goes away."

Sysadmin

"Move the CA key to an Hardware Security Module (HSM) so it's non-exportable; that kills golden-certificate forging even if the host is compromised."

Relay turns a network foothold into domain admin.
Executive

"An attacker can trick a core server into logging in, then redirect that to the certificate server to mint an administrator credential, no password needed."

Sysadmin

"Coerce a Domain Controller (DC) with PetitPotam, relay to web enrollment or ICertPassage Remote Protocol (ICPR), get a DC cert, Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), DCSync. Fix with Extended Protection for Authentication (EPA)/Hypertext Transfer Protocol Secure (HTTPS), NT LAN Manager (NTLM) off, and the ICPR encryption flag."

Certificate Authority (CA) admin rights are privileged, separately from enrollment.
Executive

"Being able to run the certificate server is as powerful as being a top administrator; it shouldn't be handed out casually."

Sysadmin

"ManageCA and ManageCertificates are Tier 0 rights; remove them from service and help-desk accounts and audit the officer list."

Certificate persistence needs special eviction.
Executive

"If this is abused, normal cleanup won't remove the attacker; we may have to reissue the certificate system."

Sysadmin

"Golden certs survive password and krbtgt resets; eviction is Certificate Authority (CA) key rotation/reissue plus re-enrollment, and checking NTAuthCertificates for rogue CAs."

09

Keep going

What's next in this series

  1. Part 3: Defeating the mapping, and the newer escalations. ESC9 and ESC10 (certificates and accounts that drop or dodge the Security Identifier (SID) extension), ESC13 (issuance policy to group), ESC14 (weak explicit altSecurityIdentities mappings), ESC15/EKUwu (Common Vulnerabilities and Exposures (CVE) entry CVE-2024-49019, application-policy injection on v1 templates), ESC16 (the Certificate Authority (CA) omitting the SID extension for everyone), ESC17, and the full hardening and remediation program that ties the series together. Say "continue" to build it.

Related notes

  • Active Directory Certificate Services (AD CS) abuse, Part 1. Templates, how certificates authenticate, and the strong-mapping enforcement these attacks lean on.
  • Active Directory attack paths, thinking in graphs. ESC5 is the ACL-edge problem pointed at Public Key Infrastructure (PKI); ADCSESC edges and the GoldenCert edge appear there.
  • The Kerberos series. Coercion, relay, Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) and DCSync connect directly to ESC8/ESC11.

Resources worth seeking out

  • "Certified Pre-Owned" (SpecterOps, 2021), the source for THEFT1–5, the golden certificate and DPERSIST1–3.
  • Compass Security's "Relaying to Active Directory (AD) Certificate Services over Remote Procedure Call (RPC)" (2022), the ESC11 research.
  • The Certipy wiki (ly4k/Certipy), for the CA-subcommand abuse and enumeration.
  • Microsoft's AD CS auditing guidance, for turning on the 4886/4887/4876/4877 events these detections rely on.
  • Locksmith and PSPKIAudit, for defensive enumeration and remediation, including CA configuration and Access Control Lists (ACLs).
My private notebook

Personal notes and bookmarks are private. Unsaved text is temporarily kept in this tab’s browser storage to recover supported sign-in redirects and reloads. Closing the tab may lose unsaved text.

Checking sign-in…

Sign in in another tab Sign in in this tab All my notes