DigiCert Got Got By A Screensaver. The Receipts: Bugzilla #2033170, Eleven Community Reports, Sixty Revoked Certs.

Patrick Duggan
4 minutes ago
5 min read

EDR blocked four attempts. The fifth landed.

May 5, 2026 · Patrick Duggan, DugganUSA LLC

DigiCert — one of the largest commercial certificate authorities on earth — got phished through their own customer support chat. The vector was a Windows screensaver file in a ZIP, disguised as a customer screenshot. CrowdStrike + endpoint defense blocked four delivery attempts. Number five got through. The attacker spent ten days inside before anyone noticed. They walked out with the ability to issue EV code signing certificates under the names of major hardware vendors. Sixty certs got revoked. Eleven of them had already been used to sign Zhong Stealer payloads — credential and crypto theft malware linked to the China-aligned GoldenEyeDog (APT-Q-27) group.

This is not a CA root compromise. The web-PKI trust chain is fine. What broke is the human ring around the trust system, and the lesson is that EDR is necessary and not sufficient when the adversary is willing to send the same payload five times.

What got got

April 2, 2026. A threat actor opens a chat with DigiCert customer support via Salesforce-based chat. They impersonate a customer with a question. They attach what looks like a screenshot — a ZIP file containing a .scr (Windows screensaver). On Windows, .scr files are native executables. Treating them as inert images is the social-engineering hand on the wheel.

The first four delivery attempts get blocked by CrowdStrike + DigiCert's endpoint stack. The fifth lands. ENDPOINT1, a support-team workstation, is now compromised.

April 4. ENDPOINT2, a second support-team workstation, gets the same vector.

April 14. DigiCert detects ENDPOINT2's compromise. Ten days of unrestricted access. The attacker has been inside long enough to know the issuance workflow, to know which support-portal flows can mint EV code signing certs without secondary approval, and to know which legitimate hardware-vendor identities don't get human review.

April 14–17. DigiCert revokes 60 certs. Twenty-seven explicitly tied to the attacker. Eleven of those, identified by community-submitted certificate problem reports, have already been used to sign Zhong Stealer payloads. Sixteen more are caught by DigiCert's internal investigation. Thirty-three are precautionary — DigiCert can't confirm customer control.

The revoked certs were issued under the names of legitimate hardware vendors: Lenovo, Kingston, Shuttle Inc., Palit Microsystems. Hardware vendor identities are softer than software vendor identities for impersonation — driver-level trust patterns are older, more permissive, and less scrutinized than modern app-signing.

All revocations were committed within 24 hours of discovery. For DigiCert specifically, that is fast — Bugzilla bugs #1651828, #1894560, #1896053 record DigiCert's prior history of delayed revocations. The pattern this time was the opposite. Credit where it's due.

Who had receipts first

The primary source is Mozilla Bugzilla bug #2033170, where DigiCert filed the incident report with the CA community as required under CA/Browser Forum baseline requirements. That's the only fully-canonical record. Everyone else — Help Net Security, SecurityWeek, BleepingComputer, CyberInsider, GBHackers, the rest — is downstream of that filing.

But the receipt that matters more is the eleven community certificate problem reports. Eleven external researchers caught the abuse before DigiCert's own internal investigation did. Those eleven reports are the reason eleven attacker certs were known to be malware-signing rather than just precautionary revocations. The community brought DigiCert the receipts on the certs that mattered. DigiCert's investigation contributed sixteen more on top of that, but the first signal came from outside.

The community research thread on Zhong Stealer infrastructure includes MalwareHunterTeam and g0njxa, both of whom published payload hashes and C2 domains. Those are the IOCs that turn this from a CA incident into an actionable defender artifact.

DugganUSA had no prior IOCs tagged "Zhong Stealer" or "GoldenEyeDog" in our index before today. Zero. Net-new attribution territory for our archive. We will be ingesting the published IOCs from the Mozilla report appendix and the MalwareHunterTeam / g0njxa research into our own STIX feed within the day.

Were they a customer

No. DigiCert is not a DugganUSA STIX feed customer. They are a CA — the kind of organization that produces threat intel rather than purchasing it from a four-person shop.

That said, our search_queries index shows four visitor searches for "digicert" on our site. Audience interest is small but real. Once our STIX feed contains the Zhong Stealer IOCs, anyone querying "digicert" against our corpus gets the active campaign artifacts back instead of a Wikipedia summary.

If anyone reading this is a DigiCert customer worried about whether your EV code signing cert is on the revoked list of sixty: the full serial numbers are in the Bugzilla #2033170 appendix. Pull them and grep your local cert store. If you appear, you've already been notified by DigiCert.

The Defender twist

Microsoft Defender, in response to the incident, started flagging legitimate DigiCert root certificates as Trojan:Win32/Cerdigent.A!dha on Windows 11 and Windows Server fleets globally. False positive. The detection signature was overbroad. Defenders worldwide spent a chunk of yesterday quarantining trust anchors that should not have been quarantined.

This is the second-order chaos that comes after a CA incident. The fix is a Defender signature update — but in the window between the false positive landing and the rollback, organizations were prompted to remove DigiCert roots from trust stores. Some did. Re-adding root certs after they've been quarantined-by-AV is not a one-click operation in most fleets.

The compounded risk: a real CA incident triggers a defensive false positive that breaks correctly-signed software at scale. We are reaching the part of the curve where defensive systems can hurt customers more than the original attack did. Worth a separate post in its own right.

What this means for everyone who isn't DigiCert

Three takeaways with operational legs.

EDR blocks the first four. Plan for the fifth. Patient social engineering — same payload, repeated through a service-desk chat, repeated until tired or until something gets through — beats endpoint defenses that are tuned for opportunistic attackers. The defense that would have stopped this is not better EDR. It is support-channel chat being a no-attachment zone, full stop, plus per-attachment sandbox detonation in a separate environment regardless of EDR verdict, plus suspicion training that says "five attempts is the campaign, not the noise."

EV code signing is the new supply chain target. npm typosquats, GitHub-hosted SmartLoader payloads, and now hardware-vendor-named EV certs. The attacker is climbing the trust ladder. The next rung is somebody whose job is to sign drivers with kernel-level privileges. Once you assume EV code signing is compromisable through a support analyst's screensaver, every signed binary you ship needs runtime telemetry behind it — the cert says "trust the publisher," not "trust this binary."

Receipts come from outside more often than from inside. Eleven of the twenty-seven attacker-tied certs were caught by community reporters, not DigiCert's investigation. The web-PKI immune system still works, but the immune cells live outside the CA, not inside. If you run a CA and you don't have a fast-track for community certificate problem reports, you are slower than the attackers.

The 95% ceiling

This post is sourced from DigiCert's own Bugzilla #2033170 filing, mirrored across Help Net Security, SecurityWeek, BleepingComputer, CyberInsider, GBHackers, Dark Web Informer, The420.in, and the Cerdigent false-positive coverage at Neowin and The Cyber Signal. The China attribution to GoldenEyeDog / APT-Q-27 comes from MalwareHunterTeam and g0njxa research and is treated as 90% confidence. Five percent of any complex assessment is wrong, including this one.

The thing we are most certain of is that the screensaver landed on the fifth try. DigiCert wrote that down themselves.

— Patrick Duggan, DugganUSA LLC, Minneapolis · 2026-05-05

Sources

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com