GoldenEyeDog Subgroup Linked to DigiCert Code-Signing Certificate Attack

Security company Expel has linked the April 2026 DigiCert intrusion to CylindricalCanine, a subgroup it associates with the Chinese cybercrime operation GoldenEyeDog. The attackers compromised DigiCert support workstations and obtained initialization codes for approved code-signing certificate orders.

The stolen codes allowed the attackers to provision certificates intended for legitimate customers and use some of them to sign malware. DigiCert revoked 60 code-signing certificates, including 27 that investigators explicitly connected to the threat actor. The company says no affected certificates remain valid.

The attribution comes from Expel’s CylindricalCanine investigation. DigiCert’s own public certificate incident report documents the intrusion, certificate misuse and response, but does not identify the attacker as GoldenEyeDog.

What Happened in the DigiCert Breach?

The attack began on April 2, 2026, when a threat actor contacted DigiCert support and repeatedly submitted malicious ZIP archives through a customer chat channel. The files were presented as screenshots that support analysts needed to review.

One support analyst opened a malicious file at approximately 23:45 UTC. Several executables then ran on the workstation. Endpoint security tools generated high-severity detections, and DigiCert isolated the device within hours.

However, a second support workstation was also compromised. DigiCert later found that its endpoint detection and response sensor was not installed or properly configured on that machine. The resulting monitoring gap allowed the attacker to retain access without triggering the same alerts.

Date	Confirmed activity
April 2, 2026	Malicious ZIP files submitted through customer support chat
April 2 to 3	First support workstation infected, detected and isolated
April 4	Earliest confirmed unauthorized activity involving the second workstation
April 5 to 14	Certificate problem reports reveal a wider pattern
April 14 to 16	DigiCert restricts portal access, masks codes and strengthens authentication
April 17	Final identified certificate revoked

Attackers Obtained Initialization Codes, Not Existing Private Keys

The attackers reached an internal support portal that allowed authenticated support analysts to enter customer accounts through a proxy function. This access exposed initialization codes for some approved code-signing certificate orders.

An initialization code acts as a single-use credential during hardware-token provisioning. When combined with an approved order, it allows the holder to generate a key pair on a token and retrieve the corresponding certificate.

This distinction is important. The attackers did not extract private signing keys that legitimate customers had already stored on their hardware. Instead, they intercepted pending certificate orders before the intended customers completed activation.

Why the Initialization Codes Were Valuable

DigiCert explains in its code-signing certificate documentation that these certificates verify a software publisher’s identity and show whether a signed file has changed since signing.

For a hardware-token order, the customer normally receives an initialization code after DigiCert approves the certificate request. The customer enters that code into DigiCert’s installer, which generates the private key on the token and retrieves the certificate.

Because the codes worked like bearer credentials for approved orders, anyone who obtained a valid unused code could complete the provisioning process. DigiCert said the single-use design also helped investigators identify which codes the attacker had used.

• The customer submitted a code-signing certificate request.
• DigiCert validated and approved the request.
• DigiCert generated a single-use initialization code.
• The attacker obtained the code through compromised support access.
• The attacker activated a hardware token before the customer did.
• DigiCert issued the certificate against the approved order.
• The attacker used the resulting certificate to sign malware.

DigiCert Revoked 60 Certificates

DigiCert explicitly linked 27 revoked certificates to the threat actor. Community members identified 11 after finding certificates attached to malware, while DigiCert found another 16 during its internal investigation.

The company revoked 33 additional certificates as a precaution because it could not confirm that the intended customers controlled them. DigiCert also cancelled pending certificate orders that fell within the affected window.

According to the updated DigiCert incident disclosure, every identified certificate was revoked within 24 hours of discovery. The revocation dates were set to the original issuance dates, and the final identified certificate was revoked by April 17.

Certificate response	Number
Certificates explicitly linked to the attacker	27
Certificates revoked as a precaution	33
Total code-signing certificates revoked	60
Affected certificates still valid	0

CylindricalCanine and GoldenEyeDog Attribution

Expel tracks the operators as CylindricalCanine and assesses that they form part of GoldenEyeDog, also known as APT-Q-27 in reporting from Chinese security company Qi’anxin. Expel describes GoldenEyeDog as a Chinese cybercrime group rather than confirming it as a government-backed operation.

The attribution relies on shared tactics, malware behavior, naming patterns and encryption techniques. Expel also observed the group using code-signing certificates in malware campaigns before the DigiCert intrusion.

Security teams should treat this as a research assessment rather than an attribution announced by DigiCert. Different security companies may also use different names for the same malware, operators or wider criminal network.

Golden Gh0st Loader and RAT Capabilities

Expel calls the malware used by CylindricalCanine Golden Gh0st Loader and Golden Gh0st RAT. Earlier research identified related samples as Zhong Stealer, but Expel found that the malware provides broader remote-access capabilities.

The RAT can collect browser credentials, capture screenshots, list files and processes, run commands, transfer payloads and control infected computers. It also contains anti-forensic functions that can remove files, delete persistence mechanisms and clear Windows event logs.

The detailed Golden Gh0st RAT analysis describes a plugin named plugin32.dll. The plugin creates an administrative backdoor account and changes Windows settings to permit automatic logon and Remote Desktop access.

Capability	Purpose
Credential collection	Steals information stored in browsers and applications
Screenshot capture	Records information visible on the victim’s desktop
Command execution	Allows operators to control the infected system remotely
File management	Lists, downloads, uploads or deletes files
Process discovery	Identifies running applications and security tools
RDP backdoor	Creates another route for persistent remote access
Log clearing	Removes evidence from Windows event logs
Self-deletion	Erases payload files and selected persistence artifacts

DLL Sideloading Conceals the Malware

Golden Gh0st Loader commonly uses DLL sideloading. The attack places a malicious DLL beside a legitimate executable that searches its local directory for required libraries.

When the trusted application starts, it loads the attacker’s DLL. The malicious library then decrypts or loads the RAT payload, which may be stored in a file disguised as a log or another harmless format.

The technique can make initial execution appear less suspicious because a legitimate application starts the malicious chain. Digital signatures on one component also do not prove that every DLL loaded by the process is trustworthy.

How Signed Malware Can Influence Security Decisions

A valid digital signature does not prove that a file is safe. It identifies the certificate holder and shows whether the file has changed since it was signed. If an attacker fraudulently controls a legitimate certificate, the attacker can apply a technically valid signature to malicious software.

Microsoft Defender SmartScreen evaluates downloaded programs using factors that include file, application, URL and certificate reputation. A signature can contribute to this assessment, but it does not override every reputation or malware check.

Microsoft changed its treatment of code-signing certificates in recent years, including removing the automatic reputation advantage previously associated with Extended Validation certificates. Signed malware may still appear more credible to users or security products, but a newly issued certificate does not guarantee an automatic SmartScreen bypass.

Golden Gh0st Network Activity

Expel observed Golden Gh0st RAT communicating over WebSocket connections. The outer WebSocket connection was not protected by TLS, but the malware encrypted and compressed the command data carried inside it.

The researchers most frequently observed command traffic on ports 5188 and 5198. The malware used a custom protocol with a 12-byte header and regular heartbeat messages between infected systems and command servers.

These traits can support network detection, but defenders should combine them with process, DNS and endpoint evidence. A connection on one of these ports does not independently prove that a device is infected.

Indicator	Type	Reported role
uu.goldeyeuu.io:5188	Domain and port	Golden Gh0st RAT command server
wk.goldeyeuu.io:5188	Domain and port	Golden Gh0st RAT command server
api.keensie.com:5198	Domain and port	More recently observed command server
27b722c66f69e360c4da106daacf3b9eeaabd20634d7e5eff45a28bd70ebfd65	SHA-256	Malicious DLL used for sideloading
3313f347e83aaf48ea31fb1d49fc37452f48f81d20a1b93009e2e78385ff4bba	SHA-256	Encrypted Golden Gh0st payload
d1b1938963037aa332591a4c999523a05886d1f62d80e03f0adc22630b8671c4	SHA-256	Unpacked RDP persistence plugin

How DigiCert Responded

DigiCert masked initialization codes from support users accessing customer accounts through proxy sessions. It applied the restriction to both the user interface and API on its US and European platforms.

The company cancelled pending orders within the affected window, disabled support accounts associated with the compromised devices and tightened authentication requirements. It also reviewed EDR coverage after discovering the protection gap on the second workstation.

DigiCert’s current certificate provisioning requirements state that public code-signing private keys must reside on approved hardware, such as a compliant token or hardware security module. The incident shows that protecting the provisioning workflow is as important as protecting an already-generated private key.

Defensive Actions for Support and Security Teams

Organizations should treat support portals as file-ingestion systems exposed to untrusted users. Attachments and external download links should open only in isolated review environments with restricted credentials and network access.

Security teams should verify that endpoint protection covers every device belonging to support, certificate-management and administrative personnel. A missing sensor should generate an alert before an attacker can exploit the visibility gap.

Defenders should also inspect signed files as carefully as unsigned files. The Microsoft SmartScreen guidance shows that signatures form only one part of application reputation. File behavior, prevalence, certificate status and threat intelligence remain relevant.

• Open customer attachments in an isolated sandbox.
• Block or quarantine executable screensaver files and unexpected archives.
• Alert when EDR agents are missing, disabled or no longer reporting.
• Restrict support impersonation and customer-account proxy functions.
• Hide certificate activation secrets from support sessions.
• Require additional approval for sensitive certificate operations.
• Monitor suspicious DLL loads from user-writable directories.
• Detect unexpected local administrator creation and RDP configuration changes.
• Check certificate revocation status when investigating signed malware.
• Hunt for Golden Gh0st domains, hashes and WebSocket patterns across historical logs.

FAQ