The document discusses the vulnerabilities and defense strategies associated with Active Directory Certificate Services (AD CS), particularly focusing on various attack methods and their impacts. It outlines the importance of properly securing AD CS to prevent unauthorized certificate enrollment and domain escalation, and emphasizes the necessity of monitoring and auditing certificate activities. Recommendations for incident response and key defensive measures are also provided to mitigate risks associated with certificate management.

1. ReCertifying Active
Directory
@harmj0y and @tifkin_

2. TL;DR
- Background
- Attacks against AD CS
- Defenses
- Incident Response
2

3. 1
Background
...
3

4. Active Directory Certificate Services
▪ A server role
▪ Microsoft’s public key infrastructure
(PKI) implementation
▫ Used by organizations for smart cards, SSL
certificates, code signing, etc.
▪ Clients send certificate signing requests
(CSRs) to a certificate authority(CA),
which signs issued certificates using the
private key for the CA certificate 4

5. Certificate Enrollment
5

6. Certificate Templates
CAs issue certificates with “blueprint” settings
defined by certificate templates (stored as AD objects)
6

7. NTAuthCertificates
7
Defines the root of domain-based certificate auth!

8. Subject Alternative Names (SANs)
▪ Allows additional identities to be bound to a
certificate beyond the Subject
▪ Can be dangerous when combined with certificates
that allow domain authentication!
▫ AD maps certificates to AD user accounts using the SAN
8

9. Aren’t Smartcards Necessary for Abuse?
▪ No! Rubeus and Kekeo support Kerberos
authentication using certificates via PKINIT
▫ Schannel authentication also supports certificates (e.g., LDAPS)
▪ Certificate must
▫ Have EKU’s that permit AD auth (e.g., Client Authentication)
▫ Be signed by a CA in NTAuthCertificates
9

10. 2
Attacks Against AD CS
...
10
And How to Defend

11. AD CS Attack Summary
11
Our “Certified Pre-Owned” whitepaper codified
these attack classes against AD CS:
THEFT* User/machine certificate theft
(5 attacks)
PERSIST* Active certificate enrollment
(3 attacks)
ESC* Domain escalation (8 attacks)
DPERSIST* Domain persistence (3 attacks)

12. Malicious Certificate Enrollments (PERSIST*)
▪ Users/machines can enroll in any template
they have “Enroll” permissions for
▪ If the certificate allows for domain
authentication (some defaults do) we can
persist in their account context
▫ Doesn’t touch LSASS
▫ Doesn’t need elevation (for user contexts)
▫ Separate credential material from passwords
(still valid after password resets)
12

13. 13

14. THEFT*/PERSIST* Defense: Overview
▪ Detect non-LSASS reading of DPAPI-encrypted keys
▫ Monitor file opens/reads of DPAPI files (SACLs*?)
■ (Local)AppData folders:
Microsoft[Crypto | Protect | Vault | Credentials]
▪ Monitor certificate auth/enrollment events
▫ EIDs 4886/4887, EID 4768 (more on these later)
▪ Monitor for Certificate Authentication events
▫ EID 4768 with PKINIT certificate information
(more on this later)
▪ “Honey Credentials” in certificate form
14
*https://medium.com/@cryps1s/detecting-windows-endpoint-compromise-with-sacls-cd748e10950

15. Requirements:
1. Low-privileged user can enroll in the template
2. No “Issuance Restrictions”
3. [PKINIT] Client Authentication EKU, Smart Card Logon
EKU, Any Purpose EKU, or No EKU
4. The ENROLLEE_SUPPLIES_SUBJECT flag set on the template
▫ Template’s AD object has msPKI-Certificate-Name-Flag set to 1 in its bitmask
ESC1 - ENROLLEE_SUPPLIES_SUBJECT
15

16. ESC1 - Impact
▪ Allows an attacker
to supply an
arbitrary SAN when
requesting a
domain-auth capable
certificate
▪ Translation: they can
become anyone in the
domain!
16

17. ESC8-NTLM Relay to HTTP Enrollment Endpoints
▪ AD CS web enrollment endpoints are optional
roles (but commonly installed)
▫ All of these endpoints are vulnerable to NTLM relay!
▪ If there is a machine-enrollable
auth template:
▫ Combine with printer bug or PetitPotam for coerced auth
▫ Translation: we take over ANY computer in the domain! 17

18. ESC* Defense: Hardening
18
▪ Audit/harden CA settings for every CA!
▫ Manager/Enroll/Control rights
▪ Audit/harden certificate template settings
▫ Enroll/Control rights
▪ Harden AD CS HTTP enrollment endpoints
▫ Remove them if not needed
▫ Enable NTLM(-relay) protections
■ HTTPS + channel binding or remove NTLM
authentication from IIS
■ Ideally, disable NTLM completely at the host
level and throughout the domain :)

19. 19
ESC* Defense:
Identifying Misconfigured Templates

20. 20
ESC*/PERSIST* Defense:
Monitor Certificate Requests and Auth
▪ Monitor cert enrollments (EIDs 4886/4887)
▪ Monitor for Certificate Authentication events
▫ EID 4768 with PKINIT certificate information

21. ESC* Defense:
Monitoring AD
▪ Audit NTAuthCerticates
▫ LDAP/certutil/pkiview
▫ SACLs + EID 4662/5136
21
▪ Monitor certificate
template modifications
▫ EID 4899
▫ SACLs + EID 4662/5136
msPKI-Certificate-Name-Flag

22. Finding Requester Info
▪ Collect weblogs from the IIS-host HTTP
enrollment servers
▪ CA database contains
requester info and
the raw CSR bytes
▫ C:WindowsSystem32CertLog<CA NAME>.edb
▫ Abnormal user agents + processes
▫ Abnormal/missing CSR fields
22

23. “Golden Certificates”
▪ If the private key for a CA’s certificate is not
protected by a TPM/HSM, DPAPI is used
▫ CAs sign issued certificates with this key
▪ Attackers can steal DPAPI-protected private keys
▪ If the CA is in NTAuthCertificates, attackers can
forge certificates as anyone in the domain!
▫ Can’t be revoked as the certs aren’t actually “issued”!
▫ Work as long as the CA cert is valid!
23

24. “Golden Certificates” and DPERSIST* Defense
▪ Detect non-LSASS reading of DPAPI-encrypted
keys (as previously covered)
▪ Monitor CA backup started/completion events
(EID 4876/4877)
▫ Requires enabling CA audit logs
24

25. A Novel “Golden Certificate” Defense
▪ Fabian Bader put out a great post* on
using IssuedSerialNumbersDirectories to
deny UNKNOWN serial # OCSP requests
25
*https://cloudbrothers.info/en/golden-certificate-ocsp/

26. ▪ Abnormal serial numbers
▫ https://www.pkisolutions.com/adcs-ce
rtificate-serial-number-generation-a
lgorithms-a-comrehensive-guide/
▪ Thumbprints that aren’t
in the CA DB’s log of
issued certs
26
Hunting Ideas for Forged Certificates

27. High Level Architecture Guidance
▪ Treat CAs as Tier 0 Assets!
▪ Hardware protect CA keys
▪ Internal root CAs should be offline, with
subordinate CAs doing issuance
▫ A proper architecture is worth investing in!
27

28. A Note on Response
...
28

29. Do you know:
If AD CS has issued a specific user a certificate?
Which users/machines requested a specific template?
If an alternate SAN was specified in a request?
29

30. AD CS Response
▪ If you have AD CS and a computer/user is
compromised, you need to be able to
answer these questions!
▫ PSPKIAudit can help here
▪ Organizations also need to streamline the
certificate revocation process
▫ Possible through the GUI or PSPKI
▪ Make plans for how to respond to a
compromised subordinate/root CA 30

31. 31

32. 32

33. 33

34. Defensive Gaps
34
▪ Few people have deep knowledge of AD CS
▫ “It’s the boiler in the basement”
▫ It’s very easy to accidentally misconfigure an AD CS
deployment
▫ Lots of third-party products “encourage” you to
configure things incorrectly
▪ Certificate Services event logs leave a
lot to be desired
▪ Most of us just haven’t been paying
attention to this!

35. Summary
▪ AD CS is dangerous if not handled properly
▪ Attack tooling (and knowledge) is now out there!
▪ Defenses:
▫ Develop an AD CS incident response plan
▫ Audit relevant AD CS event logs
▫ Audit/triage certificate issues with PSPKIAudit
▪ Our whitepaper has complete details
▫ https://bit.ly/3xLziQ9
35

36. Acknowledgements
▪ Previous work (see the paper for complete
details):
▫ Benjamin Delpy, PKISolutions, Christoph Falta, CQURE,
Keyfactor, @Elkement, Carl Sörqvist, Brad Hill
▫ Risk-Insight’s Similar Work/Findings:
■ https://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/
▪ Ceri Coburn and Charlie Clark for related Rubeus
additions
▪ Special thanks to Mark Gamache for collaborating
with us on parts of this work 36

37. Thanks!
ANY QUESTIONS?
You can find us at:
@harmj0y | @tifkin_
[will | lee] @specterops.io
AD CS Whitepaper: https://bit.ly/3xLziQ9
37