Defender Quarantined DigiCert Roots Worldwide — Here's the Fix

Two stories in one: a Defender false positive that quarantined DigiCert root certificates worldwide — and the very real DigiCert breach that triggered the over-aggressive detection logic in the first place.

A Microsoft Defender Antivirus signature update released around April 30, 2026 began incorrectly flagging two legitimate, widely trusted DigiCert root certificates as Trojan:Win32/Cerdigent.A!dha — quarantining and, on affected systems, removing the certificate entries from the Windows trust store. Microsoft acknowledged the issue, confirmed it was a false positive triggered by detection logic added in response to a real DigiCert code-signing certificate compromise, and shipped Security Intelligence update 1.449.430.0 (and subsequently 1.449.431.0) to suppress the alerts and restore the certificates.

The actionable summary: if you run Microsoft Defender, get to Security Intelligence version 1.449.430.0 or later, then verify both DigiCert root certificates are present in the Windows trust store. Microsoft's auto-update path will handle this for most environments. The deeper story underneath the false positive — a real, social-engineering-driven compromise of DigiCert support endpoints that led to the misuse of EV code-signing certificates and revocation of 60 of them — is the one worth reading carefully.

What Defender Did, and Why It Mattered

The detection logic introduced in the April 30 signature update labeled registry entries belonging to two of the most widely trusted root certificates on the internet — DigiCert Assured ID Root CA and DigiCert Trusted Root G4 — as high-severity malware. Defender's standard remediation workflow then quarantined those registry entries, removing the certificates from the Windows trust store on affected systems.

The downstream risk was real and not theoretical. Without those root certificates in place, affected systems could fail to validate SSL/TLS connections to sites whose chains rely on those roots, and could break code-signing verification for legitimate software. Reports across Reddit and Microsoft Q&A described the predictable cascade — browser certificate warnings, application launch failures, signed-update errors. Some administrators, panicking at "high-severity malware detected" alerts on production machines, reimaged endpoints before realizing the alerts were false positives.

Cybersecurity researcher Florian Roth (@cyb3rops) was among the first to publicly flag the issue, urging the security community to investigate and providing both an Advanced Hunting query for Microsoft Defender for Endpoint and a quick command-line check: certutil -store AuthRoot | findstr -i "digicert". Microsoft's own Q&A forums quickly filled with administrator reports confirming that the certificate thumbprints flagged by Defender matched the officially published values from DigiCert, ruling out actual compromise.

Microsoft's Acknowledgment and the Fix

Microsoft confirmed the issue to BleepingComputer in a statement that connects the false positive to the real DigiCert breach: "Following reports of compromised certificates Microsoft Defender immediately added detections for malware in our Defender Antivirus Software to help keep customers protected. Earlier today we determined false positive alerts were mistakenly triggered and updated the alert logic. Microsoft Defender suppressed and cleaned up the alerts for customer environments. Customers should update to Security Intelligence version 1.449.430.0 or later, but do not need to take additional action for these alerts. We have notified affected organizations and recommend administrators look for more details in the service health dashboard (SHD) within the M365 admin center."

The 1.449.430.0 update both suppressed the false-positive detection and triggered restoration of the previously removed certificates on affected systems via Defender's standard remediation paths. Subsequent updates (1.449.431.0 at time of reporting) shipped on top. For most environments, the auto-update flow will handle this without administrator intervention. Managed environments with delayed-update policies, ICS/OT segments where signature updates are gated, or air-gapped systems need manual verification.

The Real DigiCert Breach Underneath

The detail that elevates this from "Microsoft shipped a bad signature, here's the patch" to a more serious story is the underlying breach DigiCert was responding to. Per DigiCert's incident report on Mozilla Bugzilla #2033170, on April 2, 2026, a threat actor contacted DigiCert's support team via a customer chat channel and delivered a ZIP file disguised as a customer screenshot. The ZIP contained a .scr file — a Windows screensaver executable format that has been a malware delivery vector for decades.

CrowdStrike and other security measures blocked four delivery attempts. A fifth attempt, on April 3, compromised the endpoint of one DigiCert support analyst (detected and contained that day). On April 4, a second support analyst's endpoint was compromised through the same vector — but a malfunctioning CrowdStrike implementation on that endpoint meant the second compromise was not detected until April 14. Between April 14 and April 17, DigiCert identified and revoked the certificates potentially affected by the threat actor's actions.

The mechanism of abuse is the part that should concern any CA-adjacent security architect. The threat actor used a feature of DigiCert's customer-support portal that lets support analysts view customer accounts from the customer's perspective. That feature, while limited in function, exposed initialization codes for approved-but-undelivered EV code-signing certificate orders. Possession of an initialization code combined with an approved order is sufficient to obtain the resulting EV code-signing certificate. The threat actor was able to obtain those certificates across a set of customer accounts.

DigiCert revoked 60 code-signing certificates. Of those, 27 were explicitly linked to the threat actor: 11 identified in community certificate-problem reports tying the certificates to malware, 16 identified during DigiCert's own investigation. The remaining 33 were revoked as a precautionary measure. The exploited certificates were used to sign the Zhong Stealer malware family — characterized in subsequent analysis as more like a remote access trojan than a classic infostealer, with a phishing-driven distribution chain that delivers a fake image or screenshot, executes a first-stage payload from the disguise, and retrieves a second-stage payload from cloud storage.

One detail from DigiCert's report worth flagging: DigiCert noted that compromised certificates from other certificate authorities — not just DigiCert — have also been used to sign Zhong Stealer. The campaign is broader than one CA. The ZIP-and-.scr social engineering vector is also a familiar pattern; social engineering remains the highest-leverage technique in supply-chain compromises like this.

Why the Defender False Positive Wasn't a Random Bug

The clarification matters: the certificates flagged by Microsoft Defender are DigiCert root certificates in the Windows trust store. They do not match the revoked DigiCert code-signing certificates that were misused to sign malware. Microsoft's detection logic appears to have incorrectly extended a response to the DigiCert breach into flagging unrelated DigiCert root certificates — exactly the kind of overreach that happens when detection logic is shipped fast under incident pressure.

This is the second rough month for Defender's reputation as a managed security product. The Cerdigent false positive lands a week after CISA mandated federal agencies patch the BlueHammer Defender zero-day, with two related Defender vulnerabilities still unpatched. The two stories are separate technical issues, but their proximity is worth noting for any organization weighing Defender as the sole detection layer in its environment.

Defender Actions for Microsoft Customers This Week

• Verify Microsoft Defender is at Security Intelligence version 1.449.430.0 or later on every Windows endpoint. Open Windows Security → Virus & threat protection → Protection updates → Check for updates. Managed environments with delayed-update policies need manual verification.
• After updating, confirm certificate presence with: certutil -store AuthRoot | findstr -i "digicert". Both DigiCert Assured ID Root CA and DigiCert Trusted Root G4 should be listed.
• Run Florian Roth's published Advanced Hunting query in Microsoft Defender for Endpoint to identify any systems where the certificates have not been restored. The query filters for RegistryKeyCreated events under the AuthRoot certificates registry path after the fix-update timestamp.
• Monitor the M365 admin center Service Health Dashboard for follow-up notifications. Microsoft has stated affected organizations have been notified there.
• Do NOT roll back affected machines or restore from backup for this issue. The fix is in the signature update; reimaging is unnecessary and several admin reports document users who reimaged before realizing the alerts were false positives.
• Separately, on the underlying DigiCert breach: review your code-signing certificate procurement and validation hygiene. If you use EV code-signing certificates, audit recent issuances for any certificates you did not order. Threat hunting for binaries signed with recently-revoked certs is a worthwhile exercise; cross-reference Mozilla CA Communication on this incident with your asset inventory.

The CyberSignal Analysis

Signal 01 — Detection logic shipped under pressure is itself a supply-chain risk

The Cerdigent false positive is the security industry's version of "the cure was almost worse than the disease." Microsoft did the right thing in adding detections for the abuse of compromised DigiCert code-signing certificates — protecting customers from the real threat is what the product is for. But the detection logic, shipped fast, was overbroad enough to flag legitimate DigiCert root certificates and trigger automated quarantine across a global customer base. Speed and accuracy are in tension when an EDR vendor responds to an active CA breach. Customers should expect that tension to produce more incidents like this one as detection update cycles compress, and should plan for it: don't put critical operational dependencies on detection logic that just shipped, and have a fast rollback path for signature updates that target trust-store components.

Signal 02 — DigiCert's incident is a textbook customer-support attack surface

The DigiCert breach mechanism — a threat actor ZIPs a malicious .scr file disguised as a screenshot, sends it to support staff via a customer chat channel, compromises a support analyst endpoint, then uses a legitimate support-portal feature (the ability to view customer accounts from the customer's perspective) to harvest EV code-signing certificate initialization codes — is precisely the kind of attack surface that gets underweighted in CA threat models. Production CA infrastructure typically receives extreme controls. Customer support analyst endpoints typically don't, despite having functional access to enough customer-perspective features to issue valid certificates. The lesson for any organization operating a CA, a CA-reseller, a key management service, or a similar trust-issuance business is that customer-facing support tooling needs to be inside, not outside, the production trust boundary.

Signal 03 — Zhong Stealer using compromised certs from multiple CAs is the campaign signal

The detail in DigiCert's report that should worry threat-intel teams is the noting that certificates from other CAs — not just DigiCert — have also been observed signing Zhong Stealer. That implies an active campaign with a procurement pipeline for valid code-signing certificates from multiple sources. DigiCert's revocations close one channel. The campaign continues. Defenders hunting for binaries signed with recently-revoked code-signing certificates from any CA should continue that hunt past the DigiCert news cycle. The story isn't done when DigiCert's investigation ends; it's done when the campaign stops getting new certificates, and there is no public evidence yet that it has.

Sources