Notifications
Clear all
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.
NHIMG editorial — based on content published by Expel: GoldenEyeDog certificate abuse and subgroup analysis
By the numbers:
- Since 2024, Expel says it has identified 115 code-signing certificates attributed to the GoldenEyeDog actor group.
- Expel says 2,616 files were signed with the 115 certificates used by CylindricalCanine and CuboidalCanine.
Questions worth separating out
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 abused signing certificates create a machine identity risk?
A: A signing certificate is a non-human identity with authority to establish trust for code.
Q: How can security teams know whether certificate trust is still reliable?
A: Look for serial reuse, signer reuse across unrelated malware families, and signed files that appear shortly before expiry or after unusual issuance patterns.
Practitioner guidance
- Inventory signing certificates as governed credentials Track every code-signing certificate by owner, issuer, serial number, intended use, and revocation trigger so you can distinguish legitimate signing from reused or resold trust material.
- Block known-bad signers and to-be-signed hashes Use Windows Defender Application Control to deny files signed by abused certificates and, where possible, block files by to-be-signed hashes so the same trust object cannot keep reappearing under new payload names.
- Hunt for signer reuse across malware families Correlate certificate signer names, serial numbers, and issuance patterns across detections to spot reseller contamination and shared trust sources.
What's in the full article
Expel's full analysis covers the operational detail this post intentionally leaves for the source:
- Certificate-by-certificate overlap tables showing which signer names and serial numbers connect the two GoldenEyeDog subgroups
- Malware-family mapping for the 115 identified certificates, including how 77 and 38 certificates split across the two loader families
- Recommended Windows Defender Application Control approaches for blocking abusive signed files and known-bad TBS hashes
- IOC listings that tie the abused certificates to 2,616 files in VirusTotal
👉 Read Expel's analysis of GoldenEyeDog code-signing certificate abuse →
Code-signing certificate abuse in GoldenEyeDog: what IAM teams should note?
Explore further
18/08/2026 3:07 pm
Code-signing certificate abuse is a machine-identity governance failure. The article shows that the core issue is not simply malware delivery, but the uncontrolled movement of signing credentials across actors, campaigns, and resellers. That is a lifecycle problem with a trust object that carries more authority than many teams realise. For practitioners, certificate governance should be treated as part of identity governance, not just application security.
A question worth separating out:
Q: Who is accountable when an abused code-signing certificate enables malware delivery?
A: Accountability usually spans the certificate owner, the issuing chain, the reseller or intermediary if one exists, and the internal teams responsible for revocation and software trust policy. Frameworks such as NIST CSF and ISO 27001 expect organisations to manage trust credentials with defined ownership and control, not ambiguity.
👉 Read our full editorial: Code-signing certificate abuse in GoldenEyeDog exposes supply-chain reuse
