In March 2023, the VoIP vendor 3CX — whose desktop softphone is used by an estimated 12 million people daily across more than 600,000 organizations — shipped a trojanized version of its own application through its official update channel. What made the incident historic was its origin: 3CX was breached because one of its employees had installed trojanized trading software. It is the first publicly documented case of one supply chain attack directly causing another, later attributed to North Korea's Lazarus Group.
What happened: a timeline
- 2022: North Korean actors trojanize X_TRADER, software from Trading Technologies, distributed through its legitimate site.
- 2022: A 3CX employee installs the trojanized X_TRADER on a personal device; the attackers pivot to 3CX corporate credentials and eventually to its build environment.
- Around March 2023: The attackers arrange for malicious components to be built into the 3CX Desktop App.
- March 9-29, 2023: Trojanized versions are distributed via 3CX's official update mechanism.
- March 22, 2023: Endpoint vendors including CrowdStrike and SentinelOne flag suspicious behavior from the 3CX app.
- March 29-30, 2023: Public disclosure; 3CX acknowledges the compromise.
How the attack worked
Like SolarWinds, the source repository was not the target — the build process was. The attackers did not obviously alter 3CX's source; they arranged for the build to bundle malicious components: a trojanized ffmpeg.dll and a d3dcompiler_47.dll carrying an encrypted payload. Because 3CX's real build system produced the app, it was signed with 3CX's legitimate certificate and passed signature checks.
At runtime the malware ran a multi-stage chain: the trojanized DLL decrypted a payload, pulled a list of URLs pointing at GitHub-hosted icon files, and extracted command-and-control addresses hidden inside those icons. Using GitHub as command-and-control let the traffic blend into normal developer activity. A roughly seven-day sleep timer delayed beaconing to frustrate correlation. The final stage was an information stealer targeting browser data.
Impact
Trojanized Windows and macOS builds were distributed for about three weeks before detection. With a potential exposure of 600,000-plus organizations and 12 million daily users, the reach was enormous, though the attackers appear to have focused follow-on activity on specific sectors, including cryptocurrency firms — consistent with North Korea's revenue-generation pattern. The cascade — X_TRADER to 3CX to 3CX's customers — is the defining lesson.
The concrete lessons
Supply chain attacks compound. A compromise of one vendor became the entry point to another, which amplified into 3CX's entire customer base. Your risk includes not just your dependencies, but your dependencies' suppliers and the tools your own staff install.
Endpoint and developer hygiene is supply chain security. The initial foothold was unauthorized trading software on a device with a path to corporate credentials. Device controls, credential isolation, and least privilege for build access are not separate from supply chain defense.
Signatures do not equal safety. For the second time in three years (after SolarWinds), a validly signed, vendor-built binary was malicious. Signing proves origin, not intent.
Behavioral detection matters when provenance fails. What ultimately surfaced 3CX was endpoint tooling noticing the app doing things a softphone should not — reaching odd URLs and spawning unexpected processes.
How a platform like Safeguard would have helped
The honest position: Safeguard would not have detected Lazarus modifying 3CX's build outputs before disclosure, any more than it would have caught SolarWinds' SUNSPOT. Detecting a trojanized vendor binary at the moment of release is a build-integrity, provenance, and endpoint-behavioral problem — not something a dependency scanner claims.
Where a platform like Safeguard reduces blast radius is downstream and after the signal. Comparing bills of materials across builds is how you notice that new, unexpected components — like injected DLLs — appear where they should not, and Safeguard's software composition analysis maintains the component inventory that makes "which of our systems run the affected 3CX versions" an instant query rather than a fire drill. Because the affected app and countless other third-party tools reach production packaged inside images, container image scanning inventories what is actually baked into each artifact. When a clean version exists, automated fix pull requests speed the move off the compromised release, and Griffin AI helps prioritize which exposed deployments to address first based on reachability and context. If you are weighing how that response model compares to legacy scanners, our tool comparison walks through the differences.
The 3CX cascade proved that you must have visibility not only into your own build, but into the chain of software your organization and your suppliers depend on — and that when prevention at a vendor fails, fast inventory and patching are what contain the damage.
Frequently Asked Questions
What made the 3CX attack historically significant? It is the first publicly documented instance of one supply chain attack directly enabling another. 3CX was breached because an employee installed trojanized X_TRADER software; that foothold led to 3CX's build environment, which led to trojanized 3CX updates reaching hundreds of thousands of organizations. The cascade is what set it apart.
How was the trojanized 3CX app signed and still malicious? Because 3CX's own compromised build system produced it. Code signing proves an artifact came from the expected build pipeline; it says nothing about whether that pipeline was subverted. The app carried a valid 3CX signature and still shipped malware, which is why signature checks alone are insufficient.
Who was behind the 3CX attack? Multiple security firms attributed it to the Lazarus Group, a threat actor linked to North Korea, based on infrastructure and code overlaps with prior Lazarus operations and the actor's established pattern of targeting financial and cryptocurrency organizations for revenue.
How can organizations defend against cascading supply chain attacks? Extend your risk view beyond direct dependencies to your suppliers' suppliers and the tools your staff install; isolate and least-privilege build and credential access so one compromised device cannot reach the build system; maintain accurate software inventory so you can find affected versions instantly; and pair provenance controls with behavioral detection for when signed artifacts turn out to be malicious.
Get started at app.safeguard.sh/register, and find integration guides at docs.safeguard.sh.