March 29, 2023 — 3CX, a VoIP and PBX software vendor whose desktop client is used by more than 600,000 companies and an estimated 12 million users daily, confirmed that its Windows and macOS DesktopApp installers had been trojanized and distributed with valid digital signatures. The compromise, later attributed to the North Korean state-sponsored group tracked as Labyrinth Chollima (a subset of Lazarus), stands as one of the clearest recent examples of a "supply chain attack on a supply chain" — a nested compromise where attackers breached one vendor's software to steal credentials, then used those credentials to poison the build pipeline of an entirely different vendor downstream.
Security vendors moved quickly. CrowdStrike, which first flagged anomalous beaconing from the signed 3CX binary, codenamed the campaign SmoothOperator. Mandiant, engaged by 3CX to lead the incident response, tracked the intrusion as UNC4736. Within days, 3CX CEO Nick Galea publicly advised all customers to uninstall the Electron-based desktop client entirely and switch to the PWA (browser-based) client until a clean build could be verified and reissued.
What Happened
The malicious activity was traced to two versions of the 3CX Windows Electron app — 18.12.407 and 18.12.416 — and a macOS installer, all signed with 3CX's legitimate code-signing certificate. Because the binaries carried valid Authenticode signatures and were served from 3CX's own update infrastructure, they sailed past traditional allowlisting, EDR trust heuristics, and signature-based antivirus checks that treat "signed by a known vendor" as a strong trust signal.
Once installed, the trojanized client executed a multi-stage infection chain:
- A malicious DLL (tracked as TAXHAUL, also called TxRLoader) was side-loaded by the legitimate 3CX process, decrypting an encrypted payload appended to an icon file (.ico) hosted on GitHub.
- That payload deployed a second-stage loader, ICONIC Stealer (also known as COLDCAT), which harvested system and browser information.
- In a smaller number of high-value cases, the actor deployed a third-stage backdoor, GOPURAM, previously linked to Lazarus Group activity against cryptocurrency companies — a strong attribution signal, since GOPURAM had been observed by Kaspersky in unrelated 2020 intrusions tied to the same actor.
The use of GitHub-hosted icon files to smuggle encrypted shellcode, combined with DLL side-loading off a legitimately signed parent process, was specifically engineered to blend into normal update traffic and evade static detection.
The Root Cause: A Supply Chain Attack Inside a Supply Chain Attack
The most consequential detail to emerge from Mandiant's investigation was not the malware itself but how the attackers got into 3CX's build environment in the first place. The intrusion did not start with 3CX. It started with a 3CX employee who had installed a legitimate but separately trojanized financial trading application, X_Trader, published by Trading Technologies, on a personal computer that was also used for work.
X_Trader had itself been compromised in an earlier, largely unnoticed Lazarus campaign and had been pulled from distribution in 2022 — but a version remained installed on the employee's machine well after that. The malware embedded in X_Trader harvested corporate credentials, which the attackers used to move into 3CX's network, eventually gaining access to both the Windows and macOS build pipelines. From there, they modified build scripts to inject the malicious loader directly into the compilation process, meaning the malicious code was compiled in and signed as part of 3CX's own legitimate, automated release process rather than being manually inserted into a finished binary after the fact.
This detail reframes the entire incident. It is not simply a case of "a vendor got hacked and pushed bad code." It is proof that a single upstream compromise (X_Trader) can cascade laterally into unrelated downstream vendors (3CX) through nothing more exotic than an employee's personal software choices, ultimately reaching millions of end users of a product that had no direct relationship to the original victim. Security teams evaluating third-party risk on the basis of "who do we have a vendor contract with" miss this transitive exposure entirely.
Why Signature-Based and Reputation-Based Defenses Failed
Three properties of this campaign specifically defeated the controls most organizations rely on for supply chain trust:
- Valid code signing. The malicious installers were signed with 3CX's real certificate because they were built by 3CX's real, but compromised, build infrastructure. Certificate validation confirmed authenticity of origin, not integrity of content — a distinction many detection stacks conflate.
- Legitimate distribution channel. The binaries were served from 3CX's own auto-update servers and website, so there was no anomalous download source to flag.
- Living-off-trusted-binaries. DLL side-loading through a signed, expected parent process is specifically designed to avoid the "unsigned/unknown process" heuristics that many EDR products use as a primary detection trigger.
In short, every artifact-level signal that security teams are trained to trust — a valid signature, a known publisher, an official update URL — was present and correct. Detection ultimately required behavioral analysis: outbound connections to attacker infrastructure, DNS requests to legitimate-looking but attacker-registered domains, and unusual GitHub traffic from an unexpected process.
Broader Implications for Software Supply Chain Security
The 3CX incident, alongside SolarWinds and the 3CX-adjacent X_Trader compromise itself, points to a pattern security teams should treat as the norm rather than the exception going forward:
- Build pipelines are now a primary attack surface, not an implementation detail. Compromising CI/CD infrastructure yields the attacker a legitimate signature and a trusted distribution channel in one move — a far higher return on investment than compromising individual endpoints one at a time.
- Transitive third-party risk compounds. Your vendor's vendor's employee's personal laptop is now inside your threat model, whether or not you have visibility into it.
- SBOMs and code-signing alone are necessary but not sufficient. An SBOM generated from a poisoned build will faithfully and accurately document a compromised binary. Signature validation confirms the signer, not the safety of what was signed. Both controls need to be paired with runtime and pipeline integrity monitoring to be meaningful.
- Detection needs to move up the stack. Waiting for endpoint telemetry to flag a malicious process is late in the kill chain; the more valuable choke point is visibility into what changed in the build and release pipeline itself, and whether a shipped artifact's actual behavior matches its declared components.
For any organization distributing desktop software at scale, 3CX is a direct case study in why build-environment segmentation, mandatory MFA on developer and build-service accounts, and independent verification of release artifacts against source are no longer optional hardening steps — they are baseline requirements.
How Safeguard Helps
Safeguard is built around the assumption that incidents like 3CX will keep happening, and that the fix is visibility deep enough to catch a compromise before it ships, not just detection after it lands on an endpoint. Safeguard's SBOM generation and ingest pipeline continuously tracks every component and build artifact across your software supply chain, so an unexpected change in a build's composition — like an injected loader DLL — surfaces immediately rather than silently propagating downstream. Reachability analysis goes further, correlating vulnerable or anomalous components against actual code paths so teams can prioritize the handful of changes that matter instead of drowning in noise from every dependency update. Griffin AI, Safeguard's investigative agent, is designed to reason through exactly this kind of nested attack chain — tracing a suspicious binary or credential-theft signal back through vendor and build relationships to surface transitive exposure that manual review would miss. And when a fix is identified, Safeguard's auto-fix PR workflow gets the remediation into your codebase and pipeline fast, shrinking the window between disclosure and containment that attackers like Labyrinth Chollima depend on.