Domain Admin Before Lunch
Forty minutes into an assumed breach engagement, and we were Domain Admin.
No zero day. No exploit chain that required weeks of research. No phishing pretext, no lateral movement puzzle, no waiting around for a low priv foothold to turn into something useful. The whole point of an assumed breach engagement is that you start where a real attacker would end up after an initial compromise, sitting on the network with a standard domain user account and nothing else. From that starting point, forty minutes was all it took to walk out with domain controller level access. No credential dumping, no lateral movement across a dozen hosts. Just one badly configured certificate template.
That's it. That's the whole story, and we will walk you through exactly how it happened further down. Fun fact, it happens often.
ADCS misconfigurations have been public knowledge since 2021. Every red teamer, every SOC analyst who's read a conference talk, every vendor selling AD hardening services knows the acronyms: ESC1 through ESC16 at this point, if you're keeping score. And yet here we are, five years later, and we are still getting Domain Admin Privileges in under an hour because someone left a certificate template writable by Domain Users.
Why This Should Be a Solved Problem
On paper, ADCS abuse should be dead. The research that put it on the map is old news by security industry standards. Microsoft has shipped hardening updates. Strong certificate mapping enforcement rolled out and became mandatory. Every major AD security tool, BloodHound included, has had certificate template abuse baked into its attack path graphs for years. If you search "ESC1" you get more blog posts, cheat sheets, and conference recordings than almost any other AD attack technique.
Compare that to something like a kernel exploit or a novel injection technique. Those require ongoing research to stay current because vendors patch the underlying bug and the technique stops working. ADCS abuse isn't like that. There is no single vulnerability to patch. The "vulnerability" is a permission set, a template flag, an EKU that someone configured wrong when the CA was stood up three or five or eight years ago, and never touched again.
That's the part that makes it so persistent, and it's also the part most write ups gloss over in favor of the technical exploitation steps. The real story isn't the chain, it's the fact that PKI in Active Directory environments is treated as infrastructure you install once and never revisit.
Why It Keeps Coming Back in 2026
A few reasons, based on what we keep seeing across engagements.
Nobody owns the CA. Identity teams own the domain. Endpoint teams own EDR. Nobody owns the certificate authority. It usually got deployed by whoever set up the domain a decade ago, for a specific project like WiFi authentication or VPN certs, and then it just sat there. Templates get cloned from defaults, permissions get inherited, and nobody audits it again because it's not on anyone's checklist.
The barrier to exploitation dropped faster than the barrier to detection. Certipy turned what used to require manual LDAP queries and a solid understanding of certificate extensions into a couple of commands. Run Certipy, review the output, spot the vulnerable template and then exploit it. The tooling matured. Detection didn't keep pace at the same speed, because most organizations still monitor for known-bad template configurations rather than for the permission changes and enrollment events that actually indicate abuse in progress.
Patch fatigue targets the wrong thing. Security teams patch CVEs. ADCS abuse mostly isn't a CVE, it's a misconfiguration, so it never lands on a patch Tuesday list and never triggers the same urgency. Teams that are otherwise diligent about patching will walk right past a certificate template that's been silently exploitable since it was created.
Certificate based auth is expanding, not shrinking. The push toward passwordless authentication and smart card alternatives means more organizations are standing up or expanding their CAs right now, in 2026, often without anyone on the project having deep PKI security background. Every new template is a new opportunity to misconfigure something.
Templates outlive the people who understood them. The people who built the enrollment workflow for a specific application five years ago has moved on. Nobody currently at the company can explain why a given template allows enrollee supplied subject names, only that removing it might break something, so it stays.
Exploitation walkthrough
Without getting into any client specifics, for obvious reasons, here's what actually happened on that assumed breach engagement, using it as an example since ESC4 into ESC1 is one of the more common chains we run into.
ESC4 starts with permissions, not certificate settings. It means a low privileged account, sometimes as broad as Domain Users or Authenticated Users, has dangerous write access to a certificate template object. That could be WriteOwner, WriteDacl, WriteProperty, or full GenericWrite. On its own, that access doesn't get you anything, since the template might be configured safely.
The interesting part happens when you use that write access to reconfigure the template into something exploitable, most commonly into an ESC1 shaped template. That means enabling client authentication as an allowed extended key usage, and enabling enrollee supplied subject names, which lets whoever requests a certificate specify any user principal name they want, including a domain admin's or a domain controller's. Remember to always backup the original template so you can restore it when you are done.
From there it's a straightforward request. Enroll for a certificate against the now vulnerable template, specify the target identity in the subject, and use the resulting certificate to authenticate via Kerberos PKINIT. If the target identity is privileged, so are you.
The technical steps are well documented at this point and tools like Certipy handle most of the heavy lifting. The actual skill in these engagements isn't the exploitation, it's the enumeration. Finding the one template out of dozens that has the permission issue, understanding what changing it will actually do, and confirming the resulting certificate maps to something useful.
Worth pausing on what that certificate actually buys you once you have it. Default certificate lifetime on most templates is one year. That means a single successful ESC1 style request doesn't just get you in the door, it hands you a credential that's valid for authentication for the next twelve months, independent of password resets, independent of most conditional access policies, and often independent of anything an incident responder would think to check. Rotating a compromised user's password does nothing to it. The certificate keeps working. Identifying that a specific certificate was issued fraudulently and needs to be revoked requires someone to go looking through CA issuance logs for exactly this, which most environments simply aren't set up to do. In practice that one year default turns a forty minute foothold into a year long persistence mechanism unless someone catches it, and catching it is a lot harder than catching a compromised password.
ESC4 into ESC1 isn't the only quick win in this space either, it's just the one that happened to be sitting there on this engagement. ESC8 is arguably even more common in the wild, and doesn't require a misconfigured template at all. It targets CA web enrollment over HTTP, and lets an attacker coerce a machine account, often a domain controller, into authenticating to a relay listener, then relay that authentication straight into a certificate request for that machine's identity. No template permissions to abuse, no ACL to modify, just an enrollment endpoint that was never restricted to HTTPS and a network position to relay from. Between ESC4, ESC1, and ESC8 alone, most ADCS deployments have at least one of these sitting exposed, which is a big part of why this keeps showing up across engagements rather than being a one off.
Why Detection Lags Behind
Most detection strategies for ADCS abuse focus on the wrong layer. Security teams that have invested in this area typically monitor for templates that are already in a known bad state, meaning they check configuration against a static list of dangerous flags. That catches misconfigurations that existed at the time of the last audit. It does nothing for a template that gets modified during an actual attack, or by a pentester, an hour before the check runs again.
What's usually missing is event level monitoring on the CA itself. Certificate template modification, especially changes to EKU settings or the enrollee supplied subject flag, should be a high signal event, on par with a change to a Domain Admins group membership. In most environments it isn't logged anywhere anyone is watching. Certificate issuance events for high privilege identities are similarly under monitored. A domain controller or domain admin certificate getting issued outside of expected provisioning windows is a strong indicator, but most SOCs don't have that on a dashboard because ADCS just isn't treated as Tier 0 infrastructure the way domain controllers and admin workstations are.
Takeaways for Defenders
A few things that would have stopped every ADCS finding we have had in the past years, none of which require buying anything new:
- Run a permissions audit against every certificate template and the CA objects themselves, not just a check for known vulnerable flag combinations. Tools like Certipy and PSPKIAudit can be pointed at your own environment just as easily as an attacker points them at yours.
- Treat the CA as Tier 0. It should sit in the same governance bucket as domain controllers, with the same access restrictions and the same change monitoring, not as a forgotten appliance that IT stood up once for VPN certs.
- Alert on template and CA object modification events specifically. This is a narrow, high value signal that most environments aren't capturing at all.
- Remove enrollee supplied subject name wherever it isn't explicitly required, and review every template that allows client authentication as an EKU. Most organizations have far more of these than they expect, often inherited from cloned defaults nobody revisited.
- Do this review on a recurring schedule, not as a one time project. The whole reason this class of attack keeps showing up in 2026 is that PKI gets configured once and never looked at again. Attackers don't have that problem. They check every time.