A "Screenshot" in DigiCert's Support Chat Was Actually a Screensaver Virus—And It Walked Out With 60 Valid Code Signing Certificates

On April 2, 2026, a DigiCert support analyst received what looked like a customer screenshot through the live chat tool. The attached file was actually a Windows screensaver—the same .scr format Windows has shipped since the 1990s, which is functionally identical to an executable but easier to disguise as a passive object. DigiCert's internal security tools blocked the file four times. On the fifth attempt, after the attacker repackaged it, the analyst's machine ran it.

By May 4, when DigiCert disclosed the incident, the attacker had been inside the company's customer support portal long enough to generate 27 fraudulent Extended Validation code signing certificates in the names of real DigiCert customers. Those certificates were then used to digitally sign Zhong Stealer, a credential and cryptocurrency stealer attributed to the China linked group tracked as GoldenEyeDog or APT-Q-27. Sixty certificates were revoked in total, including 33 the company pulled as a precaution.

Five Attempts Until the Filter Gave Up

The attacker's persistence is the first thing worth flagging. DigiCert's own systems flagged the file four times. On the fifth submission, with the payload modified just enough to slip the static analysis, ENDPOINT1—the first support agent's machine—executed the program. The screensaver file installed a backdoor that gave the attacker remote access to the agent's session.

Two days later, on April 4, the attacker pivoted to a second machine, ENDPOINT2. That one stayed compromised for roughly two weeks. The reason is buried in DigiCert's writeup: the CrowdStrike sensor on ENDPOINT2 was malfunctioning at the time, creating what the company described as an EDR gap. Telemetry that should have alerted the security team never made it out. The agent kept working. The attacker kept watching.

The Initialization Code Loophole

DigiCert's support portal exists so that analysts can help customers who get stuck during certificate issuance. To do that, the portal exposes a per order "initialization code"—a string that proves the analyst is helping a real, in flight order.

The attacker discovered that those codes worked as bearer credentials. Anyone holding the code could continue the order as if they were the customer who placed it. The portal did not enforce that the entity completing the order had to be the entity that started it. Combine a stolen initialization code with knowledge of the corresponding approved order, and you can mint a real EV Code Signing certificate in someone else's name.

DigiCert confirmed that the attacker did exactly this 27 times. The certificates that came out the other side were technically valid. They chained up to DigiCert's roots, which every operating system trusts, and they carried the names of legitimate organizations. Windows would happily run anything signed with them and rarely show the user a single warning.

Zhong Stealer Got the Signatures

The malware that the certificates were used to sign is Zhong Stealer, a family that researchers have been tracking since 2024 and that has been attributed to GoldenEyeDog, also referenced in some reports as APT-Q-27. The group is China linked and historically focused on cryptocurrency theft and credential harvesting against Chinese language speakers and the broader Asia Pacific region. Zhong Stealer harvests browser passwords, crypto wallet seed phrases, and exchange session cookies, with a particular focus on Binance, OKX, and similar platforms.

The certificates were the missing ingredient. A signed Zhong Stealer binary that says "Acme Corp" on the publisher line is dramatically more likely to slip past corporate allowlists and end user prompts than an unsigned blob from a hosting domain no one has heard of. Microsoft Defender, ironically, did still flag some of the signed samples after the campaign was disclosed, which generated a wave of false positive complaints from legitimate customers whose certificates had been on the revocation list.

How the Outside World Found Out

DigiCert's internal investigation did not catch the full scope. The signal came from outside. On April 14, an independent researcher noticed Zhong Stealer samples that carried legitimate DigiCert signatures and pieced the picture together. Eleven of the 27 fraudulent certificates were identified through community submitted malware reports; the rest only surfaced when DigiCert combed its own logs in response.

Under Mozilla's CA program rules, DigiCert is required to publicly document any compromise in its issuance pipeline. The full incident response report sits in Bugzilla as bug 2033170, alongside the certificate authority compliance audit that all browser trust stores rely on. The Mozilla disclosure includes a timeline, the indicator hashes for the malicious screensaver, and the list of revoked certificates.

By April 17, DigiCert had revoked all 60 certificates and backdated the revocation to their original issuance date. Pending orders in the affected window were canceled. The customer support portal was hardened in two specific ways: .scr attachments are now blocked at the chat layer, and initialization codes are now masked from the analyst's own view.

Why This Mattered to Email Users Specifically

Code signing certificates determine which programs your computer will run quietly and which ones will pop a warning. When a phishing email arrives with an attached installer, the Windows SmartScreen and AppLocker stacks check the signature before the file runs. A signed binary from a known publisher passes with no prompt. An unsigned binary or one with an untrusted signature gets blocked or warned about.

For three weeks, anyone who downloaded a Zhong Stealer payload—from a phishing email, a malvertising redirect, or a poisoned download link—saw a signed, trusted file. The same campaigns that delivered the malware also harvested Gmail and Outlook credentials, which is the entire business model of the GoldenEyeDog group. The certificate authority compromise is, in effect, an email security story dressed in PKI clothing. The endpoint trust that protects your inbox depends on the chain of trust the certificate authorities maintain. When that chain breaks at the help desk, every downstream defense loses its anchor.

What This Says About Help Desks as the New Perimeter

The DigiCert breach belongs to the same family as the vishing attacks that ShinyHunters has been running against Salesforce customers all year, and to the OAuth phishing campaigns that abuse Microsoft 365 device code flows. The pattern is the same. The technical fortress is fine. The path to the fortress runs through the customer support tools that are designed to be open to outsiders.

There are three lessons that the DigiCert writeup makes explicit and which other companies should treat as homework due yesterday:

• Block executable formats at the support chat layer. The .scr extension is not the only one—.exe, .com, .bat, .cmd, and any container that can hold them all need the same treatment.
• Treat support analyst credentials as privileged credentials. They can issue certificates, reset MFA, and impersonate customers. Their endpoints need the same EDR and audit posture as a domain controller.
• Stop using order side data as a bearer credential. Anything that lets the holder complete a customer action should be tied to the customer's own authentication, not retrievable by anyone with portal access.

The five blocked attempts in DigiCert's chat are also a useful reminder for every other company: persistent attackers will keep trying. The fact that your filter caught the first four attempts does not mean it will catch the fifth.