Certificate Services Abuse
Also calledAD CS abuse, ESC1, ESC4, ESC8
Gets a certificate that signs in as another account, often a Domain Admin.
- Hooks Into
- Kerberos AS Request
- Needs
- Domain AccountorIncoming Sign-In
- Gives
- CertificateandNT HashandDomain AdminandDC Account
How the Attack Works
A certificate authority issues certificates as its templates allow, and a DC accepts a certificate for Kerberos sign-in as the account it names (PKINIT). Where a template allows client authentication and lets the requester supply the subject (ESC1), any account it lets enrol can ask for a certificate naming a Domain Admin. Write access to a template can create that weakness (ESC4), and NTLM relayed to web enrolment gets a certificate for the victim (ESC8). The certificate keeps working after a password reset, and certificate sign-in also hands back the account's NT hash.
Read first Certificate Sign-In (PKINIT), AS Request and Pre-Authentication
How It Plays Out
The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.
ws-017 Foothold
ca-01 Certificate authority
dc-01 Domain controller
- krbtgt key
Step 1 of 4: Certificate Request
ws-017 Foothold to ca-01 Certificate authority
Request for a certificate
PKCS #10 requestDCOM (MS-WCCE)WS-017$ asks ca-01 for a certificate from a template that lets it supply the subject, and names Administrator there.
Logged
4886 Certificate Services received a certificate request
On ca-01, in the Security log When enabled
A request from CORP\WS-017$ to the CorpClientAuth template.
What Defenders See
Where its audit filter records requests, the Security log on ca-01 shows event 4886. The requester is WS-017$, not the account named in the request.
Step 2 of 4: Certificate Issued
ca-01 Certificate authority to ws-017 Foothold
The issued certificate
X.509 certificateDCOM (MS-WCCE)ca-01 issues it at once, because the template asks for no approval, and the CA takes the subject as given.
Logged
4887 Certificate Services approved a certificate request and issued a certificate
On ca-01, in the Security log When enabled
The certificate issued to CORP\WS-017$, its subject naming Administrator.
What Defenders See
The Security log on ca-01 shows event 4887 with the requester and subject. A subject alternative name sent as a request extension is only in the CA database on ca-01.
Step 3 of 4: Certificate Sign-In
ws-017 Foothold to dc-01 Domain controller
Request for a TGT with the certificate
KRB_AS_REQKerberos, port 88ws-017 asks dc-01 for a TGT as Administrator, proving it with the certificate in place of a timestamp (PKINIT).
What Travels in This Step
Pre-authentication
PA-PK-AS-REQThe certificate and a signature made with its private key, in place of an encrypted timestamp
In the clear Anyone who sees the traffic can read it.
Logged
4768 A Kerberos authentication ticket (TGT) was requested
On dc-01, in the Security log
A TGT issue for Administrator with certificate details filled in.
AS Reply: The TGT explains how to read it.
What Defenders See
The Security log on dc-01 shows event 4768 for Administrator with the certificate's issuer, serial number and thumbprint, though the account never uses a certificate.
Hooks into Kerberos AS Request
Step 4 of 4: TGT and NT Hash
dc-01 Domain controller to ws-017 Foothold
Reply with a TGT and the NT hash
KRB_AS_REPKerberos, port 88dc-01 returns a TGT for Administrator whose PAC carries the account's NT hash, encrypted with a key the requester holds.
What Travels in This Step
The TGT
ticketAdministrator's name and groups, with the account's NT hash in its PAC
Encrypted with the krbtgt key Only dc-01 can open it.
Keys and Tickets
- ws-017 now holds TGT (new at this step) TGT session key (new at this step)
What Defenders See
Where its sensors run on ca-01 and the DCs, Defender for Identity raises its AD CS and PKINIT alerts.
Needs First
What the attacker must already hold for this attack to be possible.
- A Domain Account or An Incoming Sign-InAn account a weak template lets enrol, or a forced sign-in relayed to web enrolment (ESC8).
Comes From
- Domain Account: Password Spraying
- Incoming Sign-In: LLMNR, NBT-NS and mDNS Poisoning, Forced Authentication (Coercion)
Gives the Attacker
What running it hands the attacker to use next.
- A Sign-In CertificateA certificate that signs in as the account it names, until it expires or is revoked.
- An NT HashThat account's NT hash, which certificate sign-in returns inside the PAC.
- Domain Admin RightsDomain Admin rights, where the certificate names a Domain Admin (ESC1).
- A DC's Computer AccountA DC's own certificate, where a DC's forced sign-in is relayed to web enrolment (ESC8).
Leads To
- NT Hash: Pass-the-Hash, Overpass-the-Hash
- Domain Admin: LSASS Memory Theft, SAM, LSA Secrets and Cached Logons, NTDS.dit Theft, DCSync every attack that uses it: Domain Admin Rights
- DC Account: DCSync
What Defenders See
What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.
| Event and Log | Written On | Look For | Switch It On |
|---|---|---|---|
| 4886 Certificate Services received a certificate request (opens in a new tab) Security log | The certification authority | A request to a template that lets the requester supply the subject. Note the requester for the issued certificate. | Audit Certification Services on the CA, and the events picked on its Auditing tab (the CA audit filter) |
| 4887 Certificate Services approved a certificate request and issued a certificate (opens in a new tab) Security log | The certification authority | An issued certificate whose subject, or subject alternative name in the CA database, names someone other than the requester. | Audit Certification Services on the CA, and the events picked on its Auditing tab (the CA audit filter) |
| 4768 A Kerberos authentication ticket (TGT) was requested (opens in a new tab) Security log | Domain controllers | Certificate issuer, serial number and thumbprint filled in for an account that never signs in with a certificate.AS Reply: The TGT explains how to read it. | Audit Kerberos Authentication Service |
| 39 to 41 No strong mapping, Certificate predates account, Users SID does not match Certificate SID (opens in a new tab) System log | Domain controllers | A certificate refused because it maps to its account only weakly, or because it carries another account's SID. | Domain controllers with the May 2022 or later updates (KB5014754) |
| 4899 A Certificate Services template was updated (opens in a new tab) Security log | The certification authority | A template whose content changed, such as a newly allowed supplied subject (ESC4). | Audit Certification Services on the CA, and the events picked on its Auditing tab (the CA audit filter) |
| 4900 Certificate Services template security was updated (opens in a new tab) Security log | The certification authority | A template whose security changed, so more accounts may enrol in it or edit it (ESC4). | Audit Certification Services on the CA, and the events picked on its Auditing tab (the CA audit filter) |
| 5136 A directory service object was modified (opens in a new tab) Security log | Domain controllers, for objects with a matching audit entry | A change to a template object in the configuration partition, such as its msPKI-Certificate-Name-Flag (ESC4). | Audit Directory Service Changes, and an audit entry (SACL) on the object |
What It Looks Like
One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.
4887 Certificate Services approved a certificate request and issued a certificate
In the Security log on ca-01,
A certificate issued on ca-01 to one account, naming another.
The request in the CA database. Open it there to read the subject alternative name this event leaves out.
As Windows writes it:
Request ID7311The account that asked, a workstation's computer account. Compare it with every name in the certificate.
As Windows writes it:
RequesterCORP\WS-017$A template that allows client authentication and lets the requester supply the subject. Check what else it issued, then fix it.
As Windows writes it:
AttributesCertificateTemplate:CorpClientAuthThe certificate names the domain's Administrator, not the requester. Revoke it, then look for its sign-ins in 4768.
As Windows writes it:
SubjectCN=Administrator
Defender for Identity Alerts
Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.
- Suspicious Active Directory Certificate Services (AD CS) misconfigured certificate template abuse (ESC1) (opens in a new tab)
- Suspicious Domain Controller certificate request (ESC8) (opens in a new tab)Needs a Defender for Identity sensor on the CA itself.
- Suspicious Active Directory Certificate Services (AD CS) machine certificate issuance abuse (ESC8) (opens in a new tab)
- Kerberos authentication following AD CS compromise (opens in a new tab)
- Suspicious certificate usage over Kerberos protocol (PKINIT) (opens in a new tab)Needs a Defender for Identity sensor on the CA itself.
- Suspicious Kerberos PKINIT authentication (AS-REQ) (opens in a new tab)
Blind Spots
Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.
- 4886 and 4887 have no field for a subject alternative name sent as a request extension, which decides who the certificate signs in as. Read it in the CA database.
- A password reset leaves the certificate working until it expires or is revoked, so revoke it and publish a new revocation list.
Hunt It
The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.
Needs Defender for Identity sensors on the DCs and on the CA itself, which several of these alerts require. An alert marks a suspect request or sign-in, not whom the certificate names. Read that in the CA database.
// Defender for Identity alerts for certificate template abuse and certificate sign-inAlertEvidence| where Timestamp > ago(How to Prevent It
The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.
Hardened certificate templates (opens in a new tab)
Take 'Supply in the request' off templates that allow client authentication, or require CA manager approval, and limit enrolment.
Strong certificate mapping (opens in a new tab)
Keep DCs in full enforcement, so a certificate that maps to its account only weakly is refused.
Extended Protection for Authentication (opens in a new tab)
Require HTTPS with Extended Protection on web enrolment, so a relayed sign-in is refused there (ESC8).
NTLM restrictions (opens in a new tab)
Refuse NTLM on the CA's enrolment services, so no relayed NTLM sign-in is accepted there.
Sources
- MITRE ATT&CK T1649: Steal or Forge Authentication Certificates (opens in a new tab)
- [MS-PKCA] Certificate Mapping (opens in a new tab)
- [MS-PAC] 2.6 PAC Credentials (opens in a new tab)
- Microsoft Support: KB5014754, certificate-based authentication changes on domain controllers (opens in a new tab)
- Microsoft Support: KB5005413, mitigating NTLM relay attacks on AD CS (opens in a new tab)
- Microsoft Learn: Defender for Identity certificate posture assessments (ESC1 to ESC15) (opens in a new tab)
- Microsoft Learn: Securing PKI, the CA events to monitor (opens in a new tab)