DigiCert breach exposed EV code signing certificates used to sign Zhong Stealer malware

DigiCert revoked 60 EV code signing certificates after a social engineering attack gave a threat actor access to internal support tools and certificate initialization codes.

The attack began when someone posing as a customer sent DigiCert support staff a malicious ZIP file disguised as a screenshot. The file contained a .scr screensaver executable, which Windows treats as a program.

The incident is serious because code signing certificates help software look trusted. If attackers sign malware with a legitimate certificate, security tools and users may treat the file as safer than it really is.

What happened at DigiCert

On April 2, 2026, a threat actor contacted DigiCert’s support team through a customer chat channel and sent a malicious file attachment. DigiCert said several delivery attempts were blocked, but one attempt compromised a support analyst’s computer.

DigiCert detected and contained the first compromised endpoint on April 3. The company initially believed the incident had been contained based on the telemetry available at the time.

A second support analyst machine had also been compromised on April 4 through the same delivery path. DigiCert later found that this endpoint did not have CrowdStrike installed or configured, so the compromise was not detected during the first investigation.

At a glance

Item	Details
Company affected	DigiCert
Attack method	Social engineering through support chat
Malicious file	.scr executable inside a ZIP archive
Main asset exposed	EV code signing certificate initialization codes
Total certificates revoked	60
Certificates linked to attacker activity	27
Malware linked to signed files	Zhong Stealer
Final identified certificate revoked	April 17, 2026

How the attacker reached certificate data

The attacker used the compromised analyst access to enter DigiCert’s internal support portal. DigiCert said the portal includes a support function that lets authenticated analysts view customer accounts from the customer’s perspective.

That support view did not allow the attacker to manage accounts, change users, access API keys, or submit certificate orders. However, it did expose initialization codes for approved but not yet delivered EV code signing certificate orders.

DigiCert said an initialization code, when combined with an approved order, is enough to obtain the resulting certificate. That gave the attacker a path to valid EV code signing certificates across a limited set of customer accounts and certificate authorities.

Certificates were used to sign malware

DigiCert revoked 60 certificates during the investigation between April 14 and April 17. The certificates came from four certificate authorities, including DigiCert Trusted G4 Code Signing, GoGetSSL, and Verokey high-assurance code signing chains.

Of those 60 certificates, 27 were directly linked to attacker activity. Eleven were found through community certificate problem reports, while 16 were discovered during DigiCert’s internal investigation.

The remaining 33 certificates were revoked as a precaution because DigiCert could not fully confirm customer control. Security reporting also linked some of the abused certificates to payloads delivering Zhong Stealer malware.

Why code signing abuse matters

Code signing does not prove that software is safe. It proves that a file was signed with a certificate tied to a trusted identity.

Attackers want valid code signing certificates because signed malware can appear more legitimate. This can help malicious files bypass reputation checks, reduce user suspicion, and complicate detection.

EV code signing certificates carry even higher trust expectations because they require stronger identity validation and controlled issuance processes. That is why misuse of EV certificates creates concern across the software supply chain.

Timeline of the incident

Date	Event
April 2, 2026	Threat actor sent malicious ZIP file through support chat
April 3, 2026	First compromised endpoint was detected and contained
April 4, 2026	Second endpoint showed unauthorized activity
April 5, 2026	DigiCert received the first third-party certificate problem report tied to the incident
April 14, 2026	DigiCert expanded the investigation and identified the second compromised endpoint
April 14 and 15, 2026	DigiCert deployed changes to block support-proxied access to initialization codes
April 17, 2026	Final identified certificate was revoked

What DigiCert changed after the breach

DigiCert said it blocked proxied support users from viewing code signing initialization codes at both the user interface and API layers. The company deployed those changes across its U.S. and EU environments.

The company also disabled Okta FastPass for the support portal and related applications, tightened MFA requirements for affected administrative workflows, and suspended or deactivated accounts tied to the compromised endpoints.

DigiCert also began restricting the file types that can be sent through support chat and Salesforce case attachments. That matters because the original attack path relied on sending executable content through a customer support workflow.

What organizations should check now

• Confirm that the 60 revoked certificates no longer appear in internal allowlists.
• Check whether internal tools still trust any affected certificates through pinning or custom rules.
• Verify that CRL and OCSP checks work correctly across endpoint, proxy, and build systems.
• Search for signed Zhong Stealer payloads in endpoint and malware telemetry.
• Review code signing validation logs for certificates issued through affected DigiCert chains.
• Harden customer support file intake workflows against executable attachments.
• Require EDR health checks on privileged support endpoints.
• Review support portal features that expose sensitive customer secrets or issuance codes.

Impact for software supply chain security

The DigiCert incident shows how certificate abuse can start outside a software build system. A support workflow, a file attachment, and a missing endpoint control were enough to expose sensitive certificate issuance material.

The incident also shows why revocation speed matters. DigiCert said the affected certificates were revoked during the investigation, and the final identified certificate was revoked on April 17.

For enterprises, the bigger lesson is that trusted software controls depend on more than certificate policy. They also depend on endpoint security, support portal design, file intake controls, monitoring, and fast certificate problem reporting from the wider security community.

FAQ