When a Certificate Looks Like Malware
On May 3, 2026, Windows admins and SOC analysts started seeing a scary Defender alert: Trojan:Win32/Cerdigent.A!dha.
The alert kept coming back. Quick scans did not clear it. Offline scans did not provide answers. Some users saw the same detection across multiple machines at nearly the same time. Others reported that Defender had quarantined root certificate entries from the Windows trust store. The suspicious thumbprints were quickly identified as two DigiCert root certificates: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 and DDFB16CD4931C973A2037D3FC83A4D7D775D05E4.
The timing made the situation worse. Per BleepingComputer, the issue appeared after Microsoft added related detections in an April 30 Defender signature update. By May 3, admins were reporting widespread false positives. Microsoft’s remediation followed quickly: update Defender Security Intelligence to version 1.449.430.0 or later. Microsoft Q&A moderators told affected users the detection was no longer occurring after that update.
“Cerdigent” certainly seems cert-related. The detection was scant of detail otherwise. But why would EDR action on a cert file anyway?
A certificate file is not malware in the way an executable is malware. A .cer, .crt, .der, or .pem file does not run. It does not spawn a process. It does not inject into memory. It is structured trust data.
But on Windows, trust data matters.
A certificate can be malicious because of what it enables. A rogue root certificate can make a system trust attacker-controlled infrastructure. A stolen code-signing certificate can make malware look legitimate. A certificate associated with known phishing, C2, adware, or TLS interception infrastructure can be a valuable detection signal.
The analyst question: What trust decision does this cert affect, where was it found on the endpoint, and who put it there?
Censys Enters the Triage Path
Censys certificate records show that these two hashes resolve to DigiCert Assured ID Root CA and DigiCert Trusted Root G4. The supplied Censys records identify both as DigiCert root certificates, with CA basic constraints, certificate-signing usage, CRL-signing usage, self-signed root behavior, and no revocation. One record shows DigiCert Assured ID Root CA trusted in Microsoft, Apple, and NSS root-store validation. The other shows DigiCert Trusted Root G4 valid across Microsoft, Apple, NSS, and Chrome.
Censys also lets analysts move from certificate identity to Internet context. The Censys certificate dataset is the most exhaustive collection of X.509 documents in existence, with more than 15 billion records! Each record includes parsed certificate fields, trust information from major root stores, Certificate Transparency data, ZLint results, and scan-observation data.
For this incident, a SOC could use Censys to quickly answer:
What are these hashes?
Legitimate DigiCert root certificates.
Are they revoked?
No.
Are they CA certificates?
Yes.
Do major trust stores recognize them?
Yes, with some store-specific nuance.
Are they showing up in live Internet trust paths?
Yes. A Censys host query against certificate validation chains found roughly 2.1k currently online hosts. That number should not be treated as total Internet prevalence for a root certificate, but it does show these certificates appearing in ordinary public TLS validation context, not only in trace suspicious infrastructure.
A root certificate in a validation chain is not the same as a malware payload. It’s trust infrastructure. If EDR is going to treat that trust anchor like a malicious indicator, SOCs need a source of truth outside the alert itself.
Censys gives analysts authoritative certificate records, root-store validation context, revocation status, CT history, linting, scan observation, and Internet-wide search.
Censys does not prove that a trusted certificate authority could never be abused. No single data source can. What Censys does is prevent analysts from mistaking the presence of a legitimate trust anchor for proof of compromise.
The hard part of security operations is not that every alert is an incident. It’s that every alert has to be treated seriously until the evidence says otherwise.
The Sisyphean work of the SOC: pushing uncertainty uphill, one signal at a time, trying to be as certain as the situation allows. Good context does not make that work disappear. It makes the climb less blind.
