Topic starter
18/08/2026 2:33 pm
TL;DR: GoldenEyeDog has used code-signing certificates to bypass Windows SmartScreen and, in April 2026, leveraged a DigiCert intrusion to steal customer certificates and sign malware, according to Expel. The pattern shows how certificate lifecycle failures and support-channel compromise can turn trusted issuance into an attack path, not just a control.
Editorial analysis by NHI Mgmt Group, based on content published by Expel: “Introducing CylindricalCanine: The GoldenEyeDog subgroup responsible for the April DigiCert incident”.
Key questions
Q: What breaks when code-signing certificates are resold or reused by attackers?
A: Trusted execution breaks down because defenders and operating systems may treat malicious files as legitimate software.
Q: Why do support workflows create risk for certificate governance?
A: Support workflows create risk when they can reach certificate activation, renewal, or recovery without strong separation of duties.
Q: What signs suggest signed malware is being reused across campaigns?
A: Look for the same issuer, certificate fingerprint, or signing chain appearing across binaries that have different lures, hosts, or payload names.
Practitioner guidance
- Tighten certificate activation controls Require separate approval, device trust, and step-up verification for any certificate initialization code or signing-token activation request.
- Inventory all signing identities and renewal paths Map every code-signing certificate, renewal order, hardware token, and delegated support path to a named owner and expiration date.
- Monitor for signed malware reuse Alert on repeated use of the same signing chain, issuer, or certificate fingerprint across binaries that do not belong to your normal release process.
Bottom line: GoldenEyeDog’s campaign shows that stolen code-signing certificates can convert a trusted software identity into a malware delivery channel.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:20 pm
Certificate trust is now a machine-identity governance problem, not just a PKI problem. The article shows how a signing certificate can be transformed from proof of publisher identity into a delivery mechanism for attacker-controlled code. Once the trust anchor is stolen or abused, downstream platforms inherit that trust unless lifecycle controls catch up. Practitioners should treat certificate governance as identity governance for software supply chains.
A question worth separating out:
Q: Should teams focus on revocation or on support access first after this kind of incident?
A: Teams should do both, but support access deserves immediate scrutiny because it is often the path that exposed the certificate material in the first place. Revocation limits ongoing abuse, while support-access review shows whether the same path can be used again. If the activation or recovery workflow remains open, the compromise is not really contained.
👉 Read our full editorial: GoldenEyeDog’s DigiCert certificate theft exposes NHI trust gaps