In April 2026, a threat cluster called CylindricalCanine stole code-signing certificates from DigiCert, one of the largest certificate authorities that issues the digital signatures software relies on. Security firm Expel attributes this cluster to a subgroup of GoldenEyeDog, and the certificates the attackers obtained were used to sign real malware. (Source: The Hacker News)

Here is why that matters to you. A code-signing certificate is a trust anchor. When software is signed with a valid certificate from a recognized authority, your operating system, browsers, and endpoint tools treat it as legitimate and let it run with fewer warnings. When attackers hold a genuine certificate issued through DigiCert's own infrastructure, their malware inherits that same trust.

The theft targeted EV Code Signing certificate orders, the highest-assurance tier meant to give the strongest guarantee that software comes from a verified publisher. DigiCert revoked 60 certificates across four issuing CAs, including DigiCert Trusted G4 Code Signing RSA4096 SHA256 2021 CA1 and Verokey High Assurance Secure Code EV.

Of the 60 revoked certificates, 27 were explicitly linked to the threat actor, with the exploited certificates used to sign

Zhong Stealer

malware artifacts.

The scope reflects who GoldenEyeDog goes after. Expel notes the group's malware focuses on finance organizations in the Asia-Pacific region, consistent with the gambling, gaming, and Web3 sectors it has hit before. But certificate theft widens that blast radius well beyond the original targets, because signed malware can reach any organization that trusts the affected CAs.

For technical teams, this changes what a valid signature tells you: a trusted publisher name on an installer is no longer proof the file is safe. For executives responsible for software intake and vendor risk, it means the trust you place in signed third-party software and your certificate suppliers now carries a supply-chain dependency that a single compromised support workstation can undermine.

Attack Chain: From DigiCert Compromise to Malware Deployment

The intrusion started with a chat message, not an exploit. On April 2, 2026, the threat actor contacted DigiCert's support team through a customer chat channel and delivered a ZIP file disguised as a customer screenshot. Inside was a .scr executable carrying a malicious payload.

When a support analyst ran it, the actor gained control of two support analyst workstations. From there, they pivoted to a legitimate portal function — one that lets authenticated support staff view customer accounts "from the customer's perspective" to help with tickets. That feature became the pivot point for the whole operation.

Using that view, the actor pulled initialization codes for orders that were approved but pending delivery, specifically for EV Code Signing certificate orders across a set of customer accounts. Possession of an initialization code plus an approved order was, in DigiCert's own words, "functionally sufficient" to obtain the certificate. No further authorization stood in the way.

DigiCert revoked 60 certificates issued under four CAs: DigiCert Trusted G4 Code Signing RSA4096 SHA256 2021 CA1, DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1, GoGetSSL G4 CS RSA4096 SHA256 2022 CA-1, and Verokey High Assurance Secure Code EV. Of those, 27 were explicitly tied to the threat actor, and the actor used them to sign Zhong Stealer artifacts. For DigiCert's customers, that means legitimate certificate orders were effectively hijacked before delivery — the fraud rode on genuine, trusted issuance.

How the malware reaches the endpoint

Once past the initial-access stage, the delivery pattern is consistent. Files disguised as screenshots arrive in phishing emails or support-portal submissions, embedded as links rather than attachments. Clicking the link pulls additional payloads from an external server.

The download triggers a DLL side-loading chain: a legitimate signed executable is used to run a rogue DLL alongside it. To keep the victim unsuspecting, a decoy PDF displays an HTTP 503 "Service Unavailable" error while the malicious DLL loads an encrypted payload stored as update.log. That final stage is Golden Gh0st RAT.

What Golden Gh0st RAT does on the host

Golden Gh0st RAT is modular, with functionality handled through plugins and an internal module dispatcher — the same architecture seen across other Gh0st RAT (Farfli) variants. Its capabilities include:

• Establishing persistence and starting a SOCKS proxy tunnel for pivoting deeper into a network
• Keystroke logging, screenshot capture, and process enumeration
• Executing shell commands and dropping additional payloads
• Suppressing display output to hide activity from the user at the keyboard
• Clearing Windows Event logs to remove traces of post-compromise actions

For data collection it specifically targets Skype, Google Chrome, Mozilla Firefox, 360 Secure Browser, 360 Speed Browser, and Tencent QQ Browser — a browser and messaging lineup that fits the group's history against finance targets in the Asia-Pacific region. The event-log clearing matters for your investigators: if the RAT wipes logs, timeline reconstruction depends on network telemetry and EDR data rather than host logs alone.

Lineage and related tooling

The behavior overlaps with a payload QiAnXin documented in 2020 tied to gambling-industry attacks running since 2019, and with the Zhong Stealer family ANY.RUN described in February 2025. Related campaigns attributed to the broader group have used RONINGLOADER, a multi-stage loader that pushed a Gh0st RAT variant through NSIS installers posing as Google Chrome and Microsoft Teams.

CylindricalCanine now sits alongside Black Basta, TamperedChef (EvilAI), and Rhysida as groups that abuse code-signing certificates. The shared payoff is the same: malware signed with a valid certificate from a recognized CA clears static reputation checks and trust prompts that would otherwise flag an unsigned binary, so the file runs with fewer warnings and buys the operator dwell time before anyone looks closer.

Financial Services, Gambling, and Web3 Sector Exposure

The finance, gambling, gaming, and Web3 sectors share three traits that make them attractive to CylindricalCanine: they move money quickly, they operate customer-support functions that accept inbound files from strangers, and they hold credentials that unlock direct financial access. That last point matters because the group's payload, Zhong Stealer, is built to harvest exactly those credentials.

Zhong Stealer pulls saved logins, session tokens, and stored data from browsers and messaging apps commonly used by support staff in these industries. If you run a gaming platform or a crypto exchange, a stolen session token for an admin console or a payment dashboard lets an attacker act as your own employee. There is no password prompt to trip an alert, because the session is already authenticated.

The reason support teams are the entry point is structural. Your finance and Web3 support desks are paid to open attachments, click links, and view "screenshots" that customers send. That workflow is the attack surface, and it is one you cannot fully close without breaking the business function.

Here is what a credential-theft event costs you across these sectors:

• Account takeover and fraudulent transfers. In finance and Web3, stolen credentials translate directly into moved funds. Reversing a bank wire is difficult; reversing an on-chain transaction is generally impossible.
• Ransomware follow-on. Groups such as Black Basta and Rhysida are documented in the same reporting as abusers of stolen code-signing certificates. Signed malware that your endpoint tools trust makes an eventual encryption event harder to stop, and recovery means downtime plus data-restoration work.
• Data exfiltration. Customer records, KYC documents, and wallet data are high-value in these sectors and expensive to notify on.

The compliance burden lands differently depending on which sector you sit in. If you are a publicly traded financial firm, the SEC's cyber-disclosure rules require you to report a material incident on Form 8-K within four business days of determining materiality. A credential breach that exposes customer accounts often clears that bar.

If you operate a licensed gaming or gambling business, state gaming commissions impose their own breach-notification and audit requirements, and a signed-malware compromise can trigger a review of your license conditions. State data-breach laws add per-resident notification duties on top of that, regardless of sector.

For Web3 entities, the exposure includes OFAC sanctions risk. If funds drained through a takeover flow to a sanctioned address or mixer, you can face secondary liability for handling sanctioned proceeds even when you were the victim. That is a separate legal track from the breach notification itself.

The reputational damage is specific to how these sectors earn trust. Customers hand a crypto exchange or an online gaming operator direct custody of their money and identity documents. When those customers learn their credentials were taken through your support channel, many move to a competitor, and acquiring replacement customers in regulated finance costs more than in most industries.

The through-line is that one clicked file at a support desk can produce fraudulent transfers, a regulatory filing clock, a possible sanctions question, and customer attrition at the same time. Each of those is a separate cost center, and in these four sectors they tend to arrive together.

Detection and Response for Code-Signed Malware

The most urgent action is to check whether any of the 60 revoked certificates touch your environment. DigiCert revoked certificates issued under four intermediate CAs, including DigiCert Trusted G4 Code Signing RSA4096 SHA256 2021 CA1 and Verokey High Assurance Secure Code EV. Pull the current Certificate Revocation List (CRL) and confirm your endpoint verification tools honor it, because software signed with a revoked certificate that your systems still trust will run without warnings.

Identify

Start by inventorying every EV Code Signing certificate order your organization placed with DigiCert or its resellers, including GoGetSSL and Verokey issuance. If you had an approved order pending delivery in early April 2026, treat that certificate as potentially compromised and request reissuance under a new key.

Catalog which internal systems trust code signatures automatically. Any application allowlist that trusts a publisher name rather than a specific certificate thumbprint is a gap, since a stolen certificate reuses a legitimate publisher identity.

Protect

Move your application allowlisting from publisher-based rules to certificate-thumbprint or hash-based rules. This narrows trust to the exact keys you expect, so a signature from a revoked or stolen certificate no longer satisfies the policy.

• Enforce code-signing validation inside your CI/CD pipeline, rejecting any build artifact signed by a certificate outside your approved thumbprint list.
• Audit software procurement so third-party binaries are verified against the vendor's published certificate details before deployment.
• Restrict which support or helpdesk workstations can open inbound files, and block execution of .scr attachments delivered through chat or ticketing channels.

Detect

Behavioral hunting matters more than signature matching here, because the malware carries valid signatures. Hunt for the multi-stage loader behavior: a legitimate signed executable loading an unexpected DLL from the same directory, followed by reads of an encrypted payload file such as update.log.

• Process creation: flag trusted binaries spawning from user-writable or temporary paths, a hallmark of the DLL side-loading chain used to launch the final payload.
• Network beaconing: watch for outbound connections that establish a SOCKS proxy tunnel, and for callbacks after a decoy PDF displays an HTTP 503 error to the user.
• Registry persistence: review autorun keys and scheduled tasks created shortly after a support workstation opens an attachment.
• Data-collection targeting: alert on processes reading credential stores for Skype, Google Chrome, Mozilla Firefox, 360 Secure Browser, 360 Speed Browser, and Tencent QQ Browser.
• Log tampering: the final payload can clear Windows Event logs, so treat unexplained log gaps as an indicator, not an accident.

Because this activity abuses stolen credentials and legitimate authentication paths, identity monitoring closes the gap that endpoint signatures miss. In environments Capstone manages, Adlumin flags authentication anomalies — logins from unexpected sources, session-token reuse, and access to accounts a support analyst would not normally touch — that indicate a compromised workstation is being used to reach further into your network.

Respond

If you find a code-signed sample tied to this activity, assume it is not a lone artifact. The payload can log keystrokes, take screenshots, run shell commands, and drop further tools, so treat any confirmed hit as a signal of active credential theft and possible lateral movement.

Possession of an initialization code, combined with an approved order, was "functionally sufficient" to obtain EV Code Signing certificates — meaning the trust boundary failed before any malware ran.

Prioritize rotating credentials for the affected accounts, revoking active session tokens, and isolating the impacted host from the network. Segment the systems the compromised workstation could reach, since the SOCKS tunnel gives the actor a path deeper into internal resources.

Recover

Reissue any affected code-signing certificates under freshly generated keys and confirm the old ones remain revoked across your distribution channels. Validate that restored systems boot from clean images rather than backups taken after the intrusion window, and confirm event logging is intact before returning hosts to production.

Vendor Risk and Certificate Management Implications

When a certificate authority like DigiCert is compromised, the damage does not stop at DigiCert. Every organization that relies on its certificates to establish software trust inherits a piece of the problem, because a valid signature from a recognized CA is the assumption your systems are built on.

The 27 certificates explicitly tied to the threat actor were used to sign Zhong Stealer artifacts. That means software carrying a legitimate DigiCert signature could be malicious, and your endpoint tools may have treated it as trustworthy at the time it ran.

This is the cascading part of the vendor risk. You did not have to be a direct DigiCert customer to be exposed—if a software vendor in your supply chain had one of the affected EV Code Signing orders, any binary they shipped during the exposure window carries the same question mark. Your due diligence now extends past your own certificate inventory into the signing practices of every vendor whose code runs in your environment.

The operational burden lands on your security team in three concrete ways:

• Re-evaluating trusted authorities. A breach at one of the largest CAs forces a review of which intermediate CAs you implicitly trust and whether your verification tooling can distinguish a revoked certificate from a valid one in practice, not just in policy.
• Certificate transparency monitoring. Tracking what certificates are issued against your organization's name and orders becomes an ongoing task rather than a one-time check, because the abuse here involved orders that were approved but pending delivery.
• Remediation if malware was distributed. If a signed binary that traces back to one of the affected CAs reached your systems or your customers, you face incident scoping, disclosure decisions, and re-issuance of your own signing certificates.

The financial exposure scales with distribution. If you shipped software signed under a compromised order to customers, remediation is not a single patch—it is re-signing, re-releasing, and communicating to everyone who installed the affected build. For a software vendor, that touches product, legal, support, and customer trust at the same time.

The root of this incident is instructive for how you assess any vendor. DigiCert stated that its threat model did not account for a compromised analyst account viewing initialization codes through a legitimate portal function.

"The threat model did not account for the scenario in which initialization codes stored within DigiCert's internal support portal could be viewed by a compromised DigiCert analyst account operating through the portal function," the company explained.

That admission is the kind of detail worth expecting from every critical vendor. When you evaluate a CA or any provider that issues trust artifacts on your behalf, ask how insider and support-account compromise is modeled, not just external attack surface. The abuse here came from a feature working exactly as designed—support staff impersonating customers—turned against the customers it was meant to help.

Communication expectations follow the same logic. DigiCert disclosed the incident, named the four issuing CAs, published the revoked certificate count, and described the code change it deployed to mask initialization codes from proxied users. That level of specificity is what you should require from downstream software vendors as well: which certificate, which build, which window, and what they have changed. A vendor that revokes a certificate without telling you which of their products signed with it leaves you unable to scope your own risk.

Treat this event as a prompt to formalize what you demand from vendors in writing—disclosure timelines, the scope of information they will share after a signing compromise, and their obligation to re-issue and re-sign affected products. Those terms determine how fast you can respond the next time a trust anchor fails.

Immediate Actions for Finance, Gaming, and Web3 Organizations

The single most important action is to hunt for Golden Gh0st RAT execution on any endpoint that handles inbound files from external contacts — your support desks, chat operators, and account-management staff. This threat cluster delivers payloads through a DLL side-loading chain that runs a rogue DLL under a legitimate signed executable, then loads an encrypted payload named update.log. That is your primary detection anchor.

Identify

Inventory the applications this malware harvests from, because those are the highest-value hosts to check first. It targets stored data in Skype, Google Chrome, Mozilla Firefox, 360 Secure Browser, 360 Speed Browser, and Tencent QQ Browser.

For finance and gaming operators in the Asia-Pacific region, prioritize workstations where support staff review customer submissions. The delivery method — files disguised as screenshots inside phishing emails or ticketing submissions — means your customer-facing teams are the entry point, not your server infrastructure.

Protect

Block .scr executables and password-protected archives at the mail gateway and any chat file-upload path. The initial payloads arrive as embedded links that pull additional stages from an external server, so restrict outbound connections from support workstations to known destinations where your workflow allows it.

Enforce application allow-listing on those same hosts. Because the attack abuses a legitimate executable to sidload a malicious DLL, signature-based blocking alone will miss it — you need to control which DLLs load from which directories.

Detect

Focus your EDR and Sysmon telemetry on the behaviors that define this chain rather than static file hashes, which change across campaigns.

• DLL side-loading — alert on Sysmon Event ID 7 (image load) where a signed binary loads an unsigned or unexpected DLL from a user-writable path such as a temp or download folder.
• Decoy activity — a PDF displaying an HTTP 503 "Service Unavailable" error opening alongside a new process is a distinctive marker of this loader.
• Encrypted payload staging — file creation or read events referencing update.log near process-injection activity.
• RAT capabilities in action — SOCKS proxy tunnel setup, keystroke logging, screenshot capture, process enumeration, and Windows Event log clearing (Event ID 1102) as an anti-forensic step.

SentinelOne flags the side-loading and log-clearing behaviors described above across managed environments, catching the execution chain even when the loading executable carries a valid signature. Feed your network IDS with signatures for the outbound stager downloads and the SOCKS tunnel to give you a second detection layer.

Respond

If you find any of these indicators, isolate the host and preserve memory before rebooting, since Golden Gh0st RAT operates through in-memory plugins and an internal module dispatcher that may not persist to disk. Pull authentication logs for every account used on that workstation and treat browser session tokens and saved credentials as compromised.

Notify your incident response and compliance teams the same day. For Web3 and gaming platforms, check admin console and privileged-account access logs for logins that reuse stolen session tokens — that is the follow-on activity this cluster pursues after credential theft.

Recover

Rotate credentials and invalidate all active sessions for any confirmed-compromised account, then rebuild affected workstations from a known-good image rather than cleaning in place. Given the malware's ability to drop additional payloads and clear its own tracks, a compromised host cannot be assumed clean after removal of a single artifact.

If your investigation confirms customer data exposure, prepare notifications on the timeline your regulators require. Finance and gaming operators typically face sector-specific reporting obligations, and starting that process early keeps you inside those windows.