Certificates

Active Directory Certificate Services (AD CS) issues certificates that Windows accepts as authentication material: a certificate with a client-authentication purpose can be used with PKINIT to obtain a Kerberos TGT, so holding the right certificate is holding the identity it names. AD CS is widely deployed, frequently misconfigured, and rarely monitored, which is why the "Certified Pre-Owned" family of techniques turns it into one of the most reliable escalation paths to Domain Admin.

Why a certificate is an identity#

  • A certificate binds a subject (often a UPN or, since the security-extension update, a SID) to a key pair.
  • A domain controller maps that subject to an account and issues a TGT (PKINIT) or authenticates a TLS session (Schannel).
  • So if you can obtain a certificate that names a privileged account, or weaken how the mapping is enforced, you authenticate as that account, no password or hash required.

Every AD CS attack is a variation on this: get a certificate you should not have (template, CA, or relay abuse), or break the mapping that is supposed to tie a certificate to its rightful owner.

The classes of abuse#

  • Template misconfiguration (ESC1, ESC2, ESC3, ESC13, ESC15): a template lets a low-privileged user enrol for a certificate that authenticates as someone else.
  • Certificate mapping (ESC9, ESC10, ESC14): weakened or missing SID binding lets a certificate map to a more privileged account than it names.
  • Access control (ESC4, ESC5, ESC7): write access over templates, PKI objects, or CA roles is turned into enrolment.
  • CA configuration (ESC6, ESC16): a CA flag that lets any request specify its own subject, or that disables the SID binding domain-wide.
  • Enrolment relay (ESC8, ESC11): NTLM relay to the CA's HTTP or RPC enrolment endpoints.

Pages#

References#

  • SpecterOps: Certified Pre-Owned (AD CS abuse)
  • The Hacker Recipes: AD CS

Cookie Consent

We use cookies to enhance your experience. Learn more