the ad certificate services misconfig nobody audits

the ad cs blind spot

every domain admin escalation path gets attention except this one. group policy, kerberoasting, lm hashes, all audited to death. then there's active directory certificate services sitting quietly in the corner with a misconfigured template that hands out domain admin to anyone who asks nicely. nobody looks at it because most admins don't even know ad cs is running, let alone that it has its own attack surface.

this post walks through what tools like certipy actually check for, so you can run the same checks against your own environment before someone else does.

what ad cs even is

ad cs is microsoft's built in public key infrastructure for windows domains. it issues certificates for things like smart card login, vpn auth, and machine authentication. certificates are configured through "templates" that define who can request one and what that certificate is allowed to do.

the problem is templates are often left with permissive defaults from years ago, or someone widened permissions to fix a one off issue and never locked it back down. a badly configured template can let a low privilege user request a certificate that authenticates as domain admin. that's the whole bug. it's not a windows vulnerability, it's a misconfiguration, which means it's 100% fixable and 100% your responsibility to check.

the enumeration step, broken down

certipy find -u user@corp.local -p pass -dc-ip x -vulnerable -stdout

run this against your own domain with a low privileged account, the same access level a phished employee or a compromised low tier service account would have. here's what each piece does:

-u user@corp.local -p pass authenticates as a normal domain user. this matters because the whole point is checking what a low privilege account can see and abuse, not what a domain admin can already do.

-dc-ip x points certipy at your domain controller.

-vulnerable tells certipy to specifically flag templates with dangerous configurations instead of dumping every template that exists. it checks things like whether enrollee supplied subject is enabled, whether authentication is an allowed use for that cert, and who has enrollment rights.

-stdout prints results straight to your terminal instead of writing a file, useful when you're just doing a quick audit pass.

what esc1 actually means

esc1 is the name for a specific bad combo of settings on a certificate template. the short version: the template allows client authentication, it lets the requester specify an arbitrary subject alternative name (basically "who this cert claims to be"), and enrollment rights are granted to a broad group like domain users. put those three together and any regular account can request a certificate that says "i am administrator@corp.local" and that cert will actually work for authentication.

this is why it's such a quiet path to domain admin. no exploit, no malware signature, no failed login attempts to trigger an alert. it looks like a completely normal certificate request because, technically, it is one.

how to actually check and fix this in your environment

open the certificate authority console or use certutil to review template permissions directly:

certutil -template

for each template, check three things. does it allow "enrollee supplies subject"? if yes and it's not absolutely required for a specific legitimate use case, disable it. what does the extended key usage list include, does it allow client authentication when it shouldn't? and who has enroll permission, is it scoped to a specific security group or is it wide open to domain users or authenticated users?

microsoft's fix guidance groups these issues under names like esc1 through esc8 depending on which setting is the problem, so once you find a flagged template you can look up the specific remediation for that esc number instead of guessing.

also lock down who can modify templates in the first place. if a regular user or a broad group has write access to the ad cs configuration container, someone could recreate a vulnerable template even after you fix the current ones. that permission should belong to a small, dedicated pki admin group only.

finally, enable certificate request logging on your ca so unusual requests, especially ones requesting alternate names or admin upns, actually show up somewhere you'll see them.

the takeaway

ad cs misconfigs are dangerous specifically because they're boring. nobody schedules an audit for something they forgot was installed. run the enumeration against your own domain as a low privilege test account, treat every flagged template as a findable ticket, and fix the permission model instead of just the symptom. the attacker's advantage here is that it's unmonitored, so monitoring it is the whole defense.