Expel: GoldenEyeDog stole 27 EV certs from DigiCert

The April 2 DigiCert incident is finally attributed. Per Expel’s writeup as summarized by The Hacker News, the intrusion belongs to CylindricalCanine, a subgroup of the Chinese cluster tracked as GoldenEyeDog / APT-Q-27. Sixty fraudulently issued EV code-signing certificates got revoked. Twenty-seven of them were used to sign Zhong Stealer.

That last number is the one that matters. This wasn’t hypothetical trust compromise. Twenty-seven certificates from a public CA went out and signed malware in the wild before the revocation caught up. If your endpoint controls trust code-signing signatures — and most do, that’s the whole point of EV — every one of those artifacts had a green checkmark on the way in.

What Expel says happened

Per the writeup, the operator delivered a malicious .scr file dressed as a screenshot through DigiCert’s customer support chat on April 2, 2026. A support analyst opened it. From there the interesting bit is the design flaw, not the phish: initialization codes for EV cert issuance were viewable by a compromised analyst account through the support portal proxy. DigiCert’s own quote from its Mozilla disclosure is honest about it — “the threat model did not account for the scenario in which initialization codes … could be viewed by a compromised DigiCert analyst account.”

That’s the primitive. The actor could pull the init code for a customer request in flight and stand up a matched signing cert on the customer’s own account. No name-constraint on the accounts meant nothing checked whether the actor’s later signing behavior matched the legitimate customer. The audit didn’t fire because the paperwork looked right.

DigiCert has since deployed code changes on both the U.S. and E.U. platforms that mask initialization codes from proxied support portal views over both UI and API. Reasonable fix. Should have been the design.

Zhong Stealer, and the harder lesson

Of the sixty revoked certificates, twenty-seven map directly to Zhong Stealer samples. Related loader activity for this cluster was documented as far back as November 2025, and Web3 targeting from the same actor surfaced in March 2026 — this crew was operating for months before the April intrusion, and they knew what they wanted out of a CA compromise: signed loaders that endpoint tools wouldn’t flag on trust.

Analysis: signed-malware campaigns don’t need a big-CA breach to work. Attackers regularly stand up their own limited-issuance certs or buy leftovers on the market. What a CylindricalCanine-style compromise gets you is bulk plus reputation. Twenty-seven certs, all traceable to a name-brand issuer, with real customer accounts backing them. That’s a different tier of trust to burn.

What to actually do

Priority order:

1. Pull the DigiCert revocation list and cross-check it against signing certificates observed in your environment over the last 90 days. Not just installed roots — actual code you allowed to run because it was signed. If you can’t get that from your EDR, that’s the gap. Fix it.
2. 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 of abuse. Tune the volume down by thumbprint allowlisting for publishers you actually consume.
3. Do not rely on publisher name alone in application-control policy. Bind allowlists to specific cert thumbprints, not “signed by anyone whose CN matches X.” That’s the design flaw the abuse rides on.
4. Ask your CAs the boring question: what’s their support-portal threat model? Not the pen test, not the SOC 2. Ask whether a compromised support analyst can read customer initialization data in flight. DigiCert’s answer, to their credit, is now no. Others’ answers, largely, are still yes.

Revocation is not detection. If a signed artifact landed on your box in March, the revocation list posted in April doesn’t stop it from being on your box. You have to go look.