Skip to content

AD-CHAIN-004: ESC6 plus ESC16 on the same CA

medium high   Attack paths   MITRE ATT&CK T1649   Reads: derived from other findings

The same CA has ESC6 and ESC16, so a requester can put any user's SID in a SAN URL and authenticate as that user even under strong-mapping enforcement.

Why it matters

The two CA-side weaknesses cancel out the protection that KB5014754 added:

  • ESC6 (AD-ADCS-012) lets a requester supply an arbitrary subject alternative name on any request.
  • ESC16 (AD-ADCS-015) stops the CA from stamping the requester's real SID into the certificate.

With both on one CA, the attacker supplies not just a victim's name but the victim's SID in a SAN URL of the form tag:microsoft.com,2022-09-14:sid:<SID>. A DC in full strong-mapping mode reads that SID from the SAN, finds no conflicting SID extension (ESC16 removed it), and accepts the certificate as a strong mapping to the victim. The result is authentication as any account even on a fully patched, fully enforcing domain, which is why the pair is rated far above either weakness alone.

How ad-doctor detects it

A compound finding derived from the CA-side registry reads: ad-doctor reports a CA here when both policy\EditFlags has EDITF_ATTRIBUTESUBJECTALTNAME2 (ESC6) and policy\DisableExtensionList contains the SID extension OID 1.3.6.1.4.1.311.25.2 (ESC16). No extra probe is made; it combines the two single-weakness checks on the same CA object.

Attributes and probes read
  • policy\EditFlags (EDITF_ATTRIBUTESUBJECTALTNAME2)
  • policy\DisableExtensionList (szOID_NTDS_CA_SECURITY_EXT)

Severity

High. On its own, ESC6 is blocked by the SID check of patched DCs and ESC16 needs a DC in compatibility mode; together on one CA they defeat full enforcement, so any enrollee can authenticate as any user, a domain admin included, on a fully patched domain. Drops to medium when every such CA holds requests for a manager (RequestDisposition has REQDISP_PENDING), since a CA manager must then approve the forged request.

False positives and limits

  • There is no benign reason for a CA to both accept SANs from attributes and drop the SID extension. Treat this as a live path to domain compromise and fix at least one side at once.

Fix

Fixing either side breaks the chain; fix both:

  1. Clear the SAN flag:

    certutil -config "<host>\<CA name>" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

  2. Re-enable the SID extension:

    certutil -config "<host>\<CA name>" -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2

  3. Restart the service and review recently issued certificates:

    net stop certsvc & net start certsvc

Verify

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

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

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

References

Microsoft and vendors

Research

Tools

MITRE ATT&CK

New in the next release.