The signature was there. The trust wasn't.
DigiCert's EV certs, WebEx and Zoom installers, ViPNet's signed updater. Three subverted trust chains this week, one design assumption behind them.
Dave "Kilobaud" Ferris Three stories landed this week that read like different genres — a CA breach finally getting an attribution, a Russian-language actor pushing trojanized installers, an APT running out of a certified security product’s updater — and share only one thing: an endpoint somewhere accepted a signed artifact because it was signed, without asking anything else about it. Take them at face value and it looks like a week’s news. Read them together and it looks like a design assumption.
What broke, where
Expel’s writeup, covered here on 2026-07-18, attributed the April 2 DigiCert intrusion to CylindricalCanine — a subgroup of the Chinese cluster GoldenEyeDog — and confirmed that sixty EV code-signing certificates were fraudulently issued through it. Twenty-seven of the sixty went out and signed samples of Zhong Stealer before revocation caught up. The primitive was ordinary: a compromised support-portal analyst account, initialization codes viewable in flight through a proxied support view, no name-constraint mapping the eventual signing behavior back to the customer of record. DigiCert has honored the disclosure and shipped the fix. The audit trail said the paperwork was in order the whole time.
Cisco Talos’s UAT-11795 writeup named a financially motivated Russian-language actor pushing trojanized copies of MobaXterm, WebEx, Zoom, DBeaver, and FaceIT as first-stage carriers for the previously undocumented Starland RAT and a bespoke PowerShell C2 called WLDR. Distribution runs through NSIS installers built to look like the legitimate application; a Python loader travels as LICENSE.txt; the payload injects into svchost.exe. Talos puts the campaign at “since at least June 2025” — thirteen months in the open.
Kaspersky’s Securelist HelloNet disclosure described an unknown operator sideloading a malicious wtsapi32.dll out of the InfoTeCS ViPNet update client’s install directory since at least May. The signed vendor binary picks up the attacker’s DLL at startup, injects into svchost.exe, and stands up a Rust command-and-control implant listening on 443. The trust decision under attack was that whatever ships out of the certified-vendor install directory is part of the same certified-vendor intent.
Three actors, three victim sets, three targets, three payloads. One question at the endpoint: is this signed by someone I’ve decided to trust. Three yeses.
The signature isn’t the trust
What the endpoint inherits when it accepts a signature is narrower than what most application-control policies act like it is. A signature says one thing — that a specific bit-for-bit artifact was, at some past moment, associated with a keyholder the CA had done paperwork on. It does not say the artifact is what the customer intended to ship. It does not say the artifact will not be mutated by a later step in the delivery chain. It does not say the vendor’s product does what the artifact does. It does not say the vendor’s later behavior — dropping DLLs into an install directory, servicing an installer download over HTTPS, publishing a package to a registry — will not be subverted while the signature continues to hold.
Three ways this week to teach an audit trail the wrong lesson: get the CA to sign for you (CylindricalCanine), sign it yourself and get a user to run it (UAT-11795), or don’t touch the signature at all and let the signed process load your unsigned file (HelloNet). The first breaks the certificate. The second breaks the download source. The third leaves the certificate untouched and breaks the search path. The endpoint accepts all three because it is asking the wrong question.
The historical parallels are not fresh. In 2010, Stuxnet shipped drivers signed with stolen keys from Realtek and JMicron. In 2013, Bit9 lost private signing infrastructure to attackers who then signed their own tools with it. In 2017, a backdoored CCleaner installer went out to more than two million users under Piriform’s own valid signature. None of those cost anyone their signature. All of them cost customers something they thought the signature was protecting. Sixteen years is a long time for a design assumption to sit still.
The generalizable line
Application-control policies that bind allowlisting to publisher CN, and endpoint controls that treat “signed” as a discrete state rather than one property among many, are how campaigns like these run for months in the open. The DigiCert incident is the one to point at when the argument goes: if a compromised support analyst can read an in-flight initialization code out of a supposedly gapped portal, then the certificate that CA issued binds a public name to a supply chain the CA does not see the end of. The ViPNet incident is the one to point at when the argument goes: a signed vendor process loading a lower-privileged local file into a SYSTEM host is a defect in the process’s design, not just a defense-in-depth opportunity for the customer. The trojanized-installer incident is the one to point at when the argument goes: the download source belongs in the trust decision, and no signature on a file pulled down from web-devtools[.]com should have gotten anywhere near the allowlist.
None of the three campaigns needed a novel technique. What they needed was a defender whose model of trust ended at the signature — and the defender was there for all three.
The signature is a data point. The endpoint has to do the rest of the work.
Related coverage
Found this useful? Share it.
