Certighost and the PKI Blind Spot: Hardening AD CS in Your Servers

Why the certificate authority became the quietest way into your networkFor years, Active Directory Certificate Services sat in the corner of most Wind...

Why the certificate authority became the quietest way into your network

For years, Active Directory Certificate Services sat in the corner of most Windows estates: installed once, documented badly, and rarely touched again. Attackers noticed before defenders did. A misconfigured PKI does not just leak a password or a hash — it can mint a durable, cryptographically valid identity that survives password resets and slips past controls built around credentials. The latest reminder is Certighost, tracked as CVE-2026-54121, an elevation-of-privilege flaw in AD CS that Microsoft rates highly and for which public proof-of-concept code is already circulating.

The detail that matters is not the score. It is the destination. Most AD CS abuse ends with a certificate for a privileged user. Certighost goes further: it can yield a certificate that represents the Domain Controller itself.

What the flaw actually allows

According to Microsoft, an authenticated user can elevate privileges over the network because of an authorisation weakness. In practice, the published exploit chains several familiar pieces together:

An attacker creates or reuses a machine account in the domain.
They stand up unauthorised listeners that impersonate the services a CA expects to talk to during enrolment.
They submit a certificate request carrying crafted attributes that point the CA at those listeners.
The CA validates the request against the real domain controller, then trusts the answers coming back from the attacker.
A certificate is issued that belongs to the targeted Domain Controller, which can then be used for certificate-based authentication.

Anyone who has worked with PKINIT understands the consequence: a machine identity for a DC is not merely "Domain Admin with extra steps". It is an identity that participates directly in authentication mechanisms across the forest, and it is far harder to spot than a suspicious logon from a workstation.

Patching is necessary, not sufficient

Microsoft has shipped updates for affected systems, and applying them promptly should be the first action on any administrator's list. But treating the patch as the finish line repeats the mistake that created the problem. The underlying risk is organisational: PKIs that have run untouched since installation, templates nobody has reviewed, and enrolment permissions granted broadly because it was convenient at the time.

A serious review should cover, at minimum:

A complete inventory of every Enterprise CA in the forest, including forgotten subordinates.
A line-by-line audit of certificate templates, especially those permitting client authentication or enrollee-supplied subject information.
Enrolment and auto-enrolment permissions, tightened to the smallest set of principals that genuinely need them.
A map of which identities can authenticate using certificates, and where that path leads.
Audit logging of certificate requests and issuance, retained long enough to investigate incidents under GDPR obligations.
Legacy settings inherited from old migrations that no one has dared to remove.

Where Abuse Shield fits

Certificate abuse rarely happens in isolation. Before an attacker can request anything from a CA, they usually need a foothold, a machine account, and network reachability — and the same infrastructure that hosts your CA is exposed to brute-force attempts, credential stuffing and scanning every day. This is where centralised protection earns its place.

Abuse Shield consolidates server protection across your estate: automatic blocking of malicious IPs, managed fail2ban across multiple machines, and a shared IP reputation feed that means a host blocked on one server is recognised on all of them. For system administrators, hosting providers and SMEs running their own servers in Barcelona, Lleida, Tarragona or Girona, that shared intelligence closes the gap between machines that are otherwise defended one by one.

Pair that with disciplined PKI hygiene and the picture changes. The noisy, opportunistic traffic that precedes most intrusions gets filtered at the edge, while the certificate authority stops being an unmonitored shortcut to the domain.

A practical sequence for the coming weeks

Start with exposure: confirm which CAs are reachable from segments that should never talk to them. Then apply the vendor updates and verify they landed. Move on to templates and enrolment rights, removing anything that allows a low-privileged principal to obtain an identity it does not need. Finally, instrument the environment — request logs, authentication events, and network-level blocks — so that the next anomaly is visible rather than inferred after the fact.

Certighost will not be the last PKI flaw, and the organisations that cope best will be those that treat certificate services as critical infrastructure rather than a leftover from a migration. The patch closes one door. The audit and the monitoring keep the rest shut.

Put these ideas into practice

Talk to ALMC about a solution for your business. Explore your options or contact our team.

Results without leaving the page.