GoldenEyeDog’s DigiCert certificate theft exposes NHI trust gaps

At a glance

What this is: Expel’s analysis says GoldenEyeDog used stolen code-signing certificates to make malware look trusted, including a DigiCert-related theft that let the group sign malicious code.

Why it matters: This matters because certificate trust, support workflows, and machine identity governance can be turned into an ingress path when issuance and revocation controls do not hold under attack.

Context

Code-signing certificates are meant to create trust for software distribution, but they also create a high-value attack surface when attackers can obtain, steal, or reuse them. In this case, the security gap is not just malware delivery. It is the governance gap between certificate issuance, support access, and the downstream trust that Windows and users place in signed binaries.

The article also has a clear non-human identity angle because certificates, support tokens, and signing authority are machine identities that can be abused once lifecycle controls fail. When those credentials are stolen or reused, the trust boundary shifts from the software publisher to the attacker, which is why certificate governance belongs in identity security as much as in cryptography.

GoldenEyeDog’s activity is not a one-off novelty. The campaign shows a repeatable pattern in which trusted artifacts are turned into delivery mechanisms, and the fact that this has persisted across multiple campaigns suggests the control weakness is structural rather than accidental.

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 support workflows create risk for certificate governance?

A: Support workflows create risk when they can reach certificate activation, renewal, or recovery without strong separation of duties. If a help desk device or ticketing path is compromised, the attacker may obtain bootstrap material that unlocks a signing identity without attacking the certificate itself. That turns ordinary service operations into a trust boundary that needs identity controls.

Q: What signs suggest signed malware is being reused across campaigns?

A: Look for the same issuer, certificate fingerprint, or signing chain appearing across binaries that have different lures, hosts, or payload names. Reuse is especially suspicious when the malware family changes its delivery files but keeps the trust anchor intact. That pattern usually means the certificate is acting as a persistent abuse asset rather than a one-time compromise.

Q: Should teams focus on revocation or on support access first after this kind of incident?

A: Teams should do both, but support access deserves immediate scrutiny because it is often the path that exposed the certificate material in the first place. Revocation limits ongoing abuse, while support-access review shows whether the same path can be used again. If the activation or recovery workflow remains open, the compromise is not really contained.

Technical breakdown

How stolen code-signing certificates change Windows trust decisions

Windows SmartScreen and related reputation mechanisms are designed to reduce risk from unknown binaries by building trust over time. Code-signing certificates let a publisher prove software origin, but they can also suppress warnings or improve execution likelihood when attackers sign malware with legitimate credentials. The problem is not the signature format itself. It is that trust becomes portable once a signing identity is compromised, stolen, or misused. In this case, the threat is amplified when the certificate is tied to a customer or support workflow that the attacker can reach indirectly.

Practical implication: treat signing certificates as high-value machine identities and govern their issuance, storage, and revocation as part of identity security.

How support-channel compromise becomes a certificate theft path

The DigiCert incident described in the article shows a common pattern: a support user’s device was infected after opening a malicious file received through a ticketing workflow, and that compromise was then used to steal initialization codes for customers with open renewal orders. Those codes activated physical hardware tokens for signing, which means the attacker did not need to break the cryptography. They only needed to reach the trust bootstrap around it. This is a classic example of an identity control failure around delegated access, support tooling, and renewal lifecycle.

Practical implication: separate support-device trust from customer-signing trust and harden the renewal path around token activation and delegated access.

Why DLL sideloading and staged payloads keep the campaign resilient

Golden Gh0st Loader uses a staged design that drops a legitimate executable, a malicious DLL, and an encrypted payload file. The benign executable loads the DLL, the DLL decrypts the third file in memory, and the RAT is assembled only at runtime. That architecture makes static detection harder and lets the operator swap lure documents, hosts, and decoys without changing the core logic. For defenders, the important point is that certificate abuse is only one layer of the attack chain. Execution tradecraft and persistence still matter once the signed payload lands.

Practical implication: hunt for benign EXE plus malicious DLL combinations, not just for signed malware hashes.

Threat narrative

Attacker objective: The attackers want to turn trusted certificate infrastructure into an abuse channel for malware delivery, reputation bypass, and broader campaign persistence.

1. Entry began with phishing emails or ticketing-system submissions that delivered a disguised file to a support workflow, which caused the victim to open or download the payload.
2. Credential access followed when the compromised support device allowed the operators to steal customer initialization codes and certificate-related trust material from DigiCert.
3. Escalation occurred as the actors used those trust assets to sign malware, making malicious binaries appear legitimate to Windows and users.
4. Impact was the ability to bypass SmartScreen and expand malware delivery under trusted signatures, increasing reach and persistence across campaigns.

Breaches seen in the wild

• 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.
• NVIDIA code-signing certificates stolen 2022: Lapsus$ leaked two NVIDIA code-signing certificates; Windows still trusted them for drivers and attackers signed Cobalt Strike and Mimikatz with them.

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

Certificate trust is now a machine-identity governance problem, not just a PKI problem. The article shows how a signing certificate can be transformed from proof of publisher identity into a delivery mechanism for attacker-controlled code. Once the trust anchor is stolen or abused, downstream platforms inherit that trust unless lifecycle controls catch up. Practitioners should treat certificate governance as identity governance for software supply chains.

Support workflows are part of the trust boundary. The DigiCert-related compromise matters because the attacker did not need to defeat cryptography to reach the signing process. They targeted the support device and the activation path around customer certificates, which is where delegated authority often becomes invisible. That is the control gap: the organisation trusted the process that trusted the device. Teams should review delegated support access as a certificate-security control.

SmartScreen bypass shows how reputation systems can be turned into persistence systems. When attackers repeatedly sign malware with valid certificates, the bypass becomes operational rather than incidental. The named concept here is signed trust reuse: a stolen signing identity keeps being recycled to preserve execution advantage across campaigns. That pattern belongs in NHI governance, because the identity being reused is the certificate itself. Practitioners should assume trust reuse will outlive a single compromise unless revocation, monitoring, and issuer-side detection are coordinated.

Certificate compromise is a supply-chain issue with identity consequences. The abuse of customer signing material affects software trust, but the deeper lesson is that third-party issuance ecosystems can become part of the attack surface. The article connects supplier compromise, delegated activation, and malware signing into one chain. Teams that own third-party access, certificate lifecycle, or software release integrity should treat this as evidence that external trust domains need continuous governance, not periodic review.

What this signals

Signed trust reuse: once a certificate is stolen or activated through a compromised support path, attackers can keep recycling that trust to push malicious binaries past user and platform suspicion. That makes signing identity governance a recurring operational control, not a one-time issuance task.

Certificate-based abuse shows why software release integrity and identity lifecycle have to be managed together. Revocation matters, but so do activation paths, delegated support permissions, and the devices that can reach them.

For defenders, the practical shift is to treat certificate compromise like an identity incident with supply-chain consequences. The right question is not only whether the certificate was revoked, but whether the trust path that exposed it has been closed.

For practitioners

• Tighten certificate activation controls Require separate approval, device trust, and step-up verification for any certificate initialization code or signing-token activation request.
• Inventory all signing identities and renewal paths Map every code-signing certificate, renewal order, hardware token, and delegated support path to a named owner and expiration date.
• Monitor for signed malware reuse Alert on repeated use of the same signing chain, issuer, or certificate fingerprint across binaries that do not belong to your normal release process.
• Segment support endpoints from issuance systems Keep help desk and customer support devices out of the administrative path that can approve, activate, or recover signing credentials.
• Revoke and rotate after any support-device compromise If a support workstation touches renewal or activation workflows, treat the event like a certificate trust incident and invalidate exposed material immediately.

Key takeaways

• GoldenEyeDog’s campaign shows that stolen code-signing certificates can convert a trusted software identity into a malware delivery channel.
• The DigiCert-related intrusion demonstrates that support-device compromise and certificate activation workflows can expose signing material without breaking cryptography.
• Teams need certificate lifecycle controls, delegated-access review, and revocation discipline to reduce the risk of trusted binaries being abused.

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 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.
• SmartScreen: A Windows protection feature designed to warn users about unsafe downloads, files, and websites. It helps reduce phishing and malware exposure by inserting a trust-check before execution or navigation. When spoofing flaws affect SmartScreen, attackers can exploit user trust and weaken a control that is meant to interrupt unsafe action.
• Initialization code: Initialization code is bootstrap material used to activate a hardware token or otherwise begin use of a signing credential. It is not the certificate itself, but it can be equally sensitive because it may unlock the path to issuance or signing authority.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps identity, security, and infrastructure teams build a shared control model for high-value credentials.