Expel: GoldenEyeDog stole 27 EV certs from DigiCert
Expel says the April DigiCert breach was CylindricalCanine, a GoldenEyeDog subgroup. Twenty-seven of 60 revoked EV certs signed Zhong Stealer artifacts.
Marisol "Fuse" Delgado Sixty EV code-signing certs revoked. Twenty-seven of them used to sign Zhong Stealer. That’s the DigiCert April breach, and Expel finally attributed it this week to CylindricalCanine, a subgroup of the Chinese cluster tracked as GoldenEyeDog / APT-Q-27.
Twenty-seven is the number that matters. Not “hypothetical trust compromise.” Twenty-seven certificates from a public CA went out and signed real malware in the wild. If your endpoint controls trust code-signing signatures — the entire reason EV exists — every one of those artifacts had a green checkmark on the way in.
The design flaw
Skip the phish for a second. The .scr-through-support-chat delivery on April 2, 2026 is boring; a support analyst opened a file, and the workstation went. What’s not boring is what the actor could reach from there.
Initialization codes for EV cert issuance were viewable by a compromised analyst account through the support portal proxy. DigiCert’s own Mozilla disclosure says it plainly: “the threat model did not account for the scenario in which initialization codes … could be viewed by a compromised DigiCert analyst account.”
Translation: pull the init code for a customer request in flight, stand up a matched signing cert on the customer’s own account. No name-constraint on the accounts. Nothing checked whether later signing behavior matched the legitimate customer. Audit didn’t fire because the paperwork looked right.
DigiCert has since masked initialization codes from proxied support portal views over UI and API on both platforms. Fine. Should have been the design.
Analysis: why bother with a CA at all
Signed-malware crews don’t need to burn a big-CA relationship. They stand up their own limited-issuance certs, or buy leftovers. What a DigiCert-tier compromise gets you is bulk plus reputation — twenty-seven certs, name-brand issuer, real customer accounts behind them. Different tier of trust to burn, and it burns exactly once.
Related loader activity for this cluster was documented in November 2025, Web3 targeting in March 2026. They ran for months before pulling the CA trigger. They knew what they wanted.
What to actually do
Priority order:
- Pull the DigiCert revocation list and cross-check it against signing certificates observed in your environment over the last 90 days. Not installed roots — actual code you allowed to run because it was signed. If your EDR can’t answer that, that’s the gap. Fix it.
- Alert on newly-issued EV code-signing certs appearing in your fleet for the first time. First-seen certificates from a legitimate issuer are the noisy but honest detection for this class. Tune the volume with thumbprint allowlisting for publishers you actually consume.
- Don’t allowlist by publisher name. Bind to specific cert thumbprints. “Signed by anyone whose CN matches X” is the design the abuse rides on. Kill it.
- Ask your CAs one boring question: can a compromised support analyst read customer initialization data in flight? Not the pen test. Not the SOC 2. That question. DigiCert’s answer, to their credit, is now no. Most of the rest is still yes.
Revocation is not detection. If a signed artifact hit your box in March, an April revocation list doesn’t unrun it. You go look.
Found this useful? Share it.
