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

At a glance

What this is: Expel’s analysis shows GoldenEyeDog subgroups using code-signing certificates as an operational control for malware delivery, while limited overlap suggests both deliberate separation and a shared reseller market.

Why it matters: IAM, PKI, and endpoint teams need to treat certificate governance as an abuse surface, because signed malware can bypass trust decisions when certificate lifecycle controls and revocation discipline are weak.

Context

Code-signing certificates are meant to establish trust in software distribution, but they can be repurposed as an attacker-controlled reputation layer when issuance, resale, and revocation are weak. In this case, the relevant governance problem is not just malware signing. It is the reuse of trusted certificates across multiple campaigns, which turns PKI hygiene into a supply-chain resilience issue with direct implications for identity and access governance around certificates as machine credentials.

GoldenEyeDog’s subgroup behaviour shows why certificate control cannot be treated as a one-time procurement decision. When different crews share the same signer, serial, or reseller source, defenders lose a clean boundary between legitimate issuance and malicious reuse. That makes certificate lifecycle management, revocation speed, and trust-store policy part of the operational control set for security teams that manage Windows endpoints, software distribution, and non-human credential risk.

Key questions

Q: What fails when code-signing certificates are reused across malware campaigns?

A: The failure is trust segregation. When the same certificate signer, serial, or reseller source appears in multiple campaigns, defenders cannot rely on signature alone to distinguish legitimate software from malicious binaries. The control gap is weak certificate provenance and slow revocation, which lets the same trust artefact keep working after it has been abused.

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. When certificates are reused, rotated quickly, or abused through a signing service, they become a trust token that supports delivery at scale.

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. Reuse across actors is a strong sign that trust artefacts are circulating in a reseller market or have been copied into attacker workflows. If blocklists update slowly, the control is already behind the threat.

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.

Technical breakdown

How signed malware keeps its trust signal

Code signing is a trust mechanism that lets an operating system or security product infer that a binary came from a known signer. In practice, that trust is only as strong as certificate issuance, private-key protection, and revocation discipline. If attackers buy, steal, or reuse certificates, the signature still looks legitimate until reputation systems, certificate revocation, or application control policies intervene. That is why signed malware is so effective: it exploits the gap between a valid cryptographic signature and a trustworthy software origin.

Practical implication: treat signed binaries as potentially hostile unless the signer, source, and lifecycle are governed together.

Why reseller-driven certificate reuse creates defender blind spots

The article describes a reseller market where certificates can be bought, resold, or minted in multiple serial-number variants under the same organisation name. That creates a supply chain for trust itself, not just for malware. Different threat groups can end up with overlapping signers even when they appear operationally separate, which makes attribution harder and lets reputation spill across unrelated campaigns. The technical problem is not only malicious content, but shared certificate provenance that defeats simple blocklists and one-off revocation assumptions.

Practical implication: correlate signer names, serials, issuers, and first-seen dates before deciding what to trust or block.

Why Windows trust controls have to move beyond allow-by-signature

Windows Defender Application Control and similar allowlisting tools can help, but permissive signature-based policy still allows abuse if the certificate is trusted by default. The article’s recommendation to block known bad certificates and use to-be-signed hashes reflects a deeper control truth: trust should be conditional, not inherited from signature alone. In machine identity terms, a code-signing certificate functions like a credential. If it is reused, sold, or not revoked promptly, it remains an active authentication artefact for attackers.

Practical implication: align application control policy with certificate lifecycle telemetry, not just publisher reputation.

Threat narrative

Attacker objective: The objective is to make malicious binaries look trustworthy enough to reach execution and persist across multiple campaigns.

1. Entry occurs when threat actors obtain code-signing certificates through a reseller or related trust channel rather than through a clean, single-use issuance path.
2. Privilege escalation happens when the signed malware inherits Windows trust and bypasses normal SmartScreen friction or permissive allowlisting.
3. Impact follows when the abused certificates are used to distribute multiple malware families, contaminate reputation signals, and widen the campaign surface across actors.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
• GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

GoldenEyeDog’s overlap pattern is a governance signal, not just an attribution clue. The limited sharing between subgroups suggests deliberate certificate separation, but the shared signer sources show that separation is still porous. That means defender models based on one actor, one certificate, or one campaign miss the operational reality that trust commodities circulate across crews. The named concept here is certificate provenance contamination: when the same trust artefact can surface in multiple malware families, making reputation and containment decisions less reliable. Practitioners should account for provenance, not only signature validity.

Revocation latency becomes the decisive control variable when code-signing abuse is industrialised. If abused certificates remain trusted long enough to be reused, the ecosystem keeps paying the attacker’s trust dividend. That has direct implications for endpoint policy, vendor trust review, and emergency blocklist workflows. The practical conclusion is simple: response teams need prebuilt revocation and block mechanisms before a campaign forces them to improvise.

This case reinforces that PKI governance and NHI governance are converging problems. A code-signing certificate is not a human user credential, but it behaves like a non-human credential with issuance, reuse, and offboarding risks. That intersection matters for IAM leaders because the operational failures are the same: uncontrolled issuance, weak inventory, and delayed retirement. Practitioners should manage certificates with the same lifecycle discipline they apply to privileged service accounts.

WDAC-style enforcement only works when policy intelligence keeps pace with abused signers. The article’s own recommendation to block known bad certificates and use to-be-signed hashes highlights a broader lesson: static trust controls age quickly in criminal supply chains. The right response is not blind distrust of all signatures, but continuous policy refresh tied to certificate intelligence. Practitioners should connect endpoint control to PKI telemetry and threat intel.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Machine Identity, PKI and Certificate Lifecycle Guide

What this signals

Certificate provenance contamination: when the same signer or serial appears across unrelated malware families, trust controls stop behaving like a clean security boundary and start acting like a shared attack surface. That means practitioners need provenance-aware policy, not simple publisher reputation, to decide what reaches execution.

The operational lesson for defenders is that revocation and blocklisting need to be managed as a standing program, not an incident-only reaction. Once abused certificates circulate through reseller channels, the window between first sighting and broad reuse can be long enough to defeat reactive controls.

For practitioners

• 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. Flag reused organisation names across multiple binaries and campaigns, especially when the same signer appears in unrelated software.
• 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. Maintain a rapid update path for signers that appear in threat intelligence.
• 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. Build this check into release approval, not only endpoint detection.
• Track certificate reuse across malware families Correlate serial numbers, signers, and issuers across different samples so that a certificate reused by multiple actors is treated as a trust contamination event, not a single malware attribution clue.

Key takeaways

• Code-signing abuse becomes a governance problem when trusted certificates are reused, resold, or intercepted across multiple malware campaigns.
• The article shows 115 tracked certificates and only four shared between the two GoldenEyeDog subgroups, which suggests deliberate separation alongside a shared source of trust artefacts.
• Defenders need provenance-aware certificate controls, faster revocation, and explicit deny policy rather than relying on signature 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.
• Certificate provenance: Certificate provenance is the traceable history of how a certificate was created, replaced, and approved over time. For non-human identities and hardware-backed tokens, it is the evidence that the object still belongs to the expected lifecycle, which becomes critical when write controls are bypassed.
• Windows Defender Application Control: Windows Defender Application Control is a Windows code integrity feature that permits only approved drivers, scripts, DLLs, and applications to run. It shifts enforcement from detecting bad software after the fact to allowing only known-good code paths before execution begins.
• Certificate Revocation List: A Certificate Revocation List is a signed publication from a certificate authority that lists certificates that are no longer trusted before their natural expiry. It is used by relying systems to confirm current status, and it becomes operationally useful only when the list is reachable, current, and readable by the consuming toolchain.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate lifecycle control into stronger access, trust, and offboarding decisions across modern identity programmes.