CertiGhost: How to Determine Whether Your Enterprise CA Was Exploited

A note on sourcing: this guide is based on public security research and reporting on CVE-2026-54121 (“Certighost”), disclosed by researchers Muhammad Ali (H0j3n) and Aniq Fakhrul in July 2026, and on Microsoft’s own patch released July 14, 2026. We’ve cited what’s publicly confirmed and avoided speculation beyond it. Verify current details against Microsoft’s official advisory and the researchers’ published technical write-up directly, and treat this as a starting incident-response framework, not a final or exhaustive word, we’ll update this guide as further disclosure and analysis develops.

TL;DR: Key Takeaways

Certighost lets a low-privileged domain user obtain a certificate bearing a domain controller’s identity: no administrative rights are required, only a standard domain account and network access, per the public research.
Template hardening alone does not protect against this: unlike ESC1-style attacks, Certighost exploits a validation gap in AD CS’s default enrollment behavior itself, organizations that had already hardened their certificate templates were not necessarily protected.
Patch first, investigate in parallel: Microsoft’s July 14, 2026 security update addresses the underlying flaw, apply it immediately if you haven’t, patching stops future exploitation but doesn’t tell you whether you were exploited before patching.
The core detection question is a Requester-versus-identity mismatch: a certificate issued against the Machine template where the requesting account isn’t the domain controller whose identity the resulting certificate represents is the central signal to hunt for.
If domain controller impersonation is confirmed, this is a full domain compromise, not a certificate incident: the exposure includes DCSync and krbtgt secret extraction, and recovery needs to be scoped accordingly, not treated as a simple certificate revocation.

What Certighost Actually Does

Tracked as CVE-2026-54121, CVSS 8.8, improper authorization: the vulnerability lives in a certificate enrollment fallback mechanism in AD CS referred to as a “chase,” used during directory-object resolution.
The core issue, per the public research: in vulnerable deployments, the CA trusted a requester-specified value pointing to a domain controller without adequately verifying the referenced server was an authentic one, allowing an attacker-controlled host to be substituted in its place during that resolution process.
What this enables: a certificate that appears to represent a legitimate domain controller’s identity can end up issued to a request that actually originated from an attacker-controlled machine, and that certificate can subsequently be used for certificate-based (PKINIT) Kerberos authentication as that domain controller.
Why the downstream impact is severe: a domain controller identity carries directory replication rights. Successfully authenticating as one opens the door to DCSync-style extraction of the krbtgt secret, the foundation of a full domain compromise, not a limited or contained incident.
Why this bypasses your existing template hardening: this is explicitly documented as distinct from the well-known ESC-series template misconfiguration patterns, it doesn’t depend on overly permissive enrollment permissions or a poorly configured template, it exploits code that ships as default AD CS behavior. A clean ESC1-16 audit result does not mean protection from this specific issue.

Step One: Patch First, Investigate in Parallel

Apply Microsoft’s July 14, 2026 security update without delay if you haven’t already, multiple public advisories treat this as an urgent patching priority given the low bar for exploitation (a standard domain account, no special privileges) and the severity of the outcome.
Understand that patching addresses future risk, not past exposure, if your CA was vulnerable for any period before you applied the fix, patching alone doesn’t tell you whether exploitation actually occurred during that window, that requires the investigation covered below.
Don’t let investigation delay patching, and don’t let patching substitute for investigation, run both in parallel rather than treating them as sequential steps.

Indicators to Look For

Unexpected or unrecognized computer accounts created recently: per the public research, the attack path commonly relies on the default ms-DS-MachineAccountQuota setting, which allows any authenticated domain user to register up to ten computer accounts, review recently created computer accounts for ones that don’t correspond to a legitimate device provisioning process.
Unexpected LDAP or SMB/LSA listener activity on non-domain-controller, non-CA hosts: a regular workstation or member server binding to ports associated with directory or authentication services is unusual and worth investigating regardless of this specific vulnerability.
Relevant network connection events on unexpected hosts, correlate against your standard network connection and listening-port telemetry for activity consistent with the pattern above, on hosts that have no legitimate reason to be running these services.
Certificate requests against the default Machine certificate template with unusual request attribute content, particularly where the request appears to reference directory-resolution attributes pointing at hosts other than your actual domain controllers.

CA Database Review

Review certificates issued against the Machine certificate template specifically, since public research points to this as the template involved in the disclosed attack path, filter your review here first rather than across your entire certificate population.
Compare the Requester field against the actual identity the issued certificate represents, using certutil -view filtered by template, for every Machine-template certificate, confirm the account that requested it is legitimately the device the resulting certificate’s subject and SID information represents.
Flag any certificate where a computer or user account requested a certificate whose resulting identity resolves to one of your actual domain controllers, this specific mismatch, a non-DC account requesting and receiving a certificate bearing DC identity, is the central signal this entire investigation is built around.
Don’t limit this review to your current CA only if you’ve had CA changes recently, migrations, renewals, or hierarchy changes covered elsewhere in our series mean historical issuance data may span more than one CA record set.

Event Log Analysis

Apply the same Requester-versus-Subject/SAN correlation covered in our event ID 4886-4889 reference, specifically watching for this pattern on Machine-template requests where the resulting identity maps to a domain controller.
Correlate certificate issuance (event 4887) forward to Kerberos authentication, an Event 4768 (Kerberos TGT request) with PreAuthType set to 16, indicating certificate-based authentication, tied to a domain controller account but originating from an unexpected source, is a strong signal the issued certificate was actually used, not just issued.
Correlate against network listener events identified above, a certificate request event occurring shortly after unexpected listener activity on a non-DC host strengthens the case that a specific request is connected to this attack pattern rather than being unrelated activity.
Extend your search window back to well before your patch date, this vulnerability was reported to Microsoft in May 2026 and patched in July, if your environment was exposed for any meaningful period before patching, your review needs to cover that full window, not just the days immediately around public disclosure.

Issued Certificate Analysis

For any certificate matching the suspicious pattern above, treat it as compromised pending further evidence, not as an open question, the cost of over-flagging a legitimate edge case is far lower than the cost of leaving a genuinely fraudulent domain controller certificate unaddressed.
Determine the certificate’s validity window and current status, confirm whether it’s already expired, still valid, or was already revoked through unrelated activity, this shapes how urgently the revocation step below needs to happen.
Correlate against your authentication logs to determine whether the certificate was actually used, not just issued, a fraudulently issued but never-used certificate and one that’s been used for PKINIT authentication as a domain controller represent very different severity levels for your response.
Preserve the certificate and its full request record as evidence before taking remediation action, export the relevant CA database records and event log entries first, remediation steps like revocation are appropriate to take quickly, but preserve the evidence supporting your investigation before or alongside doing so.

Revocation

Revoke any certificate confirmed or strongly suspected of being fraudulently issued with domain controller identity immediately, don’t wait for investigation to be fully complete before revoking, given the DCSync and krbtgt exposure risk, this isn’t a situation that tolerates a wait-and-see approach.
Publish an updated CRL immediately after revocation and verify its propagation across every configured CDP location, consistent with the publication guidance covered throughout our broader AD CS series.
If there’s any indication DCSync activity actually occurred, treat this as a full domain compromise requiring a krbtgt password reset, performed twice in sequence per standard Active Directory guidance, this is a materially bigger response than certificate revocation alone and should be escalated accordingly.

Containment

Disable or remove unauthorized computer accounts identified during your indicator review, specifically ones created through the machine account quota mechanism described in the public research without a legitimate provisioning justification.
Isolate any host found running unexpected LDAP or SMB/LSA listener activity, treat this consistent with how you’d handle any other host showing signs of active compromise.
Consider tightening ms-DS-MachineAccountQuota to zero as a compensating control, alongside patching, not instead of it, reducing this default’s exposure limits the practical ease of the attack path even after the underlying vulnerability is patched.
Consider restricting Machine template enrollment further while your investigation is ongoing, a temporary tightening of who can enroll against this specific template reduces exposure while you complete the review above.

Recovery

Confirm the patch is applied to every CA in your hierarchy, not just the one you checked first, a multi-CA environment with even one unpatched CA still carries the underlying risk.
Re-issue legitimate domain controller certificates if any ambiguity remains about which are trustworthy, treating certainty about your DC certificate population as a priority worth the operational effort to re-establish cleanly.
Complete the full krbtgt reset procedure if compromise was confirmed, this is a standing Active Directory recovery step independent of AD CS specifically, and it needs to happen before you consider the incident closed.
Build the detection logic from this investigation into standing, ongoing monitoring, rather than treating this as a one-time sweep, the Requester-versus-identity correlation covered here is a permanently useful detection pattern, not just a response to this specific disclosure.

This Guidance Will Be Updated as the Disclosure Evolves

This post reflects public reporting and research available at the time of writing. As is typical for a newly disclosed vulnerability of this severity, further technical analysis, additional indicators, or refined guidance may emerge as the security community and Microsoft continue to publish updates. Check Microsoft’s official security advisory for CVE-2026-54121 and the original researchers’ technical write-up for the most current, authoritative detail, and treat this guide as a starting incident-response framework you should validate against those primary sources.

How Encryption Consulting Can Help

Determining whether a specific vulnerability like this was actually exploited in your environment, versus simply confirming you’re now patched, requires the kind of CA database and event log correlation work that’s genuinely time-sensitive during an active disclosure.

Encryption Consulting’s PKI Services team supports this directly:

Emergency exposure assessment: reviewing your CA database and event logs for the specific indicators covered here, scoped to your actual environment and patch history.
Patch verification across your full CA hierarchy: confirming every CA, not just the ones most visible, has the relevant security update applied.
Incident response support, if evidence of exploitation is found, helping you scope revocation, containment, and recovery correctly, including coordination with your broader Active Directory incident response if domain compromise is confirmed.
Detection logic implementation, turning the Requester-versus-identity correlation covered in this guide into standing, ongoing monitoring rather than a one-time check.
Ongoing vulnerability monitoring, integrated into your broader continuous PKI risk assessment practice, so newly disclosed AD CS vulnerabilities get evaluated against your specific environment quickly.

If you need help determining whether your environment was exposed to Certighost, or want support with patch verification and detection, our PKI Services team can assist directly.

Conclusion

Certighost is a reminder that AD CS security isn’t fully covered by template permission hardening alone, this vulnerability lived in default enrollment behavior itself, not a misconfiguration you could have caught with an ESC1-16 review. Patch immediately if you haven’t, then work through the indicators, CA database review, and event correlation covered here to determine whether your environment shows signs of exploitation before the patch was available. If you find evidence of domain controller impersonation, treat it as the full domain compromise it represents, not an isolated certificate issue, and verify everything here against Microsoft’s current official guidance as this disclosure continues to develop.

Need help determining whether your CA hierarchy was exposed to Certighost, or verifying your patch coverage? Talk to our PKI Services team for emergency exposure assessment. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What is Certighost (CVE-2026-54121)? Certighost is the public name for CVE-2026-54121, a CVSS 8.8 improper-authorization vulnerability in AD CS’s certificate enrollment “chase” mechanism. It allows a low-privileged, authenticated domain user, with no administrative rights required, to obtain a certificate bearing a domain controller’s identity, which can then be used to impersonate that domain controller and potentially compromise the entire domain.

Does hardening certificate templates against ESC1-ESC16 protect against Certighost? No. Certighost exploits a validation gap in AD CS’s default enrollment behavior itself, not a misconfigured certificate template. Organizations that had already hardened their templates against known ESC-series privilege escalation patterns were not necessarily protected, applying Microsoft’s patch is required.

When was the Certighost vulnerability patched? According to public reporting, Microsoft patched CVE-2026-54121 in its July 14, 2026 security updates, roughly two months after the researchers reported it. A working proof-of-concept and full technical details were publicly released on July 24, 2026.

What should an organization do if it suspects its CA was exploited via Certighost before patching? Review issued certificates against the Machine certificate template for identity mismatches, correlate certificate issuance events against authentication logs for unexpected domain controller certificate use, and if any fraudulent domain controller certificate or DCSync activity is confirmed or strongly suspected, treat it as a full domain compromise requiring krbtgt password reset, not just certificate revocation.

Is this guidance on Certighost final and complete? No. This guidance reflects public security research and reporting as of the time of writing. Organizations should verify current details against Microsoft’s official advisory and the original researchers’ published technical write-up, since understanding of newly disclosed vulnerabilities like this one often develops further after initial disclosure.