Topic starter
18/08/2026 2:16 pm
TL;DR: GoldenEyeDog’s subgroups increasingly rely on code-signing certificates, with 115 certificates tracked since 2024 and only four shared between the two tracked clusters, showing both deliberate separation and a common reseller market that can contaminate multiple malware families, according to Expel. The governance problem is not just malicious signing, but weak certificate lifecycle control across purchase, issuance, reuse, and revocation.
Editorial analysis by NHI Mgmt Group, based on content published by Expel: “Reading the certificate leaves: Understanding GoldenEyeDog’s teams—CylindricalCanine and CuboidalCanine—through code-signing certificates”.
Key questions
Q: What fails when code-signing certificates are reused across malware campaigns?
A: The failure is trust segregation.
Q: Why do code-signing certificates matter in malware campaigns?
A: Code-signing certificates influence whether operating systems and users trust a file, so attackers use them to lower suspicion and extend dwell time.
Q: How can security teams tell whether certificate trust controls are failing?
A: Look for the same organisation name, signer, or serial number appearing across unrelated binaries, campaigns, or malware families.
Practitioner guidance
- Audit certificate provenance across your software trust stack Inventory signers, serial numbers, issuers, and first-seen dates for all code-signing certificates that your endpoints trust.
- Block abused signers with explicit deny controls Use Windows Defender Application Control or an equivalent policy layer to deny certificates known to be abused, rather than relying on permissive allow-by-signature behaviour.
- Tie revocation checks to deployment decisions Require revocation status and trust evaluation before software reaches production endpoints, and treat delayed revocation as an exposure window.
Bottom line: Code-signing abuse becomes a governance problem when trusted certificates are reused, resold, or intercepted across multiple malware campaigns.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:07 pm
Code-signing certificates are machine identities, and this article shows what happens when they are traded like commodities. The trust value of a certificate depends on ownership, exclusivity, and revocation discipline, not simply on cryptographic validity. Once reseller markets enter the picture, a certificate can be simultaneously a signature and a reusable access token for malware distribution. Practitioners should treat certificate lifecycle governance as part of identity security, not as a narrow PKI administration task.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should own code-signing certificate governance in the organisation?
A: Ownership should sit jointly with identity, security, and release engineering, because code signing affects trust, access, and software delivery at the same time. A single technical owner is rarely enough. The accountable team must define renewal policy, approve key handling, and ensure revocation can happen without delay.
👉 Read our full editorial: Code-signing certificate abuse in GoldenEyeDog exposes supply-chain reuse