"ReCertifying Active Directory was presented at BlackHat EU 2021 by Will Schroeder and Lee Christensen.

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