DigiCert Revokes 60 Code Signing Certificates After Support Malware Incident

DigiCert revoked 60 code signing certificates after a malware incident involving its customer support team gave an attacker access to initialization codes for pending EV code signing certificate orders.

The incident was disclosed in Mozilla’s CA compliance tracker as Bug 2033170. DigiCert said a threat actor contacted its support team through a customer chat channel on April 2, 2026 and sent a ZIP file disguised as a customer screenshot. Inside the ZIP was a .scr file, which is an executable on Windows.

CrowdStrike and other security controls blocked four delivery attempts. The fifth attempt compromised a machine used by a DigiCert support analyst. DigiCert detected and contained that machine on April 3 and initially believed the incident had been handled.

The investigation changed on April 14, when DigiCert identified a second compromised support analyst machine. That second machine had been infected through the same support-chat file delivery path on April 4. DigiCert later said CrowdStrike was not installed on that endpoint, which meant the earlier investigation missed it.

That second machine is where the incident became much more serious.

DigiCert said the attacker used the compromised analyst endpoint to access an internal support portal. The portal allowed support analysts to view customer accounts from the customer’s perspective for support tasks. DigiCert said the access was limited and did not allow the attacker to manage users, API keys, accounts, or orders.

It did allow access to initialization codes for approved but not-yet-delivered EV code signing certificate orders.

That detail matters because DigiCert said possession of an initialization code, combined with an approved order, was enough to obtain the resulting certificate. The attacker did not need to break DigiCert’s certificate authority infrastructure or steal a root key. The attacker used a support workflow that exposed a credential-like value inside the customer support environment.

DigiCert revoked 60 code signing certificates during the investigation. Of those, 27 were explicitly linked to the threat actor. Eleven had been identified through certificate problem reports submitted by community members linking the certificates to malware, while 16 more were identified during DigiCert’s own investigation. The remaining 33 were revoked as a precaution because DigiCert could not explicitly confirm customer control.

The abused certificates were found signing Zhong Stealer malware.

This is why the incident is more serious than a normal helpdesk malware infection. Code signing certificates are used to make software appear trusted. When attackers get valid certificates, they can sign malware in a way that may help it bypass warnings, look more legitimate to victims, and survive longer before being blocked or distrusted.

DigiCert said all identified certificates were revoked within 24 hours of discovery, with the revocation date set to their date of issuance. Pending orders in the affected window were also cancelled, and initialization codes were masked from proxied support sessions through both the portal and API.

The report also lays out several failures that made the incident possible.

File controls on the customer support chat channel and Salesforce case attachment workflow allowed high-risk attachments to reach support staff. DigiCert said the support chat channel had not been adequately evaluated as a malware delivery path against CA support personnel.

Endpoint detection coverage was also incomplete. The first compromised machine triggered CrowdStrike detections and was contained quickly. The second compromised machine did not have CrowdStrike installed, creating a blind spot that lasted until the expanded investigation on April 14.

The third problem was how DigiCert treated initialization codes. The workflow assumed those codes would only be available to validated subscribers and entered into DigiCert’s Hardware Certificate Installer. The threat model did not account for a compromised support analyst viewing those codes inside DigiCert’s own portal. DigiCert said the codes had been treated as intermediate workflow data rather than bearer credentials.

That is the central lesson in the report. A support tool does not need direct access to a CA signing system to become dangerous. If it exposes values that can lead to certificate issuance, it needs to be treated like privileged infrastructure.

DigiCert’s own “what didn’t go well” section is blunt. File-type controls were insufficient, EDR coverage was incomplete, initialization codes were not protected as bearer credentials, and Okta FastPass allowed a compromised device to satisfy authentication requirements for sensitive support-portal access.

DigiCert also said it got lucky. A community member noticed the pattern of misused certificates and reported it. Without that outside report, DigiCert said the undetected compromise of the second endpoint and the related certificate misissuance may have remained undiscovered for longer.

There is no indication in DigiCert’s report that the attacker misused non-code-signing certificate workflows, changed account settings, managed customer users, or compromised broader CA systems. The company said the activity it found was focused on code signing initialization codes within specific customer accounts.

Even with that limitation, the incident shows how fragile certificate trust can become when support workflows are not treated with the same seriousness as core CA infrastructure. A malicious file sent through a normal support channel, one missed endpoint, and exposed initialization codes were enough to produce valid certificates later tied to malware.