DigiCert Incident Puts Code-Signing Certificate Risk in Focus

Overview

New analysis from Expel links a subgroup in the GoldenEyeDog ecosystem, tracked as CylindricalCanine, to an April 2026 incident at DigiCert. According to the analysis, attackers used malware to compromise a support employee’s device and gain access to code-signing certificates intended for DigiCert customers.

The topic matters because code-signing certificates are part of the software trust model. They do not make a file automatically safe, but they help operating systems, security tools and users determine whether software comes from the expected publisher and whether the code has been modified after signing.

When attackers gain access to a valid code-signing certificate, malicious files can appear more trustworthy. This creates risk for software supply chain integrity, endpoint protection and vendor trust processes.

What Happened

According to Expel, the attackers used social engineering against the support process. Malicious files were presented as screenshots or customer evidence, submitted through phishing emails or support tickets. After the file was opened, the support employee’s device was compromised.

The access allowed the attackers to reach activation codes associated with code-signing certificate renewal or issuance. These codes are used to activate hardware tokens required for software signing.

The attackers could then use stolen certificates to sign their own malicious files. This does not remove the need for malware to perform malicious actions, but it may help the file look more legitimate during early execution and analysis.

Why Code-Signing Certificates Are Sensitive

Code-signing certificates are used to confirm that software comes from a specific publisher and has not been changed after signing. They are important for:

• software vendors;
• internal development teams;
• update mechanisms;
• enterprise deployment processes;
• endpoint security tools;
• user trust;
• software integrity validation.

If a certificate is stolen or abused, an attacker can sign malware with a valid digital signature. This can complicate initial assessment by users, IT teams and some security controls.

The risk is therefore not only technical. It affects trust in how software is delivered, installed and updated.

Malware Used in the Campaign

Expel links the activity to Golden Gh0st Loader and Golden Gh0st RAT. These tools are used in campaigns associated with GoldenEyeDog activity.

Golden Gh0st RAT may provide capabilities for:

• remote access;
• command execution;
• browser credential collection;
• screenshot capture;
• process enumeration;
• persistence;
• activity trace removal;
• additional backdoor access.

Expel also describes the use of DLL sideloading. In this technique, a legitimate application is used to load a malicious DLL placed in the expected directory. This makes detection harder because part of the execution chain appears linked to a trusted executable.

Support and Ticketing Process Risk

The incident highlights a common weakness in many organizations: support teams often receive files from external users, customers or partners. These files may be screenshots, logs, documents, archives or proof-of-issue materials.

This creates specific risk:

• employees expect to open external files;
• files may look like part of a normal customer workflow;
• support systems may not be fully isolated;
• attachment scanning may miss new payloads;
• a compromised support endpoint may have access to sensitive customer workflows.

Support processes should therefore be treated as part of the attack surface, especially when support teams handle certificates, credentials, activation codes, customer environments or sensitive operational data.

What Should Be Monitored

Organizations that use code-signing processes or process customer-submitted files should monitor several activity types:

• execution of unexpected .scr, .exe, .dll or archived files;
• DLL sideloading by legitimate applications;
• new scheduled tasks;
• new local administrator accounts;
• changes enabling remote desktop access;
• unusual outbound WebSocket connections;
• access to certificate management systems;
• extraction or use of activation codes;
• unusual file signing activity;
• signed files that do not match the normal release process;
• code-signing certificate use outside the expected build environment.

Context is important. A digital signature alone should not be enough to treat a file as safe. The signature should be reviewed together with publisher, signing time, signing location, release workflow and file behavior.

Recommended Actions

Organizations should treat code-signing certificates as sensitive security assets.

Priority actions include:

• restrict access to code-signing certificates and hardware tokens;
• use multi-person approval for critical signing operations where applicable;
• isolate build and signing environments;
• monitor when, where and by whom files are signed;
• prohibit signing outside approved systems;
• monitor certificate usage logs;
• rotate or revoke certificates when compromise is suspected;
• verify whether signed files match the normal release process;
• isolate support endpoints that process external files;
• use sandbox environments for customer-submitted attachments;
• train support teams not to run unverified screenshots, installers or archives;
• monitor DLL sideloading and unusual persistence mechanisms.

If code-signing certificate abuse is suspected, response should include more than certificate revocation. Teams need to check which files were signed, where they were distributed, whether they reached customers and whether downstream impact exists.

DIAMATIX Perspective

The incident shows that software trust must be managed as part of the security model. Code-signing certificates, build processes, support channels and endpoint controls are connected.

For organizations, the risk is not only whether a certificate provider was affected. The question is whether internal processes can detect signed malware, unusual certificate use or a compromised support/workstation environment.

DIAMATIX treats cases like this as a software supply chain and trust infrastructure risk: the certificate is a trusted element, but file behavior, delivery path and signing context need to be monitored together.

CISO Analysis

For CISOs, the key question is whether the organization knows how code-signing certificates are managed and who can access them.

Key questions to review:

• Which code-signing certificates do we use and where are they stored?
• Who is authorized to sign software?
• Is every signing operation logged?
• Can a certificate be used outside an approved build environment?
• Is there a process for revocation and rotation if compromise is suspected?
• Do we evaluate signed files by behavior, not only by valid signature?
• Are support endpoints that process external files isolated?
• Is there a process for reviewing customer-submitted attachments?

The practical takeaway is that code-signing certificates should be managed like privileged access. If abused, the risk can extend to customers, partners and downstream software users.

What This Means for Your Environment

• This type of risk relies on compromised support endpoints, abuse of activation codes and use of valid code-signing certificates to sign malware.
• Detection depends on visibility into certificate usage, signing workflows, support attachments, endpoint behavior, DLL sideloading and outbound command-and-control communications.
• Response requires revocation of affected certificates, review of signed files, support endpoint investigation, persistence analysis and downstream impact assessment.

Key questions to review:

• Do you know all code-signing certificates your organization uses?
• Can you see when and where each certificate was used?
• Are files submitted through support channels controlled?
• Could validly signed malware bypass part of your process?
• Do you have a response plan for a compromised code-signing certificate?

Review control over code-signing certificates and software supply chain risk

DIAMATIX can help review:

• code-signing processes and certificate usage;
• build and release workflows;
• support channels and external file handling;
• endpoint telemetry for DLL sideloading and persistence;
• certificate revocation and rotation procedures;
• response readiness for compromised trusted software assets.

Request a software trust and code-signing risk review with DIAMATIX.
Trusted · Innovative · Vigilant

Sources

• Expel. Introducing CylindricalCanine: The GoldenEyeDog subgroup responsible for the April DigiCert incident.
• The Hacker News. GoldenEyeDog Subgroup Linked to DigiCert Breach and Code-Signing Certificate Theft.
• DigiCert. Microsoft and code-signing certificates: What to know.
• Expel IOC repository for Golden Gh0st indicators.

This article is based on publicly available information as of July 2026.