CVE-2022-26923 (AD CS dNSHostName)

An AD CS privilege escalation (the original “ESC12” framing). If an attacker has GenericWrite over a computer object’s dNSHostName attribute, they can rename that computer object to match a Domain Controller’s dNSHostName, then request a machine certificate from AD CS as that “DC”. The CA, trusting the (now DC-named) computer, issues a cert that authenticates as a Domain Controller — granting DCSync and Tier-0 access.

The chain (per ad-cs-esc-attacks ESC12)

1. GenericWrite on a controlled computer object’s dNSHostName (acl-abuse).
2. Rename it to a real DC’s name: Set-DomainObject -Identity <computer> -Set @{'dNSHostName'='dc01.domain.com'}.
3. Request a Machine cert from AD CS as that “DC”: certipy req -u '<computer>$' -hashes <nt> -ca CA -template Machine -dc-ip <dc>.
4. Authenticate with the DC cert → you’re a DC → dcsync / domain dominance.

Status / notes

• Most environments now patch this specific path (the CA validates the dNSHostName against the object / requires the computer to actually be a DC). The other ESC12 case — a CA whose private key material is exposed (HSM/registry) on a host you can reach — remains the more durable ESC12. See ad-cs-esc-attacks for the current framing.
• Still a good BloodHound / certipy find target on unpatched AD CS.

Detection / mitigation

• 5136 — a dNSHostName change on a computer object (the rename tell).
• AD CS — a machine cert issued to an account whose dNSHostName matches a DC.
• Patch + validate the requesting computer is actually a DC.
• Restrict dNSHostName write (acl-abuse).

Links

• ad-cs-esc-attacks — the ESC12 entry this CVE underpins
• esc8-ntlm-relay-adcs — the related AD CS → DCSync chain (ESC8)
• dcsync — the privilege a DC cert unlocks
• acl-abuse — the GenericWrite-on-computer prerequisite
• certipy — the tooling that requests the cert
• ad-persistence — DSRM / the DC local-SAM context

References

• Microsoft: CVE-2022-26923
• SpecterOps / ired.team: ESC12
• ad-cs-esc-attacks (this wiki)