DigiCert, one of the world's largest public Certificate Authorities (CAs), has disclosed that attackers compromised its internal support portal using a malicious Windows screensaver file, fraudulently obtained 60 Extended Validation (EV) Code Signing certificates (the highest-trust tier of code signing credentials, which grant signed software elevated trust by operating systems and security tools), and used at least 11 of them to sign payloads belonging to the Zhong Stealer malware family — a credential and cryptocurrency-stealing tool previously linked to the China-linked threat group GoldenEyeDog (also tracked as APT-Q-27). All identified certificates were revoked by April 17, 2026.
EV Code Signing: Why These Certificates Matter
Code signing is the practice of digitally signing software executables and scripts to prove authenticity and integrity — confirming that a file came from who it claims to come from and has not been tampered with in transit. Operating systems, browsers, and security platforms use these signatures to decide how much trust to extend to a piece of software.
EV Code Signing certificates represent the highest tier of code signing trust. Unlike standard Organization Validated (OV) certificates, EV certificates require the certificate authority to conduct rigorous identity verification of the requesting organization — including physical presence checks, verified business records, and legal standing confirmation. In exchange for this elevated scrutiny, EV-signed software receives privileged treatment: Microsoft SmartScreen (the Windows Defender browser and file filter that warns users about downloaded software of unknown origin) grants EV-signed executables a clean reputation from their first appearance, bypassing the reputation-building period that standard-signed software must earn. That means malware signed with a stolen EV certificate can run silently on Windows machines that would otherwise flag or block it.
This is precisely why threat actors target certificate authorities and their customers: a stolen EV certificate transforms a malicious payload from a red flag into a green light.
How Attackers Breached DigiCert's Support Portal
The intrusion began on April 2, 2026, when an unknown threat actor impersonated a customer and contacted DigiCert's support team through its official customer chat channel. The attacker delivered a malicious ZIP archive disguised as a customer screenshot. Inside the ZIP was a .scr file — the Windows screensaver format, a legitimate binary extension that Windows executes as a program, frequently abused as a malware delivery mechanism because security filters sometimes pass it where they would block .exe files.
The .scr file installed malware on a support analyst's system. DigiCert identified the first infected endpoint on April 3 — one day after initial compromise — but a second infected system was not detected until April 14, a gap of nearly two weeks. The company attributed the delayed detection to an "endpoint protection sensor gap," indicating that one machine lacked adequate EDR (Endpoint Detection and Response) coverage or that agent telemetry was not being continuously reviewed.
With footholds on two endpoints inside DigiCert's support environment, the attackers turned to the support portal itself. DigiCert's authenticated support analysts possess a proxy function that allows them to view and interact with customer accounts from the customer's perspective — a legitimate feature designed to facilitate account troubleshooting without requiring customers to share credentials. The attackers leveraged this proxy access to locate approved-but-not-yet-issued Code Signing certificate orders and obtain the associated initialization codes.
Under the DigiCert issuance workflow, possession of a valid initialization code combined with an approved certificate order is sufficient to complete certificate issuance. The threat actor extracted both pieces of data for a set of customer accounts across multiple CAs operated by DigiCert, then completed the issuance requests — producing fully trusted, customer-attributed EV Code Signing certificates without the certificate holders' knowledge.
Researchers including Squiblydoo, MalwareHunterTeam, and g0njxa reported observing the fraudulently issued certificates being used in the wild. The affected certificate subscribers included well-known hardware and technology firms — among them Lenovo, Kingston, Shuttle Inc., and Palit Microsystems — whose approved certificate orders were hijacked in the attack.
Certificates Revoked and Malware Signed
By April 17, 2026, DigiCert had identified and revoked 60 certificates in total:
- 27 certificates were explicitly linked to the threat actor's fraudulent issuance activity.
- 11 certificates were confirmed by external researchers to have been actively used to sign malware — specifically, payloads belonging to the Zhong Stealer malware family.
DigiCert stated that all identified malicious or potentially exposed certificates were revoked within 24 hours of discovery and that the Mozilla CA Community forum was notified via Bugzilla report #2033170, as required under CA/Browser Forum baseline requirements.
The remaining 33 certificates in the revocation set were revoked as a precaution due to the possibility that the threat actor may have accessed additional initialization codes not yet used for issuance.
Zhong Stealer: What the Malware Does
Zhong Stealer is an infostealer (a class of malware designed to silently harvest credentials, session tokens, and financial data from infected machines and transmit it to attacker-controlled infrastructure). It targets stored browser credentials, cryptocurrency wallet data, and authentication session cookies. Its previous campaigns have been associated with the GoldenEyeDog threat group (also identified as APT-Q-27), a financially motivated cluster with links to Chinese-language cybercrime ecosystems.
It is not yet publicly confirmed whether GoldenEyeDog conducted the DigiCert breach itself or whether another threat actor purchased or leased the fraudulently obtained certificates and used them in Zhong Stealer campaigns. Researchers have noted the attribution is unclear at this stage.
Exploitation Status and Threat Landscape
Active exploitation is confirmed. Eleven certificates obtained through the DigiCert support portal breach were used to sign and distribute Zhong Stealer payloads prior to revocation. The 11 signed samples were identified by independent malware researchers monitoring threat actor infrastructure and VirusTotal feeds.
CISA's Known Exploited Vulnerabilities (KEV) catalog does not list this incident, as no CVE was assigned — this was a process and access control failure, not a software vulnerability in the traditional sense. However, the real-world impact is equivalent to a supply chain compromise: legitimate company names (Lenovo, Kingston) appear on the certificate signer field of malware binaries, providing a layer of false legitimacy that endpoint defenses may not strip away even after revocation, depending on whether Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) stapling is configured and enforced.
A secondary incident followed the public disclosure: Microsoft Defender incorrectly flagged DigiCert root certificates as Trojan:Win32/Cerdigent.A!dha — a false positive triggered by detection logic that conflated the revoked certificates with the root CA's own trusted certificates. Microsoft corrected the detection signature, but the false positive caused widespread alerts across enterprise environments before the fix was deployed.
Who Is Affected
Any organization or individual who:
- Received and installed software signed between April 2 and April 17, 2026 with certificates issued under DigiCert-operated CAs should verify the signer against the revocation list.
- Operates Windows endpoints without OCSP or CRL enforcement may continue to run Zhong-Stealer-signed binaries that the OS trusts despite certificate revocation.
- Deploys software signed by Lenovo, Kingston, Shuttle Inc., or Palit Microsystems should verify whether the specific signing certificate serial number appears in DigiCert's revocation disclosure.
- Builds software products and uses DigiCert for code signing should audit recent certificate orders and confirm that no initialization codes were accessed without their knowledge.
What You Should Do Right Now
- Check your installed software against DigiCert's revocation disclosure. DigiCert has published its incident report and the list of revoked certificate serial numbers via the Mozilla CA Community forum. Cross-reference any recently installed executables signed by the affected organizations (Lenovo, Kingston, Shuttle, Palit).
- Run a hash check on executables signed between April 2–17. For any binary signed during the exposure window, verify its hash against known-good sources and run it against an up-to-date AV engine with Zhong Stealer signatures loaded.
- Enforce OCSP Must-Staple or CRL checking on your endpoints. If your Windows environment does not validate certificate revocation status before trusting signed binaries, revoked certificates still appear valid. Group Policy can enforce this via
Certificate Path Validation Settings.
- Hunt for Zhong Stealer IOCs. Zhong Stealer communicates with attacker-controlled C2 infrastructure; published IOCs from MalwareHunterTeam and g0njxa include C2 domains and file hashes. Push these to your SIEM and EDR for retrospective hunting.
- Audit your DigiCert certificate orders. If your organization uses DigiCert for code signing, log in to your account and review all certificate orders initiated before April 17. Contact DigiCert support if any order was completed without your explicit action.
- Verify Microsoft Defender is updated past the false-positive window. Ensure Defender definition updates from after April 18, 2026 are applied, which include the corrected Cerdigent detection that no longer flags legitimate DigiCert roots.
Background: Understanding the Risk
This breach illustrates a systemic risk in the certificate issuance supply chain: the trust that browsers, operating systems, and security tools extend to code signing certificates is only as strong as the identity controls at the CA that issued them. When those controls fail — whether through a stolen credential, a social engineering attack, or an insider threat — the entire downstream trust model is undermined.
This is not DigiCert's first encounter with certificate integrity issues. In July 2024, DigiCert disclosed it had failed to properly verify domain ownership for a subset of TLS certificates over a multi-year period, resulting in emergency revocation of thousands of HTTPS certificates. The current incident is structurally different — it involves targeted theft of issuance credentials, not a systemic validation failure — but it reinforces that certificate authorities are high-value targets for attackers who understand the downstream trust leverage a valid certificate provides.
EV Code Signing certificates, in particular, represent a concentration of risk. The SmartScreen bypass that EV certificates confer is a powerful asset for any threat actor distributing malware. As long as legitimate companies rely on EV certificates for software distribution and support portals provide access to initialization codes, attackers will continue attempting to exploit the gap between certificate issuance workflows and endpoint security controls.
Organizations that sign software should consider hardware security module (HSM) storage for private keys, multi-person authorization for certificate issuance, and real-time monitoring of certificate order activity as baseline controls.
Conclusion
DigiCert's support portal breach and the resulting misuse of 11 stolen EV Code Signing certificates to distribute Zhong Stealer demonstrates that threat actors are increasingly targeting the issuance infrastructure of Certificate Authorities, not just the certificates themselves. Any organization that installed software signed by DigiCert-issued certificates between April 2 and April 17, 2026 — particularly binaries attributed to Lenovo, Kingston, Shuttle Inc., or Palit Microsystems — should treat those binaries as suspect until verified against DigiCert's revocation disclosure. The most urgent priority is retrospective threat hunting for Zhong Stealer activity across endpoints that may have run malware that appeared fully trusted at the time of execution.
For any query contact us at contact@cipherssecurity.com
