The DigiCert Breach: How a Screensaver File Unlocked the Internet’s Trust Infrastructure
When you install software and Windows tells you it’s from a verified publisher, you trust that. When your browser shows a padlock, you trust that too. That trust flows from certificate authorities — organisations whose entire purpose is to be the reliable, unforgeable foundation of digital identity on the internet.
In early April 2026, an attacker walked through the front door of one of the largest certificate authorities in the world using a screensaver file and a chat message. The result: 27 stolen EV Code Signing certificates issued in the names of legitimate companies, used to distribute malware to unsuspecting users who had every reason to believe the software was genuine.
This is the story of the DigiCert breach — and the chaotic Defender false positive crisis that followed.
What Is DigiCert and Why Does This Matter?
DigiCert is one of the world’s largest Certificate Authorities (CAs). It issues the TLS/SSL certificates that secure HTTPS connections, the code signing certificates that vouch for the authenticity of software, and the PKI infrastructure underlying IoT security and enterprise identity systems globally.
When DigiCert’s name appears on a certificate, it is a binding assertion to the world: this software, this website, this communication is what it says it is. That trust has real-world consequences. When that assertion is compromised, everything downstream of it is compromised too.
EV Code Signing certificates — the specific type stolen in this breach — are the highest tier of code signing credential. They require rigorous identity verification of the organisation applying for them, and they grant the holder the ability to digitally sign software in a way that Windows and other operating systems explicitly recognise as trusted. Signed software faces fewer security warnings, bypasses many application allowlisting controls, and is treated as legitimate by endpoint security tooling.
Stealing EV Code Signing certificates is not a credential theft. It is a trust theft — the ability to present malware to the world wearing the digital identity of a legitimate, verified company.
How the Attack Unfolded
April 2, 2026 — The Initial Contact
An attacker contacted DigiCert’s customer support team through the company’s standard Salesforce-based customer chat channel. Posing as a customer, they repeatedly attempted to deliver a malicious ZIP file disguised as a customer screenshot.
Inside the ZIP: a .scr file — a Windows screensaver executable. The .scr format is a classic social engineering vehicle. Windows treats screensaver files as native executables, but they carry the mundane veneer of a display settings file. When opened, they run with the same permissions as the user who clicked them.
CrowdStrike endpoint protection blocked four consecutive delivery attempts. On the fifth attempt, it succeeded. A support analyst on ENDPOINT1 executed the payload.
April 3, 2026 — Initial Containment, Incomplete Picture
DigiCert’s Trust Operations team detected the compromise on ENDPOINT1 and isolated the machine within 24 hours. The team believed the incident was contained.
It was not.
April 4, 2026 — The Second Machine
A second machine, ENDPOINT2, was also compromised through the same delivery vector — also on April 4. But unlike ENDPOINT1, it went undetected.
Why? DigiCert’s own incident report provided a frank explanation: the CrowdStrike prevention setting on ENDPOINT1 had been below the intended organisational standard at the time of initial compromise, allowing the payload to execute before blocking engaged. On ENDPOINT2, the CrowdStrike sensor was absent, degraded, or non-reporting. No detection fired.
The result: a ten-day blind spot from April 4 to April 14, during which the attacker had unrestricted, unmonitored access to a compromised support analyst’s machine and session.
April 4–14, 2026 — The Pivot Into the Support Portal
Using the compromised analyst accounts, the threat actor accessed DigiCert’s internal customer support portal and exploited a specific feature: the ability for authenticated support staff to view customer accounts from the customer’s perspective.
This feature is intentionally limited — it does not permit account management, API key access, user management, or order submission. But it does expose something critical: initialisation codes for approved but undelivered EV Code Signing certificate orders across a range of customer accounts.
The key detail here is in DigiCert’s own incident report: possession of an initialisation code, combined with an already-approved order, is sufficient to obtain and activate the resulting certificate. The attacker did not need to compromise customer accounts directly. They did not need to impersonate customers to DigiCert’s verification team. The heavy lifting of identity verification had already been done. They only needed to collect the codes that unlocked delivery — and the support portal handed those to them.
April 14–17, 2026 — Discovery, Revocation, and Damage Assessment
DigiCert discovered the ENDPOINT2 compromise on April 14 and moved quickly. Between April 14 and April 17, the company revoked 60 EV Code Signing certificates issued from four Certificate Authorities:
- DigiCert Trusted G4 Code Signing RSA4096 SHA256 2021 CA1
- DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
- GoGetSSL G4 CS RSA4096 SHA256 2022 CA-1
- Verokey High Assurance Secure Code EV
Of the 60 revoked certificates, 27 were explicitly linked to the threat actor — 11 identified through community-submitted certificate problem reports from external researchers, and 16 discovered during DigiCert’s internal investigation. The remaining 33 were revoked as a precaution where customer control of the associated certificates could not be confirmed.
DigiCert has noted it was fortunate that external security researchers spotted the abuse of its certificates and reported the issue, which is what led to the rapid discovery of the compromised accounts.
What Were the Stolen Certificates Used For?
The 27 stolen EV Code Signing certificates were used to digitally sign payloads delivering Zhong Stealer — a malware family associated with cryptocurrency theft and remote access, and linked to GoldenEyeDog (APT-Q-27), a well-documented Chinese cybercrime group. Attribution to GoldenEyeDog for the DigiCert breach itself remains unconfirmed.
Security researchers — including Squiblydoo, MalwareHunterTeam, and g0njxa — independently observed newly issued DigiCert EV certificates being used in malware campaigns and reported them to DigiCert. The certificates appeared to have been issued to and used in the name of legitimate, well-known technology companies including Lenovo, Kingston, Shuttle Inc, and Palit Microsystems.
From the perspective of a victim, software signed with an EV certificate from a recognised hardware manufacturer is about as trustworthy as software gets. Windows will display the publisher’s name during installation. Endpoint security tools will suppress or deprioritise alerts. Application allowlisting may permit execution outright. The abuse of EV Code Signing certificates in malware delivery is particularly insidious precisely because all of the trust signals point the wrong way.
Zhong Stealer is noted in some analyses to behave more like a remote access trojan (RAT) than a traditional infostealer — establishing persistent remote access rather than simply exfiltrating data and exiting. DigiCert’s own report also noted that Zhong Stealer was signed with stolen certificates from other certificate authorities beyond DigiCert, indicating this campaign is broader than a single breach.
The Microsoft Defender False Positive Crisis
While DigiCert’s breach response was underway, a secondary crisis erupted across Windows environments globally.
On April 30, 2026, Microsoft released a Defender signature update (Security Intelligence version 1.449.424.0) that added a detection for Trojan:Win32/Cerdigent.A!dha — targeting the stolen DigiCert certificates to prevent their use in further malware execution.
The detection logic was too broad.
Rather than targeting only the compromised certificates in active malware context, the rule incorrectly flagged legitimate DigiCert root certificates stored in the Windows trust store. On affected systems, Defender not only alerted on these certificates — it removed them from the AuthRoot registry key (HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\).
The impact was immediate and widespread. On May 3, 2026, reports flooded in from system administrators across Windows 11 and Windows Server environments. Without the DigiCert root certificates, browsers threw HTTPS errors on DigiCert-backed websites, applications verifying software signatures failed, and certificate-based authentication systems broke.
Critically, the persistent, un-clearable alerts caused genuine panic. Standard remediation procedures — quick scans, full scans, offline scans — did not resolve the warning, because it was not actually malware. Some administrators, seeing a high-severity Trojan alert marked as remediated and unable to clear it through normal means, reinstalled Windows entirely — destroying local data unnecessarily.
Microsoft acknowledged the issue and released a corrected update. Administrators should update to Security Intelligence version 1.449.430.0 or later, which stops the incorrect alerts and automatically restores any removed certificates. No additional manual action is required once the definitions are updated.
What Should You Do Now?
For organisations and security teams:
- Verify that all 60 revoked DigiCert EV Code Signing certificates have been propagated across your CRL (Certificate Revocation List) and OCSP infrastructure. Ensure none are trusted in internal allowlists or pinned certificate configurations.
- Check whether any software in your environment is signed with any of the revoked certificates. Treat any match as a potential indicator of compromise and investigate accordingly.
- Review endpoint protection coverage. The DigiCert breach was prolonged by a degraded/absent CrowdStrike sensor on a critical endpoint. Audit your agent deployment health and confirm prevention settings meet organisational standards across all machines — especially those handling privileged operations.
- Update Microsoft Defender definitions to version 1.449.430.0 or later if you have not already done so, to resolve the Cerdigent false positive issue and restore any removed certificates.
- Verify DigiCert root certificates are present on Windows systems. Run:
certutil -store AuthRoot | findstr /i "digicert"DigiCert Assured ID Root CA and DigiCert Trusted Root G4 should appear. If they do not, the machine was affected by the false positive removal.
For software vendors and code signing certificate holders:
- Audit your code signing certificate inventory immediately
- Review whether any of the 60 revoked certificates are in your possession or have been used in recent builds
- Contact DigiCert directly if you have received revocation notices or have concerns about certificate integrity
For all organisations — the broader lesson:
The DigiCert breach did not begin with a sophisticated zero-day or nation-state tooling. It began with a chat message and a file that looked like a screenshot. The attacker tried five times before they succeeded — four attempts blocked, one that got through because of a configuration gap on a single endpoint. That gap was the difference between a blocked attack and a ten-day unrestricted access window that compromised one of the world’s most trusted digital institutions.
The Bigger Picture
Certificate authorities occupy a unique position in internet trust architecture. They are not just another vendor to patch. When a CA’s issuance process is compromised, the damage is not contained to the CA — it propagates outward through every organisation, user, and system that trusts the certificates it has issued.
The DigiCert breach is a reminder of three compounding risks that rarely get addressed together:
Human layer vulnerabilities in high-trust environments. Support analysts with privileged access to customer data and certificate initialisation codes are high-value social engineering targets. The attacker here needed only to get one person to open one file — and they tried five times to do it.
Endpoint protection gaps undermine containment. A missing or degraded security sensor on a single machine extended a one-day incident into a ten-day breach. Agent health monitoring is not a nice-to-have on machines with privileged access.
Emergency response can create secondary crises. Microsoft’s well-intentioned attempt to block the stolen certificates in active use inadvertently disrupted systems that depended on legitimate DigiCert certificates. The speed of the response created a false positive problem that caused some administrators more disruption than the original breach. In incident response, blast radius matters.
Quick Reference
| Item | Detail |
|---|---|
| Target | DigiCert (Certificate Authority) |
| Attack Type | Social engineering via malicious screensaver (.scr) file |
| Initial Compromise | April 2, 2026 |
| Second Endpoint Compromised | April 4, 2026 |
| Discovered | April 14, 2026 |
| Blind Spot Duration | 10 days (ENDPOINT2 undetected) |
| Certificates Revoked | 60 EV Code Signing certificates |
| Certificates Linked to Attacker | 27 |
| Malware Distributed | Zhong Stealer (RAT/infostealer) |
| Suspected Threat Actor | GoldenEyeDog / APT-Q-27 (unconfirmed) |
| Secondary Incident | Microsoft Defender false positive (Trojan:Win32/Cerdigent.A!dha) |
| Defender Fix Version | Security Intelligence 1.449.430.0 |
Stay ahead of threats like this. Subscribe to our security bulletin for timely advisories, breach breakdowns, and actionable guidance.
