#Update 2026-05-05 // CrowdStrike's marketing team alerted me to the following update on Bugzilla. The full incident report was updated with the following to acknowledge CrowdStrike wasn't installed or configured on the endpoint:
On 2026-04-14, further investigation identified that ENDPOINT2, a machine used by another analyst was compromised through the same delivery vector on 2026-04-04. CrowdStrike was not installed or configured on that endpoint, meaning the compromise was not detected during the earlier 2026-04-03 investigation. The machine was established more than 3 years ago. Because our end-user machine logs are retained for three years, we cannot determine why CrowdStrike was not installed or configured on this particular endpoint.
Certificate authorities sit at the foundation of online trust. So when one of the largest, DigiCert, gets hacked through a fake screenshot in a customer support chat, it is worth paying attention.
What happened
In early April 2026, a threat actor posed as a customer and contacted DigiCert's support team through its chat channel. The attacker uploaded a malicious ZIP file disguised as a customer screenshot, which actually contained a .scr file, the format Windows uses for screensavers. After several blocked attempts, two support analyst machines were eventually compromised.
From there, the attacker used a feature inside DigiCert's internal support portal that lets authenticated analysts view customer accounts from the customer's perspective. While that view does not allow account changes or new orders, it did expose initialization codes for previously approved but undelivered EV code signing certificate orders. Combined with an approved order, those codes were enough to obtain real, trusted code signing certificates.
How bad was it
DigiCert ultimately revoked 60 code signing certificates, 27 of which were tied directly to the attacker. Eleven of those were already being used in the wild to sign the Zhong Stealer malware family when community researchers flagged them.
One detail stands out. On the second compromised analyst machine, the attacker stayed put for nearly two weeks because the CrowdStrike EDR agent had been misconfigured and was not reporting to its central management server. DigiCert openly described itself as "lucky" that an outside security researcher noticed certificates being abused and reported it, which is what triggered the broader investigation.
The Microsoft Defender twist
Just as the dust was settling, things got messier. A faulty Microsoft Defender signature update deployed on April 30, 2026 began flagging two legitimate DigiCert root CA certificates as Trojan:Win32/Cerdigent.A!dha and silently removing them from Windows trust stores. That had nothing to do with the actual breach, but it threatened to disrupt SSL/TLS validation and code signing across enterprise environments worldwide. Microsoft pushed a corrective update that began restoring the quarantined certificates, and researcher Florian Roth shared certutil queries admins could use to verify their systems.
What DigiCert changed
In response, DigiCert tightened several controls: enforcing MFA on administrative workflows, blocking access to initialization codes when staff are proxied into customer accounts, restricting attachment file types in support chat and Salesforce cases, and improving logging.
Indicators of compromise
The IOCs below were published in DigiCert's Mozilla incident report and corroborated by community researchers.
| Type | Indicator | Notes |
|---|---|---|
| IP address | 82[.]23[.]186[.]8 | Used by threat actor to install certificates |
| IP address | 154[.]12[.]185[.]32 | Used by threat actor to install certificates |
| IP address | 154[.]12[.]185[.]30 | Used by threat actor to install certificates |
| IP address | 45[.]144[.]227[.]12 | Used by threat actor to install certificates |
| IP address | 45[.]144[.]227[.]29 | Used by threat actor to install certificates |
| IP address | 203[.]160[.]68[.]2 | Used by threat actor to install certificates |
| IP address | 62[.]197[.]153[.]45 | Used by threat actor to install certificates |
| File type | .scr inside ZIP archive | Malicious payload disguised as a customer screenshot |
| Malware family | Zhong Stealer | Credential and cryptocurrency stealer; behaves like a RAT |
| Threat group | GoldenEyeDog (APT-Q-27) | Chinese e-crime group linked to the certificates |
| Issuing CA | DigiCert Trusted G4 Code Signing RSA4096 SHA256 2021 CA1 | Source of revoked certificates |
| Issuing CA | DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1 | Source of revoked certificates |
| Impacted subjects | Lenovo, Kingston, Shuttle Inc, Palit Microsystems, Tencent, DigiFors | Organizations whose pending EV orders were abused |
| Defender false positive | Trojan:Win32/Cerdigent.A!dha | Unrelated Defender bug that flagged DigiCert root CAs |
| Root cert thumbprint | 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 | DigiCert Assured ID Root CA, falsely flagged |
| Root cert thumbprint | DDFB16CD4931C973A2037D3FC83A4D7D775D05E4 | DigiCert Trusted Root G4, falsely flagged |
The full list of 60 revoked certificate serial numbers is available in the appendix of DigiCert's Bugzilla incident report.
The takeaway
This breach is a clean case study in modern social engineering. There was no zero day, no exotic exploit chain. A .scr file in a chat message and one misconfigured EDR agent were enough to reach into the certificate issuance pipeline of a top tier CA. For the rest of us, the lessons write themselves: lock down what support staff can see and do on behalf of customers, verify that endpoint protection is actually reporting home, restrict file types in any user facing channel, and assume that the trust infrastructure you depend on is itself a target.
