For the past decade, if you were worried about Active Directory authentication, you were concerned with Kerberos and NTLM hashes. That’s where the attacks lived, and that’s what got hardened.
But there’s a second authentication system running inside most Active Directory environments, and it’s becoming one of the fastest ways for an attacker to advance from a low-level foothold to full domain admin: Active Directory Certificate Services, or ADCS.
In a recent penetration test, our team used an ADCS misconfiguration to take over an Ivy League school’s entire domain in just 12 minutes.
The environment had monthly vulnerability scans, a tightened-down EDR solution, and SMB/LDAP signing enabled across the board. None of that mattered because none of those tools were built to look at ADCS.
Here’s what ADCS is, why it’s a problem you need to be paying close attention to, and exactly what you can do about it.
What Is Active Directory Certificate Services, in Plain Terms
Kerberos is the default way Active Directory Certificate Services handles logins and sessions. It relies on hashes (NTLM hashes specifically) to verify who you are.
ADCS is a separate system that issues digital certificates for authentication. Instead of a hash, you present a certificate, and Active Directory trusts it the same way it trusts a Kerberos ticket. Many organizations use ADCS without realizing how central it’s become, since certificates are often used for things like VPN access, smart card logins, internal web services, and machine authentication.
Active Directory Certificate Services isn’t inherently problematic. Instead, the issue lies in how certificate templates get configured, and how those configurations can create a situation where an attacker requests a certificate that says “I’m the Administrator” and Active Directory believes it.
Why This Is Showing Up Now
The misconfigurations that make ADCS exploitable aren’t new. Many of the vulnerable templates we find during pen tests have been sitting in the environment for 8 to 10 years, often created when someone duplicated a default template to support some application and didn’t realize what they’d opened up.
Security researchers only started mapping out how these misconfigurations can be exploited in 2021.
Once the first technique (now called ESC1) was published, more rapidly followed. As of 2026, there are 16 documented escalation paths, numbered ESC1 through ESC16, and that list is still growing.
View all documented escalation paths here.
This timing matters. A misconfigured template that’s been harmless for a decade can become a same-day domain compromise the moment someone publishes the technique to exploit it. As in all things security, the threat landscape has an unfortunate habit of shifting at the speed of light.
The bad guys picked this one up fast, including state-sponsored or affiliated groups, because the payoff is enormous: a single misconfigured certificate template can be worth more than weeks of phishing and meticulous lateral movement.
Why Your Existing Tools Probably Aren’t Catching It
This is the part that surprises people. ADCS misconfigurations generally don’t show up as CVEs. There’s no patch because nothing is technically broken. A setting is just configured in a way that’s now known to be exploitable.
That means your standard, household-name vulnerability scanners, which are built to match against known CVEs and missing patches, have nothing to flag. EDR tools are built to catch malware behavior and known attack patterns, not certificate template configurations sitting in Active Directory.
In the engagement that prompted this post, our automated pen testing platform ran through its full attack chain twice inside the client’s environment and it couldn’t find the path either.
The client’s EDR was tuned well enough to block our tools, so it took a human penetration tester looking for an ADCS sweet spot to find a way in.
How to Check Your Own Environment
The good news is that checking for ADCS misconfigurations is relatively simple. There are free, well-maintained tools built specifically for this.
Locksmith is a PowerShell tool that audits your Active Directory environment for ADCS misconfigurations. It’s popular enough that it’s now part of the PowerShell Gallery, so you can run it directly without downloading anything from GitHub.
Running it in audit mode will tell you which certificate templates are misconfigured, which specific ESC vulnerability applies, and in most cases, give you the exact command to fix it.
Certipy is the other side of the same coin. It’s the tool used to identify and exploit these Active Directory Certificate Services vulnerabilities from an attacker’s perspective, which makes it useful for understanding exactly what an attacker would see if they ran it against your environment.
Certipy’s documentation also maintains the most current breakdown of all known ESC vulnerability types (ESC1 through ESC16), with technical details on each.
As a starting point, run Locksmith first. It’s built for defenders, gives you a plain-language audit, and points directly at what needs to be addressed.
Closing the Gap
The fixes for most Active Directory Certificate Services misconfigurations are trivial.
The most common issue, ESC1, is typically resolved by changing a single setting: requiring manager approval before a certificate template can issue a certificate. That single change adds a human checkpoint that breaks the entire attack path.
A few practical steps:
Run an audit. Use Locksmith to find out if you have any ESC1-16 vulnerable templates. Organizations that haven’t looked specifically for this will very likely find at least one.
Fix templates one at a time, carefully. Changing a certificate template’s settings can affect whatever was relying on that template. If a service or application authenticates using a certificate from that template, test changes in a controlled way before rolling them out broadly.
Add Active Directory Certificate Services to your ongoing review process. This shouldn’t be a one-time check. As new ESC techniques continue to be published, templates that look fine today could become exploitable tomorrow. Build ADCS configuration review into the same cadence as your other checks.
Get a human to look at it. Automated scanners and EDR tools can be valuable, but as this engagement demonstrated, they’re not yet able to catch this specific category of issue.
The Bigger Picture
Configuring Kerberos and retiring NTLM still matters, but it’s not a complete authentication hardening strategy anymore.
ADCS is living inside your Active Directory environment, and for a lot of organizations, it’s never been examined in much detail. The techniques to exploit it are public, well-documented, and actively in use, and the fixes are low-lift if you find an exploitable cert.
As always, a lot of our focus in simulating threat actor behavior remains on what automated tools haven’t been designed to monitor.
Blue Team Alpha’s penetration testing engagements always include a human in the loop. Our offensive and incident response teams share intelligence, so the techniques we test for are the ones currently being used in real-world breaches.
Want to test your organization’s defenses? Schedule a Consultation