GoldenEyeDog Hijacks DigiCert Code-Signing Certificates to Sign Malware

DigiCert's April 2026 security incident has been linked to a subgroup within the China-linked GoldenEyeDog activity cluster, tracked as CylindricalCanine, which used malware to compromise a support employee's device and intercept code-signing certificate activation data.

How the intrusion started

The campaign began with a phishing lure disguised as a screenshot or document sent through DigiCert's own support ticket workflow, the same channel legitimate customers use to reach the company. When a support employee downloaded and opened the malicious file, Golden Gh0st Loader malware infected the device. That access gave the threat actors visibility into initialisation codes issued to customers renewing their code-signing certificates, codes used to activate customers' physical signing tokens.

Why stolen certificates matter more than stolen data

By intercepting those activation codes, the attackers could obtain certificates intended for legitimate customers and use them to digitally sign their own malware. A validly signed file carries a level of implicit trust that most users and even some security tools extend without question, and it can reduce or avoid Windows SmartScreen warnings that would otherwise flag an unsigned executable. GoldenEyeDog has reportedly abused code-signing certificates by this method since at least 2024, specifically to improve the success rate of malicious EXE and MSI file delivery.

Who is behind it

Researchers assess CylindricalCanine as a distinct operational subgroup within the broader China-linked GoldenEyeDog cluster, also tracked separately by Qi'anxin as APT-Q-27. The group has focused on financial organisations across the Asia-Pacific region, using phishing, malicious support submissions, credential theft, and modular malware delivery as its core toolkit.

How the malware actually operates

The infection chain relies on DLL sideloading. A first-stage loader downloads a legitimate executable, a malicious DLL, and an encrypted payload disguised as a log file. When the legitimate program loads the rogue DLL, it decrypts the payload in memory and launches Golden Gh0st RAT, a modified remote access trojan built on the older Gh0st RAT family. Once active, the RAT gives operators extensive control: screenshot capture, keylogging, process discovery, command execution, proxy tunnelling, browser credential theft, file deletion, event log clearing, and persistence. Some observed samples deploy an additional persistence plugin that creates a privileged backdoor account and modifies Windows logon settings to support ongoing remote access.

Indicators to watch for

Reported infrastructure includes the domains uu.goldeyeuu.io and wk.goldeyeuu.io over port 5188, and api.keensie.com over port 5198, all associated with Golden Gh0st RAT command and control. Security teams should treat any of these as high confidence indicators of compromise if observed in network traffic.

Why this matters for GCC enterprises

Code-signing certificates function as a foundational trust mechanism across essentially every software supply chain, and a certificate authority compromise of this kind undermines that trust regardless of which specific organisation was the original target. This connects directly to the trust chain problem we detailed in our coverage of compromised AsyncAPI npm packages, where valid provenance attestations turned out not to guarantee the legitimacy of the underlying commit. Both incidents share the same underlying lesson: cryptographic trust signals, whether a signed package or a signed executable, verify that a specific process was followed, not that the process itself was free of compromise. This is the same category of vendor-trust exposure we examined in our research on identity and access management in the GCC, where privileged access sitting one step removed from an organisation's core systems consistently proves to be the softest target. Enterprise security teams should not treat a valid code signature as sufficient evidence of legitimacy on its own, particularly for executables arriving through support channels, email attachments, or software updates from vendors whose certificate issuance processes are not directly visible to the receiving organisation.