On March 29, 2023, CrowdStrike and SentinelOne disclosed that the 3CX DesktopApp, a softphone used by roughly 600,000 organizations and 12 million daily users, was shipping trojanized builds signed with a legitimate 3CX Ltd. certificate. Mandiant's follow-on investigation, published April 20, 2023, traced the intrusion further back than any previous supply chain event: the initial compromise was a different trojanized installer, X_TRADER from Trading Technologies, that a 3CX engineer had personally installed in 2022. That makes 3CX the first publicly confirmed cascading supply chain attack, where malware from one compromised vendor planted the beachhead used to compromise a second vendor. This post walks through what the attackers did, what 3CX missed, and what every ISV building desktop clients should change in response.
How did the trojanized 3CX installer actually work?
The trojanized 3CX installer worked by sideloading a malicious ffmpeg.dll that decrypted shellcode stored inside an unsigned overlay of d3dcompiler_47.dll. The loader, dubbed TAXHAUL by Mandiant and SUDDENICON by CrowdStrike, fetched a second-stage payload from an icon file hosted in a GitHub repository. That repository, MsftGithubAccount/icon, held base64-encoded command-and-control addresses appended after a magic byte sequence. The final payload, ICONICSTEALER, harvested browser data from Chrome, Edge, Firefox, and Brave, looking specifically for cryptocurrency exchange credentials. A Mac variant dropped a payload named UpdateAgent signed with a different Apple developer ID, confirming cross-platform tooling.
What do we know about the attacker?
Attribution pointed to UNC4736, a cluster tracked by Mandiant with overlaps to the Lazarus Group (DPRK, specifically the Labyrinth Chollima subcluster). CrowdStrike separately tracked the activity as LABYRINTH CHOLLIMA. The overlap with Operation AppleJeus, the long-running DPRK campaign targeting cryptocurrency firms, and the ICONICSTEALER focus on exchange data are consistent with North Korean state-sponsored revenue generation. The X_TRADER installer used for initial access had itself been compromised back in 2022, even though Trading Technologies had discontinued the product in April 2020; the download page was still live and still trusted by finance and trading professionals.
How did the attacker get into 3CX's build pipeline?
The attacker got into 3CX's build pipeline by moving laterally from a single engineer's workstation to an internal build server and then modifying the Electron build scripts that produced the Windows and macOS installers. According to Mandiant's report, the engineer had downloaded X_TRADER from Trading Technologies' website, ran it on a 3CX-managed laptop, and unknowingly installed VEILEDSIGNAL, a modular backdoor. From there the attacker stole corporate credentials and accessed the DesktopApp build environment. Between March 13 and March 26, 2023, every Electron installer 3CX shipped was trojanized and signed with 3CX's valid Sectigo code-signing certificate. The builds passed 3CX's own integrity checks because the signing was genuine.
What did 3CX miss that reproducible builds would have caught?
3CX missed the out-of-band modification of ffmpeg.dll in the final artifact, which a reproducible build pipeline would have caught immediately. Electron apps pull dozens of DLLs into the final bundle; without a deterministic, byte-for-byte rebuild comparison between the CI pipeline and an independent builder, a malicious file substituted after build time is undetectable from the signing step alone. SLSA Level 3, which requires build provenance that attests to the exact source and dependencies used, would have produced an attestation that did not match the shipped binary. The industry had been discussing SLSA throughout 2022; 3CX had not yet adopted it.
# Example SLSA provenance attestation fragment
predicateType: https://slsa.dev/provenance/v1
predicate:
buildDefinition:
buildType: https://github.com/slsa-framework/slsa-github-generator/...
externalParameters:
source: git+https://github.com/3cx/desktopapp@refs/tags/v18.12.416
internalParameters:
runnerEnvironment: github-hosted
How should downstream defenders have responded?
Downstream defenders should have, and in most cases did, kill the 3CXDesktopApp process, uninstall vulnerable versions (18.12.407, 18.12.416 on Windows; 18.11.1213, 18.12.402, 18.12.407, 18.12.416 on macOS), and hunt for outbound traffic to the published C2 domains. CISA added the 3CX bug to the Known Exploited Vulnerabilities catalog on April 6, 2023. Beyond the IR basics, the actionable takeaway is to scrutinize every trust-chain collapse: a trojanized installer signed with a genuine certificate breaks EDR baselines that allowlist by publisher. Treat the set of signed publishers as a dynamic risk inventory, not a static allowlist, and subscribe to vendor security advisories as a telemetry source.
What changes did 3CX and the ecosystem make?
3CX engaged Mandiant, rotated certificates, rebuilt its infrastructure on hardened images, and added reproducible build checks and an internal security operations center by mid-2023. Electron maintainers published guidance on hardening DLL resolution, and CISA referenced 3CX in its Secure by Design whitepaper released in April 2023. Industry-wide, the breach accelerated conversations about SLSA adoption, TPRM practices for desktop-app ISVs, and the need for SBOMs that include binary-level attestations, not just manifest-level dependencies. Customers started asking for evidence of signed provenance and deterministic builds in RFP cycles that previously ended at "do you scan your code?"
How Safeguard Helps
Safeguard treats installers, DLLs, and transitive binary artifacts as first-class SBOM components, so a substituted ffmpeg.dll in a downloaded 3CX build would flag against the signed attestation. Griffin AI reads vendor advisories in real time, correlates trojanized-version identifiers against your endpoint inventory, and drafts IR runbooks specific to the affected product family. The TPRM module tracks vendor signing-certificate incidents and surfaces cascading risk when a supplier discloses a compromised dependency chain. Reachability analysis then narrows the blast radius to processes that actually load the malicious module, and policy gates prevent any CI pipeline from consuming a vendor artifact whose provenance does not match the published SLSA attestation. These controls shorten the typical 3CX-style detection window from weeks to hours.