When a Screensaver Cracked the Internet's Trust Layer: Inside the DigiCert Hack

Summary

In April 2026, a threat actor posed as a customer and compromised two DigiCert support analyst machines by uploading a malicious screensaver file (.scr) disguised as a screenshot. The attacker exploited internal portal access to extract initialization codes for EV code signing certificates, resulting in 60 revoked certificates, 27 directly linked to the attacker and 11 already used to sign Zhong Stealer malware. The breach was detected only when an external researcher flagged certificate abuse; a second compromised machine went undetected for two weeks because the CrowdStrike EDR agent was misconfigured.

Full text

#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 happenedIn 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 itDigiCert 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 twistJust 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 changedIn 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 compromiseThe 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 takeawayThis 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.

Indicators of Compromise

• ip — 82.23.186.8
• ip — 154.12.185.32
• ip — 154.12.185.30
• ip — 45.144.227.12
• ip — 45.144.227.29
• ip — 203.160.68.2
• ip — 62.197.153.45
• malware — Zhong Stealer

Entities