Microsoft RAMP stops at the edge of your certificate authority

Microsoft patched CVE-2026-54121 on July 14. Researchers H0j3n and Aniq Fakhrul published a working proof of concept 10 days later and named it Certighost. If your AD CS servers took the July cumulative update, you're protected. If they're still on June builds, you're exposed to public exploit code.

The attack itself is short. A standard domain user with no administrator rights manipulates attributes on a machine account they control, triggers flawed fallback logic inside the certificate authority, and receives a signed certificate that authenticates as a domain controller over PKINIT. From there, DCSync yields the krbtgt hash and the ability to forge Golden Tickets across the forest. It needs an Enterprise CA integrated with Active Directory and the ability to create or control a computer account, which the default machine account quota of 10 grants to every domain user.

The account that started the chain never held elevated privileges at any point in it. That's the detail that matters here, because Microsoft's roadmap for privileged access is built around a threat model this attack sidesteps.

RAMP's three initiative groups

The Rapid Modernization Plan tells you to separate and manage privileged accounts, improve the credential experience for the people who hold them, and deploy admin workstations. Underneath those sit the specifics most security teams are working through right now: Privileged Identity Management (PIM), emergency access accounts, categorizing Microsoft Entra roles by impact, MFA and passwordless for admins, blocking legacy authentication, and Privileged Access Workstations.

Most of that is Microsoft Entra ID work. What RAMP asks for on premises comes down to separate admin accounts, dedicated workstations for the people who use them, and unique local administrator passwords. Certighost is a defect in AD CS. None of those three touch it.

RAMP contains no certificate authority initiative. Microsoft scoped it that way deliberately, and the guidance says so, building on a separate privileged access deployment document. RAMP answers who holds elevated access in your environment. How your CA decides what identity to bind to a certificate is a different question.

Certighost won't be the last one

Certificate issuance integrity is a category, and it keeps producing. Most of the known paths are the ESC attack techniques documented since "Certified Pre-Owned," where a template or a CA flag lets a user with no privileges request a certificate for an identity they don't own. Certighost is a different shape. The template configuration is irrelevant. The defect is in the certificate authority's own request-handling logic, in how it resolved which directory object the request was really asking about.

That distinction matters for what you do about it. A certificate template audit, which is the standard advice, would not have found this one.

What customers get wrong about this

Most customers treat AD CS as covered because somebody owns it. The certificate authority sits with a PKI or infrastructure team, the identity team assumes that means it's handled, and a different reporting line gets read as a control. When I ask whether they've audited their configurations against any of the ESC paths, the answer is usually that they weren't aware of them.

The teams that do own it are measured on availability. Issuance succeeds, renewals don't lapse, authentication doesn't break, the CA is healthy by every metric they're accountable for. It stays healthy by all of them when a standard user enrolls a certificate for an account they have no claim to, which is exactly why nobody catches it.

Governance has nothing to attach to

RAMP's controls activate around a privileged account. Certighost never touches one until the CA itself issues the certificate that creates it.

There's no intermediate account for PIM to gate and no admin authentication for MFA to challenge. Escalation and payoff happen in a single transaction inside the certificate authority's request processing, and the adversary's starting account stays exactly where it started, in tier with every other standard domain user. The machine account quota that makes the staging step possible isn't a RAMP initiative either.

RAMP does point to Microsoft Defender for Identity (MDI), and MDI carries real certificate coverage. Posture assessments evaluate templates and CA settings for the known escalation paths, and the checks that look at the CA itself require an MDI sensor on the AD CS server. There's also a named detection for this technique that fires on the request pattern.

Both of those are worth having. Neither one denies the enrollment request. A posture assessment is a configuration report you read on a cadence, and a detection is an alert that arrives while the transaction completes.

So a security team can finish RAMP end to end, do it well, run MDI alongside it, and still have no control that evaluates a certificate request and refuses it. Privileged access governance and certificate authority integrity are separate problems. RAMP solves one of them, and I'd argue that treating a completed rollout as coverage for both is the most common misread of what that roadmap is for.

If someone tells me they've finished their RAMP work, my first question is who owns the certificate authority. If they have to go find out, that's the answer. RAMP is the right roadmap and finishing it means their privileged accounts are governed, which is real progress and not nothing. It just says nothing about the system that can mint one of those accounts out of a standard user's certificate request. Monitoring that system is the floor. What I'd want next is something that can refuse the request.

Blocking the enrollment request

Netwrix Threat Prevention (NTP) and Netwrix Threat Manager (NTM) work on both sides of this. On the monitoring side, NTM covers the same ground RAMP points at through Defender for Identity, surfacing AD CS misuse and certificate abuse patterns as they happen.

The prevention side is what separates them. NTP evaluates enrollment requests against known AD CS abuse patterns, including the ESC1 to ESC7 techniques, and blocks them before a certificate exists rather than generating a record that one was issued. A posture assessment tells you a template is wrong and a detection tells you a request looked wrong, but enforcement is the only one of the three that ends the transaction.

Do RAMP, then go look at your certificate authority

Follow RAMP. The work it asks for is work worth doing. Patch your AD CS servers, and set the machine account quota to zero while you're in there.

Then go look at your certificate authority, because RAMP isn't going to send you there. Audit the templates, and then ask the harder question underneath them: when a standard account submits an enrollment request asserting an identity it has no claim to, what in your environment evaluates that request, and does anything stop it or just write it down?