GoldenEyeDog’s DigiCert certificate theft exposes NHI trust gaps

At a glance

What this is: This is Expel’s analysis of GoldenEyeDog’s malware, its use of stolen code-signing certificates, and the April 2026 DigiCert intrusion that enabled certificate theft.

Why it matters: It matters because certificate trust, support workflows, and third-party access controls sit inside identity governance, and failures here can give malware a trusted execution path.

By the numbers:

• 69% of organisations now have more machine identities than human ones.
• 57% of organisations lack a complete inventory of their machine identities.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Expel’s analysis of GoldenEyeDog malware and DigiCert certificate theft

Context

Code-signing certificates are a trust anchor for software execution, so when attackers steal or abuse them, they inherit a legitimacy signal that can bypass user and endpoint friction. In this case, the primary weakness was not just malware delivery, but the way trusted support workflows and certificate issuance created a path from access to signed payloads.

The article also sits at the intersection of NHI governance and supply-chain security because certificates are non-human identities with a lifecycle that must be issued, protected, monitored, and revoked. When a support device, customer initialization code, or certificate renewal workflow is compromised, the problem becomes one of identity control, not just malware detection.

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 code-signing certificates create governance risk beyond software publishing?

A: Because they are identity credentials for software, code-signing certificates sit inside a lifecycle that includes issuance, activation, custody, renewal, and revocation. If any of those steps are exposed through support channels, vendor workflows, or shared endpoints, attackers can convert trust into execution. That makes certificate governance part of identity security, not just PKI administration.

Q: How do security teams detect certificate abuse in real environments?

A: Teams should look for unexpected signed binaries, unusual publisher lineage, companion DLL loading, and malware that appears only after trusted execution paths are used. Logging certificate inventory is not enough if the delivery chain can still abuse support tickets or vendor portals. Detection must combine file provenance, endpoint behavior, and certificate lifecycle monitoring.

Q: Who is accountable if a certificate is misused in an approval workflow?

A: Accountability sits with both the issuing authority and the organisation operating the workflow. The issuer must validate certificate governance, while the department must control role assignment, key custody, and revocation. In regulated environments, that shared accountability is what makes the audit trail defensible.

Technical breakdown

How code-signing certificates change execution trust

Windows SmartScreen and related reputation systems use certificate history as one signal for whether a binary should run with fewer prompts. Attackers exploit that trust by signing malware with legitimate certificates, which can reduce warnings and make malicious files look routine to users and some controls. Once a certificate is trusted, the attacker is no longer trying to invent trust from scratch. They are borrowing it from the certificate authority ecosystem and from the software supply chain that depends on it.

Practical implication: treat certificate compromise as an execution-control failure, not just a cryptographic incident.

DLL sideloading and staged loader chains

The loader pattern described here uses a benign executable to load a malicious DLL, which then decrypts a third file in memory. This works because many applications expect companion DLLs and will load them before deeper inspection occurs. The staged design also helps attackers vary file names, hosting locations, and decoys while keeping the core implant logic stable. That makes static file-based detection less reliable than lineage, load-order, and behavior-based monitoring.

Practical implication: monitor unsigned or unexpected DLL loads beside legitimate executables, especially in ticketing-driven delivery paths.

Certificate lifecycle failure as an identity problem

A code-signing certificate is an identity credential for software, with issuance, token activation, renewal, and revocation boundaries just like human or workload identities. In the DigiCert case, access to a support member’s device enabled theft of customer initialization codes, which in turn enabled certificate activation and misuse. The weak point was not the certificate format itself but the surrounding lifecycle controls, including support access, token handling, and renewal workflows.

Practical implication: extend identity governance to certificate issuance support paths, token custody, and renewal offboarding.

Threat narrative

Attacker objective: The attackers aim to turn stolen certificate trust into durable malware execution and broader campaign reliability.

1. Entry occurred through a malicious file delivered via phishing email or a support ticketing workflow, which reached the victim’s device through a trusted business channel.
2. Credential access followed when the compromised device exposed customer initialization codes and other certificate-related material that enabled misuse of DigiCert-issued certificates.
3. Impact came when the attackers used the stolen certificates to sign their own malware, increasing trust and improving delivery success.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certificate trust is an identity control, not a branding problem. When attackers can sign malware with legitimate certificates, they are abusing a software identity that downstream controls are built to trust. That means certificate governance must be treated with the same seriousness as privileged access, because the blast radius includes execution trust across endpoints and application controls. Practitioners should manage certificates as high-value identities, not as passive technical artifacts.

Support workflows are now part of the attack surface for NHI governance. The DigiCert incident shows that certificate theft can begin with a support member’s device, a ticketing channel, or a renewal flow rather than a classic admin compromise. This is a governance failure around lifecycle containment, not simply a malicious file problem. The specific control gap is the absence of end-to-end custody over certificate activation material and support-side access.

Code-signing abuse creates a trust gap that standard malware controls do not close. SmartScreen bypass and DLL sideloading together show how attackers blend identity abuse with execution-path manipulation. The named concept here is certificate trust leakage, where one compromised trust anchor contaminates multiple controls downstream. Teams should assume signed code can still be hostile and build layered verification around provenance, behavior, and publisher lifecycle.

Machine identity scale makes certificate sprawl harder to govern than many teams expect. Certificates are part of the broader non-human identity estate, and the governance burden grows as machine identities outnumber human ones. Once renewal, token activation, and revocation become distributed across teams and vendors, visibility drops quickly. The practical conclusion is that NHI governance has to include certificate inventory, ownership, and support-channel monitoring, not just vault hygiene.

Attackers are optimizing for trust reuse, not just stealth. This campaign shows persistence in tactics because trusted infrastructure still reduces friction better than inventing new malware delivery every time. That is why identity and security teams should focus on trusted-path abuse, not only on payload signatures. The field should treat certificate abuse as a repeatable identity exploitation pattern, not an edge case.

From our research:

• 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
• 57% of organisations lack a complete inventory of their machine identities, which makes certificate and workload governance harder to sustain at scale.
• Forward pivot: See Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and rotation gaps that make trust leakage harder to contain.

What this signals

Certificate trust leakage is the operational pattern security teams should watch now. Once a signing credential is exposed, the attacker can reuse the trust signal across delivery, execution, and persistence paths, which means endpoint controls alone will not close the gap. The practical response is to treat certificate custody, renewal, and activation as part of the identity control plane, not a separate PKI silo.

The scale problem is the harder issue. When machine identities outnumber human identities by 69%, certificate governance becomes a lifecycle management problem with ownership, inventory, and revocation pressure at enterprise scale, not just a niche supply-chain issue. That is why the most effective programmes will tie certificate monitoring to Why NHI Security Matters Now rather than leaving it inside a narrow platform team.

Practically, this should push organisations toward tighter support-path controls, stronger separation of duties for activation material, and explicit ownership for software identities. The teams that can answer who holds the trust anchor, where it is activated, and how quickly it is revoked will be better positioned than teams that only scan for malicious binaries.

For practitioners

• Inventory code-signing certificates as NHI assets Track issuers, owners, renewal dates, token custody, and downstream software use in a single certificate register so support teams cannot act outside visible governance.
• Lock down support-channel delivery paths Quarantine attachments and linked downloads that reach support queues, and require detonation or sandbox review before a ticketed file can be executed on a support device.
• Separate certificate activation codes from support endpoints Move initialization codes and token activation material out of general-purpose support laptops and require privileged approval for any retrieval or use.
• Detect DLL sideloading beside trusted executables Write detections for unexpected companion DLL loads, especially when a benign binary is paired with a second-stage decryptor or RWX memory use.
• Revoke and rotate exposed certificate material immediately Treat compromise of certificate activation codes, token custody, or support-device access as a revocation event and validate whether any signed payloads were already issued.

Key takeaways

• GoldenEyeDog’s campaign shows how stolen code-signing trust can turn malware into a trusted software event.
• The key failure mode is certificate lifecycle exposure through support channels, not just malicious file delivery.
• Practitioners should govern certificates as high-value non-human identities with clear ownership, inventory, and revocation paths.

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.
• DLL Sideloading: A technique where a legitimate executable loads a malicious library from a location the application checks before the real system path. It works because the program’s trust is inherited by the code it loads, which makes execution control as important as file reputation.
• 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.
• Trust leakage: Trust leakage is the spread of confidence from one compromised identity or control into other systems that rely on it. In this context, a stolen signing certificate leaks trust into endpoint execution and software reputation systems, allowing malware to benefit from legitimate provenance.

What's in the full article

Expel's full analysis covers the technical detail this post intentionally leaves at the governance and risk level:

• Malware unpacking details for Golden Gh0st Loader and Golden Gh0st RAT, including the staged DLL sideloading chain
• Network communication decryption logic and indicator examples that support hands-on detection work
• Observed command IDs, plugin behavior, and persistence mechanisms used by the implant
• IOC tables and campaign artifacts that help defenders correlate related activity across environments

👉 Expel’s full post includes the malware chain, decryption approach, and defensive indicators in detail.

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 lifecycle control. It helps identity and security practitioners apply consistent governance to certificates, workloads, and other non-human identities.