Virtual Round Table · Jul 22

View the event
DigiCert Support Portal Breach Exposes Code-Signing Trust, 27 Certificates Tied to Chinese Group
Cybersecurity

DigiCert Support Portal Breach Exposes Code-Signing Trust, 27 Certificates Tied to Chinese Group

Attackers used a poisoned customer-chat attachment to compromise DigiCert analyst workstations and walk away with code-signing certificates later used to sign malware.

PublishedJuly 19, 2026
Read time6 min read
Share

How the intrusion started

The breach began where enterprises rarely look for one, in the customer support channel. According to analysis from security firm Expel, on April 2 threat actors delivered a malicious ZIP file disguised as a customer screenshot through DigiCert's support chat. Inside was a screensaver executable with the .scr extension, a decades-old lure that still works because a support analyst under time pressure is conditioned to open what a customer sends. That single attachment gave the attackers access to two analyst workstations. From there they leveraged the trusted position those support staff hold to reach the certificate machinery that is DigiCert's entire reason for existing.

The tradecraft is a reminder that social engineering aimed at support and help-desk teams remains one of the most reliable paths into a hardened organization. Support analysts exist to be helpful, they handle unpredictable inbound content all day, and their tooling often grants broad internal reach so they can resolve customer problems quickly. That combination makes them a high-value target. DigiCert is a mature security company, and the intrusion still succeeded through a human-facing channel rather than a technical flaw in the signing systems. The lesson generalizes to any enterprise: the people paid to open messages from strangers are a frontline that deserves frontline defenses.

What the attackers took

The payoff was code-signing certificates. In response to the incident, 60 certificates were revoked, with 27 explicitly tied to the threat actor. Those fraudulently obtained Extended Validation code-signing certificates were then weaponized to sign the Zhong Stealer malware. That final step is what makes this breach dangerous well beyond DigiCert itself. A code-signing certificate is a statement of trust, the digital seal that operating systems, security tools, and users check to decide whether a piece of software is safe to run. Malware signed with a legitimate EV certificate sails past many of the reputation and warning systems that would otherwise flag an unknown binary and give a user pause.

Extended Validation certificates carry extra weight precisely because they are supposed to be hard to obtain, requiring vetting that ordinary certificates skip. That elevated trust becomes a liability once the certificates are stolen, because defenses tuned to treat EV-signed code as more trustworthy now extend that benefit of the doubt to the attacker's malware. Revocation helps, yet it is imperfect in practice. Not every system checks revocation status reliably, offline and air-gapped environments may never receive the update, and any malware that executed while the certificates were still valid has already done its work. The window between issuance and revocation is where the damage concentrates.

The group behind it

Expel attributed the DigiCert intrusion to CylindricalCanine, which it identifies as a subgroup of GoldenEyeDog, a Chinese cybercrime cluster also tracked under names including APT-Q-27, Dragon Breath, and the Miutti Group. The broader group has been active since 2015 and has historically concentrated on the gambling and gaming sectors. Aaron Walton, a security researcher at Expel, summarized the mechanics plainly, saying the group used their malware to access a support member's device at DigiCert and leveraged that access to steal certificates. Mozilla's Bugzilla report corroborated the certificate revocations, giving the account grounding in the public certificate-transparency ecosystem rather than resting on a single vendor's telling.

Attribution to a long-running, financially motivated Chinese group matters for how enterprises weigh the threat. This is not a one-off smash-and-grab. Groups with a decade of operational history refine their techniques, reuse infrastructure, and rotate through targets that offer leverage. A certificate authority is an exceptionally high-leverage target because a single successful theft yields signing capability that can be used against countless downstream victims who have never interacted with the CA at all. The Zhong Stealer campaign is the immediate expression of that leverage, and it is reasonable to expect the same playbook aimed at other providers in the trust supply chain.

Why code-signing trust is fragile

Code signing is one of the load-bearing trust mechanisms of modern computing, and this breach exposes how much of that trust rests on the security of the issuers and their staff. Enterprises treat a valid signature as strong evidence of legitimacy, wiring that assumption into allowlists, deployment pipelines, and endpoint policies. When an attacker can obtain genuine certificates through a support-desk compromise, the signature stops being reliable evidence of anything. The trust model does not fail loudly. It quietly certifies the attacker's code as safe, which is the worst kind of failure because the systems built to catch malware actively wave it through.

This is the same structural weakness that has driven a run of supply-chain incidents across the industry, from poisoned package registries to compromised build pipelines. Each one exploits a point of implicit trust that defenders had stopped questioning. Code-signing certificates belong on that list of trust anchors that require active verification rather than passive faith. Enterprises that consume signed software, which is effectively all of them, cannot audit every CA's internal controls, so the defensive burden shifts toward monitoring signing behavior, watching for anomalous use of certificates, and refusing to treat a valid signature as the end of the security conversation.

Practical guidance for enterprises

For organizations that issue their own signed software, the DigiCert breach is an argument for locking down signing infrastructure with the same rigor applied to production secrets. Private keys belong in hardware security modules or a managed signing service, signing operations should require multiple approvals, and certificate issuance and use should be logged and monitored for anomalies. Support and help-desk teams need dedicated phishing defenses, tightly scoped tooling that limits blast radius, and hardened endpoints, since this intrusion proves that channel is a live target. Treating the support desk as a security-critical function rather than a cost center is the uncomfortable but correct conclusion.

For everyone consuming signed software, the guidance is to stop treating a valid signature as a clean bill of health. Behavioral detection, application control that considers reputation and context alongside the signature, and prompt attention to revocation feeds all reduce the odds that stolen-certificate malware slips through. Where feasible, verify the specific expected publisher of signed code rather than accepting any valid signature as sufficient. The overarching message for CTOs and CISOs is that trust in the software supply chain is earned continuously through verification, and any single point of implicit trust, including a certificate authority's support portal, is a point that a capable adversary will eventually pry open.

Tagged#news#security#cybersecurity#breach#cisa#ransomware#zero-day#supply-chain#ai-security#digicert#code-signing#goldeneyedog#cylindricalcanine#zhong-stealer#certificate-authority