Most security teams assume that becoming a domain controller requires either stolen admin credentials or a serious piece of exploit engineering. That assumption just took a hit. Researchers H0j3n and Aniq Fakhrul published a working technique on July 24 called Certighost that lets a standard, low-privileged Active Directory user request a certificate, authenticate as a domain controller, and then pull the keys to the entire domain. No memory corruption. No fuzzing. No zero-day in the traditional sense. Just a certificate request that the environment was already configured to honor. It’s the kind of finding that should reshape how cybersecurity teams think about what “privileged” actually means inside their own directory.

The Trick That Requires No Exploit Code At All

Here’s the uncomfortable part. Certighost doesn’t break cryptography or bypass a patch. It abuses a workflow that Active Directory Certificate Services was designed to support: a user requests a certificate, a template grants it, and the resulting cert becomes a valid credential. In misconfigured environments, that template lets a regular account obtain a certificate that maps to a domain controller’s machine account. Once that certificate exists, the attacker authenticates as the DC itself over Kerberos. Domain controllers carry directory replication permissions by default, which means that credential can invoke DCSync and pull the krbtgt hash. At that point, the attacker isn’t impersonating a domain controller anymore. They can forge Kerberos tickets for anyone in the forest, indefinitely, until someone rotates krbtgt twice and actually means it.

What makes this dangerous isn’t sophistication, it’s reach. Certificate templates like this exist in a huge number of enterprise AD deployments because nobody audits them after initial deployment. They get set up once, usually by whoever stood up the PKI five or six years ago, and then nobody touches them again until a researcher publishes a name for the problem.

Cybersecurity Teams Still Treat Certificate Services As an Afterthought

This isn’t the first time AD CS misconfigurations have handed out domain dominance. The “Certified Pre-Owned” research years ago catalogued a whole family of these paths, commonly labeled ESC1 through ESC8, and tooling to find and abuse them has been public for a long time. Certighost is a new variant in that same lineage, not an isolated bug. The pattern keeps repeating because certificate services sit in an odd blind spot: they’re not covered by typical vulnerability scanning, they’re rarely included in tabletop incident response exercises, and they don’t show up on the dashboards most SOCs actually watch. Firewall rules and network segmentation don’t help here either, since the entire attack happens over protocols that are supposed to be reachable from the internal network. This is a security hardening problem, not a threat detection problem, and treating it as the latter is how it keeps slipping past teams that otherwise consider themselves mature.

The Vatican’s Prayer App Shows the Same Blind Spot, Just Smaller

You don’t need enterprise PKI to make this mistake. This week also brought word that the Vatican’s official prayer app exposed personal data on more than 700,000 users through a porous API endpoint, names, email addresses, country, and account status, all retrievable by anyone with a browser and no special access. There was no impersonation trick required, no certificate abuse, just an endpoint that never checked whether the requester should be allowed to see that data.

Put these two stories side by side and the throughline is obvious. Both failures come from systems that were built to trust a request by default and verify almost nothing. A certificate template that hands out DC-equivalent trust to any domain user and an API that hands out user records to any browser are the same failure mode wearing different clothes. Scale and stakes differ wildly, one is a religious app leak and the other is a path to full domain compromise, but the root cause is identical: nobody asked “who should actually be allowed to do this” before shipping.

What Actually Closes These Gaps

None of this requires exotic defenses. It requires someone to go looking, on a schedule, rather than waiting for a researcher to name the problem for you.

Auditing Your Certificate Templates

If you run AD CS, this is not optional homework anymore. Pull every certificate template that’s enabled for autoenrollment or that allows the requester to supply a subject alternative name, and check who can enroll in it. Anything that lets a low-privileged group obtain a certificate usable for client authentication on a sensitive account needs to be locked down or removed. This is a known, well-documented category of misconfiguration, and free tooling exists to enumerate it.

1. Inventory every certificate template in your PKI and identify who has enrollment rights on each one, not just who you think has enrollment rights.
2. Remove or restrict any template that permits enrollee-supplied subject names combined with client authentication EKUs.
3. Enable enhanced auditing on your certificate authorities so certificate issuance events actually generate logs your incident response team reviews, not just logs that exist.
4. Rotate the krbtgt account twice, with the required replication interval between rotations, if you have any reason to believe this template exposure existed in your environment.
5. Extend brute-force and threat-protection controls to your PKI management interfaces and any exposed enrollment endpoints. A tool like IPBan Pro can throttle repeated authentication attempts against these systems the same way it does for RDP or web logins, closing off one more path attackers use to probe for weak templates.
6. For anything internet-facing, whether it’s a PKI enrollment portal or a public API like the one that burned the Vatican’s app, require authentication and authorization checks on every endpoint by default, not as an exception you add after a leak.

None of this is glamorous. It’s the unsexy maintenance work that cybersecurity programs tend to defer in favor of chasing the newest CVE with a catchy name. But defense in depth only works if every layer, including the one you inherited from whoever configured your PKI in 2019, gets checked on a recurring basis rather than assumed to be fine.

The Real Lesson Here Isn’t About Certificates

It’s about default trust. Every system in your environment was configured by someone, at some point, who made a call about who gets to ask for what. Those calls age badly. Templates get copied forward during migrations. API endpoints get built quickly and never revisited. Access that made sense for a ten-person pilot never gets revoked when the pilot becomes production infrastructure serving hundreds of thousands of users. Certighost and the Vatican leak aren’t really stories about a certificate exploit and an app bug. They’re both stories about audits nobody ran.

Frequently Asked Questions

Is Certighost a patchable vulnerability?

Not in the traditional sense. It abuses legitimate certificate enrollment functionality rather than a software flaw, so there’s no single patch to install. The fix is auditing and restricting certificate templates in your own environment.

How would I know if this technique had already been used against my domain?

Check certificate authority logs for unexpected enrollment requests tied to accounts that shouldn’t have client authentication certificates, and review DCSync-capable replication activity for anomalies. If your CA auditing wasn’t enabled beforehand, this is much harder to reconstruct after the fact, which is itself a reason to enable it now.

Does this only affect large enterprises with complex PKI deployments?

No. Any organization running Active Directory Certificate Services with autoenrollment templates is potentially exposed, regardless of size. Smaller IT teams are often more exposed because they’re less likely to have revisited PKI configuration since initial setup.

Sources

• Certighost Exploit Lets Low-Privileged Active Directory Users Impersonate a Domain Controller
• Vatican’s Official Prayer App Leaks 700K+ Global Users’ PII