Topic starter
18/08/2026 2:16 pm
TL;DR: The 115 certificates tracked since 2024 and the four shared between CylindricalCanine and CuboidalCanine point to deliberate separation plus a shared source of trust artefacts, Expel reports. Certificate governance has to track provenance, reuse, and revocation, not just whether a signature validates.
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: 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.
Q: What fails when code-signing certificates are reused across malware campaigns?
A: The failure is trust segregation.
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.
Glossary terms: Code Signing Certificate, Certificate provenance, Windows Defender Application Control, Certificate Revocation List
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
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