Code-signing certificate abuse in GoldenEyeDog exposes supply-chain reuse

At a glance

What this is: This is an analysis of GoldenEyeDog’s use of abused code-signing certificates to sign malware, with the key finding that separate subgroups still draw from overlapping certificate sources.

Why it matters: It matters because certificate abuse is an NHI governance problem as much as a malware problem: if trusted signing material can be resold, reused, or delayed in revocation, application trust decisions become attacker-controlled.

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.

👉 Read Expel's analysis of GoldenEyeDog code-signing certificate abuse

Context

Code-signing certificates are intended to support software trust, but in criminal hands they become reusable identity material for malware distribution. When those certificates are resold or reused across campaigns, defenders inherit a problem that looks like application integrity but behaves like non-human identity abuse: a trusted signing identity is being used outside its intended lifecycle.

Expel’s analysis shows two related clusters within GoldenEyeDog that mostly keep separate signing material but still draw from a common supply chain. That pattern is typical of certificate-abuse ecosystems, where the key governance issue is not only the malicious payload, but the control gap between certificate issuance, resale, and timely revocation. The intersection with IAM is real because trust decisions are being made on the basis of a machine-held credential.

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. Once a signing certificate is reused across multiple campaigns, the certificate no longer proves provenance in a meaningful way. Teams need ownership, exclusivity, and revocation processes so trust does not become an attacker-controlled shortcut.

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. If that identity is stolen, sold, or shared outside its intended lifecycle, it can authorize malicious software just as an over-privileged service account can authorize harmful actions. The governance failure is the lack of lifecycle control around the credential.

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. Reliable trust depends on provenance, custody, and revocation speed, not on whether a certificate is technically valid at the moment it is seen.

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.

Technical breakdown

Why code-signing certificates function like high-trust machine identities

A code-signing certificate is a cryptographic identity that tells operating systems and security tools a file comes from a trusted signer. In practice, that trust can override user warnings, SmartScreen prompts, and other reputation checks, especially when the file is signed and the environment is permissive. That makes the certificate itself a valuable abuse target, not just a protection mechanism. When attackers buy, steal, or reuse certificates, they inherit the reputation of a legitimate signer and can distribute malware that looks less suspicious to endpoint controls. Practical implication: treat signing certificates as governed credentials, not as static procurement artefacts.

Practical implication: inventory signing certificates, restrict who can obtain them, and tie each certificate to an explicit owner, purpose, and revocation path.

How certificate resale creates cross-campaign trust contamination

The article describes a reseller ecosystem where the same organisation name, issuer, or even serial number can appear across multiple malware families. That means the trust boundary is not the vendor or certificate authority alone, but the chain of custody after issuance. Once a certificate is resold or copied into multiple operations, revocation becomes more complex because defenders may see the same signing identity attached to unrelated malicious activity. This is why certificate provenance matters as much as certificate validity. Practical implication: build detection and block decisions around signer reputation, serial reuse, and known-bad TBS hashes rather than trusting certificate presence alone.

Practical implication: monitor signer reuse across malware families and use blocklists that account for serial number duplication and to-be-signed hashes.

Why code-signing abuse is an identity governance problem, not only an endpoint problem

Code-signing certificates are machine identities with lifecycle, custody, and authorization boundaries. If they are obtained through weak vetting, resold, or left valid after misuse, the organisation has effectively allowed a privileged trust credential to drift beyond governance. That is structurally similar to unmanaged non-human identities elsewhere in the enterprise, where a credential exists, has power, but lacks lifecycle oversight. The result is not just malicious code execution, but a weakened trust model for software distribution. Practical implication: align certificate governance with identity lifecycle controls such as ownership, review, rotation, and revocation triggers.

Practical implication: apply lifecycle management, approval workflows, and revocation SLAs to signing certificates the same way you would to other high-risk credentials.

Threat narrative

Attacker objective: The attacker wants trusted execution of malware that blends into legitimate software distribution and expands the reach of the payload.

1. Entry occurs when attackers obtain or reuse a code-signing certificate from a reseller or compromised source and use it to sign malware that can pass trust checks.
2. Escalation happens when signed malware bypasses user warnings and security prompts, allowing the payload to execute with greater credibility on victim systems.
3. Impact follows when the signed loader delivers Gh0st RAT, ValleyRAT, or related payloads that support persistence, command execution, and broader compromise.

NHI Mgmt Group analysis

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.

Cross-campaign certificate reuse creates a trust contamination layer that defenders often miss. When the same signer, issuer, or serial appears across unrelated malware families, the certificate stops being a provenance signal and becomes an attack substrate. That undermines trust decisions in endpoint and application control systems and raises the value of provenance-aware blocking. For practitioners, reputation, serial analysis, and signer lineage need to sit alongside allowlists.

The named concept here is certificate trust contamination: a signing identity reused across multiple malicious operations until trust itself becomes unreliable. This is not a theoretical edge case, because the article shows both shared certificate sources and limited but real overlap between subgroups. The practical consequence is that certificate validity alone is no longer evidence of legitimacy. For practitioners, trust models must include custody, exclusivity, and revocation speed.

WDAC-style enforcement becomes more important when signed malware is part of the threat model. The article’s recommendation to block unsigned and known-bad signed files reflects a broader point: permissive trust settings turn certificates into a bypass mechanism. Endpoint controls only work when signing trust is bounded by policy, not assumed by default. For practitioners, application control must be paired with explicit bad-signature blocking and exception governance.

Shared certificate sourcing suggests a wider criminal credential market that cuts across language, geography, and malware families. The overlap with Russian and Chinese crimeware shows that signing certificates are traded as commodity trust objects. That means certificate abuse should be monitored as a supply-chain security issue, not only a malware IOC problem. For practitioners, threat hunting must extend to signer ecosystems, not just payload hashes.

What this signals

Certificate abuse behaves like identity drift for software trust. Once a signing credential can be resold or reused, its assurance value depends less on cryptography than on lifecycle governance, ownership, and revocation discipline. That is why machine identity control should be treated as an operational control plane, not a procurement record.

Certificate trust contamination: when the same signer appears across unrelated malicious campaigns, the trust signal itself becomes suspect. Teams that already manage workload identity and secrets rotation should extend the same governance logic to signing credentials, with explicit ownership and rapid revocation thresholds.

For practitioners, the next step is to connect endpoint enforcement with identity inventory and provenance analysis. Map signed binaries to known issuers, flag duplicate serials, and use application control policies in line with CIS Controls v8 and NIST SP 800-53 Rev 5 Security and Privacy Controls.

For practitioners

• 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. Link the inventory to application ownership and certificate lifecycle review.
• 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. The same signer appearing in multiple unrelated samples is a signal to investigate the certificate supply chain.
• Set revocation SLAs for abused signing credentials Define how quickly a compromised or abused certificate must be revoked, then test that process against detection and legal approval steps. Slow revocation leaves a trusted credential usable long after misuse is known.

Key takeaways

• Code-signing certificates are a machine-identity problem when attackers can buy, reuse, or resell them across campaigns.
• The article’s 115 tracked certificates and 2,616 signed files show how quickly trust material can scale into a broad abuse surface.
• The control gap is lifecycle governance, so ownership, revocation speed, and signer-based blocking matter more than certificate validity alone.

Key terms

• Code Signing Certificate: A code signing certificate is a digital credential used to prove that software came from a trusted publisher and has not been altered. In identity terms, it is a non-human identity that authorizes release activity, and its value depends on lifecycle control, key custody, and revocation discipline.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
• Application control: Application control is the enforcement of which software may run on a device and under what conditions. It is a key governance layer because unauthorized or unsafe code can undermine access assurance even when authentication and device enrolment are in place.

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

👉 Expel's full post covers the certificate overlap tables, malware-family mapping, and WDAC guidance.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It gives practitioners a structured way to govern high-risk credentials across identity and security programmes.