Certighost and the privilege hidden in your certificate authority

Author: Len Noe, Solutions Architect, BeyondTrust

Every mature Active Directory environment has a component that quietly has more power than the people who run it usually admit: the Certification Authority (CA). What your entire estate is willing to believe.

When a certificate is signed, every downstream computer, service, and authentication flow treats that signature as truth. That’s a tremendous amount of trust concentrated in one system, and most companies manage it like a utility that’s installed once and never considered again.

Certighostpursued as CVE-2026-54121is a reminder of what happens when that trust is misplaced. Researchers released a working proof of concept on July 24, 2026, showing that a low-privilege Active Directory user (who has nothing more than a standard domain account) can force a corporate certification authority to issue a valid authentication certificate to a domain controller, and then use that certificate to become the domain controller.

Microsoft shipped the fix on July 14, 2026 and rated it 8.8 on the CVSS scale.

What Certighost actually does

Active Directory Certificate Services is Microsoft’s public key infrastructure that issues and manages the certificates that underlie smart card login, device and user authentication, and VPN access. A standard domain user has no right to obtain a certificate that represents a domain controller, but Certighost breaks this barrier without touching a single access control list.

The flaw is an AD CS registry behavior known as “tracking.” If an enterprise CA cannot immediately resolve the target object locally, it can follow the routing information provided by the requestor (a parameter called cdc) to locate the object elsewhere.

The error is that the CA never checks whether the endpoint named in cdc is a legitimate domain controller before contacting it. An attacker points cdc at a computer under their control, and the CA dutifully establishes an outbound connection to this rogue endpoint, which responds with spoofed identity credentials, including the target domain controller’s object security identifier and DNS hostname.

The CA trusts the information, binds that identity to a signed X.509 certificate, and gives the attacker a certificate stating that they are a domain controller.

From then on the attack follows a well-known path. The attacker uses the certificate with PKINIT, the Kerberos public key extension, to obtain a ticket granting ticket as the domain controller’s machine account.

Domain controller accounts inherently have directory replication rights, sufficient to perform a DCSync operation on a real domain controller and retrieve credential material, down to the krbtgt account hash. Once you have krbtgt, you can spoof Kerberos tickets at will and the domain is functionally yours.

A standard domain user account was sufficient in testing because the default Active Directory settings, including the default MachineAccountQuota that allows regular users to create machine accounts, provided everything the chain needed.

At the time of publication there was no confirmed exploitation in the wild. That’s no reason to relax. A working, public proof-of-concept negates the effort required to reproduce this, and the gap between “PoC exists” and “commodity tooling encompasses it” is measured in weeks, not years.

This is not a certificate error. It is a failure of privilege and trust.

It’s tempting to submit Certighost under PKI Arcana, assign it to the CA owner, and move on as soon as the patch is available.

Remove the certificate machinery and consider the form of the attack: an unprivileged identity manipulated a trusted system to vouch for a privileged identity, and the environment had no mechanism to challenge the result. This is a trust validation problem that lies at the core of identity security.

The certificate authority is not a passive appliance. It is a standalone privileged identity that creates trust on behalf of the entire domain. The patch provided by Microsoft is, at its core, a verification step that ensures that the target of a search query is actually a domain controller.

This is the recurring characteristic of an identity-driven compromise: the attacker rarely breaks cryptography or authentication. You find the place where the system has decided to trust without checking it.

There is a second, more unpleasant lesson hidden in the premises. Active Directory’s default configuration grants every authenticated user a small privilege: the ability to create machine accounts, Courtesy of a MachineAccountQuota which allows this by default.

Certighost is one of many attack chains that are silently based on this capability. The specific CVE is new, but the latent privilege on which it was based has been in your domain for years.

The weak point represented a shortcut, but the terrain was already dangerous.

A determined attacker who gets a single foothold with low privileges has a realistic path to domain dominance because privileges have accumulated in places that no one actively controls: overly broad permissions on certificate templates, permissive machine account defaults, shallow trust between the CA and the domain, and monitoring that monitors endpoints but not the identity control layer.

Certighost is a clear demonstration of how these conditions are getting worse. Remove the CVE and the underlying exposure remains, awaiting the next technique.

What you can actually do about it

Patch first. Apply the Microsoft July 14, 2026 Update with each issuing CA as it introduces target validation that stops specific tracking abuse.

If deployment is delayed, researchers have documented a workaround that disables the vulnerable tracking feature. But test before deploying: This path is designed to support legitimate registration workflows, and disabling it may break them.

Beyond immediate resolution, reduce the persistent privileges that underpinned the attack. Setting the domain’s MachineAccountQuota to zero removes the default ability for regular users to create machine accounts, significantly reducing the attack surface for this class of technology.

This change is not free. Some provisioning workflows and older tools assume that users can add machines to the domain. Therefore, you should inventory these dependencies and direct machine creation through controlled, delegated accounts rather than making it accessible to everyone.

Then restrict the CA itself. Restrict outbound SMB and LDAP connections from your CAs so that they can only communicate with known, authorized domain controllers, which directly undermines the rogue endpoint step in the chain.

Review enterprise certification authority deployments, certificate templates, and enrollment permissions: which principals can request this, and is there an organization in this group that has the identity that this certificate represents?

In most environments, certificate registration privileges have never been checked against this standard, and this is exactly what is happening AD CS attack Paths emerge.

Finally, Make sure you have the right level. Monitor for anomalous machine account creation, unusual certificate enrollment activity, DCSync operations, and pay attention to CA enrollment events rather than assuming that endpoint telemetry is detecting an identity attack it was never intended to detect.

DCSync from anything other than a domain controller deserves an immediate response, and if your detection stack can’t detect this, that’s a gap worth closing.

The real snack

Certighost will be patched, cataloged and largely forgotten within a quarter. That’s the trap. If the response stops at the KB number, the organization will not learn anything permanent because the specific error was never the point. The point is that trust in a company is a thing you design and continually validate, not a trait you configure once and inherit forever.

The acceptable stance is not a lengthy patch list. It’s a mindset that views identity as infrastructure and privilege as a risk to be minimized rather than a convenience to be preserved. Reduce standing privilege Wherever it hides, including the default settings you never chose, and validate trust at every point a system will respond, not just at the front door.

Your certification authority has been issuing trusted identities on your behalf since it was established. The work is to ensure that this only happens for identities that you can actually verify.

Find out how BeyondTrust’s free identity security risk assessment helps you uncover hidden identity and privilege risks in your own environment.

About the author

Len Noe is a solutions architect at BeyondTrust, transhuman, podcaster, international cybersecurity speaker, author, tech evangelist, and biohacker with 13 implanted microchips.

A former blackhat with more than 30 years of experience in technology, he has spoken in over 70 countries and is featured in the documentary I Am Machine, which premiered at DEF CON 2025.

BeyondTrust is the global leader in privileged identity security protecting Paths to Privilege™. Identity alone does not create risk. Privilege does. As human, machine and AI agent identities explode across all environments, BeyondTrust is the only company designed to discover, control and secure the privileges of all identities from a single platform. BeyondTrust is trusted by more than 20,000 customers, including 75 of the Fortune 100, and is recognized by top industry analysts as a leader in multiple categories. BeyondTrust transforms identity security from a management problem into a strategic advantage.

Find out more at www.beyondtrust.com.

Sponsored and written by BeyondTrust.