Skip to content

AD-ADCS-017: ESC17: enrollee-supplied subject on a server authentication template

medium   Certificate services   MITRE ATT&CK T1649, T1557   Reads: LDAP

A published template with the Server Authentication EKU lets broad groups supply the subject, so any enrollee can get a trusted TLS certificate for any internal host name.

Also known as: esc17

Why it matters

ESC17 is ESC1 for servers. The requester names the subject, and the template issues a certificate for server authentication, so a low-privileged user can ask for wsus.corp.example and receive a certificate every domain member trusts.

With it an attacker can pose as an internal TLS service. The public attacks target WSUS over HTTPS: relay the client's authentication to LDAP, or serve it a malicious update. Getting the client to connect takes something more, for example a DNS record the attacker can write.

Admins can create this by accident when they "fix" ESC1 by swapping Client Authentication for Server Authentication, and clones of the built-in WebServer template behave the same way.

How ad-doctor detects it

A published template is reported when all of these hold:

  • CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT is set;
  • its EKUs contain Server Authentication (1.3.6.1.5.5.7.3.1);
  • no manager approval and no authorized signatures are required;
  • a broad group (Domain Users, Domain Computers, Authenticated Users, Everyone) can enroll.

Certipy and Locksmith flag the same combination. Two differences:

  • Certipy also counts Any Purpose and no-EKU templates. Those, and templates that also have a client authentication EKU, are left to AD-ADCS-001 and AD-ADCS-002, so one template is not reported twice for the same reason.
  • Both tools report any enrollee outside their safe list; like the other template checks, this one only looks at broad groups.

A schema v1 template can fire together with AD-ADCS-008: they describe different problems. The object looks like LabESC15 (enroll: Domain Users).

Attributes and probes read
  • msPKI-Certificate-Name-Flag (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 0x1)
  • pKIExtendedKeyUsage
  • msPKI-Certificate-Application-Policy
  • msPKI-Enrollment-Flag (CT_FLAG_PEND_ALL_REQUESTS 0x2)
  • msPKI-RA-Signature
  • nTSecurityDescriptor (template DACL)
  • certificateTemplates (on pKIEnrollmentService)

Severity

Always medium: a Server Authentication certificate cannot log on to the domain by itself (on a schema v1 template see AD-ADCS-008). The abuse also needs a service worth impersonating and a way into its traffic, and such a template is often deliberate.

False positives and limits

  • A deliberate web server template. If only a few servers or admins may enroll, it does not fire. If it fires, a broad group can enroll, and that is the part to fix.
  • No service worth impersonating. Certipy's wiki says exploitation depends on further prerequisites, and ad-doctor does not check them.

Fix

  1. Limit enrollment to the servers or admins that need the template. Do not rely on Domain Computers: any compromised computer account can then enroll.

  2. Require CA certificate manager approval where the requester must supply the subject:

    $t = "CN=LabESC15,CN=Certificate Templates,CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)"
Set-ADObject $t -Replace @{ 'msPKI-Enrollment-Flag' = 2 } -WhatIf

  3. Or clear Supply in the request on the template's Subject Name tab, or unpublish the template if nobody uses it.

  4. Review certificates already issued from the template for host names that do not belong to the requester.

Verify

ad-doctor scan dc01.corp.example --ldaps -u 'CORP\auditor' --only AD-ADCS-017

To accept the risk instead, add an entry to the file passed with --accept (see accepted risks):

[[accept]]
check = "AD-ADCS-017"
objects = ["..."]        # optional; without it the whole check is accepted
reason = "..."
expires = 2027-03-31

References

Research

Tools

MITRE ATT&CK

New in the next release.