On March 29, 2023, CrowdStrike and SentinelOne independently flagged a digitally signed, legitimate application quietly beaconing to attacker infrastructure: 3CX's DesktopApp, a VoIP/PBX client used by roughly 600,000 companies and 12 million daily users worldwide. The trojanized installer — versions 18.12.407 and 18.12.416 for Windows, and 18.11.1213 for macOS — had been built and signed inside 3CX's own pipeline after North Korea-linked operators, tracked by Mandiant as UNC4736 and by CrowdStrike as Labyrinth Chollima, compromised the company's build server. Mandiant later called it the first documented case of one software supply chain attack cascading directly into a second: attackers got into 3CX by first compromising Trading Technologies' X_TRADER application, which a 3CX employee had installed on a personal computer. This is what happened, how it happened, and what it means for anyone shipping or consuming signed software.
What happened in the 3CX supply chain attack?
Attackers modified 3CX's official Windows and Mac DesktopApp installers to load malware, and every customer who downloaded or auto-updated the app between roughly February 3 and March 29, 2023 received a signed, trojanized build. The Windows Electron client side-loaded two malicious DLLs — ffmpeg.dll and d3dcompiler_47.dll — that decrypted a hidden payload embedded in the executable itself, a technique that let the malware ride inside files with legitimate names and valid 3CX code-signing certificates. Because the binaries were properly signed and the update came from 3CX's real update servers, endpoint detection tools and most antivirus engines had no reason to block it. 3CX pulled the Windows installer, told customers to uninstall it entirely, and temporarily redirected users to a browser-based PWA client while it rebuilt its pipeline — a response that took the company roughly a week of active customer-facing remediation after public disclosure.
How did attackers first get into 3CX's network?
They didn't start with 3CX at all — they started with Trading Technologies' X_TRADER financial software, which a 3CX employee had installed on a personal computer in April 2022, more than a year before the malicious installers shipped. X_TRADER had been officially decommissioned by Trading Technologies in April 2020 but remained downloadable from its website until 2022, and a trojanized copy signed with a code-signing certificate was distributed to victims during that window. Because the employee used that same personal machine to connect to 3CX's corporate network over VPN without multi-factor authentication, the attackers rode that single credential straight into 3CX's internal environment. Mandiant, hired by 3CX to investigate, found evidence the intrusion began around December 2022 and escalated to compromising both the macOS and Windows build environments by February 2023 — meaning attackers had roughly two to three months of undetected lateral movement before they touched the build pipeline that produced customer-facing software.
How did malware get embedded in a signed, legitimate installer?
Attackers compromised 3CX's build infrastructure directly and inserted their payload during the compile step, so the resulting binaries were signed with 3CX's own legitimate certificate and passed every standard integrity check. On Windows, the loader hid inside ffmpeg.dll, decrypting an encrypted, obfuscated blob appended to the file rather than dropping a separate, more detectable payload to disk. The malware — dubbed ICONIC Stealer — then reached out to GitHub, pulling icon files from a repository where the actual command-and-control URLs were hidden using steganography inside the image data, a step designed specifically to blend malicious network traffic in with normal-looking requests to a trusted domain. Kaspersky later found that a small subset of infected machines, fewer than 10 in their telemetry and concentrated at cryptocurrency companies, received a second, more capable backdoor called Gopuram, indicating the attackers selectively escalated access only against specific targets of interest rather than every one of the hundreds of thousands of installs.
Who was behind the attack and what did they want?
CrowdStrike and Mandiant both attributed the operation to North Korea-nexus actors, with CrowdStrike naming the cluster Labyrinth Chollima — a subset of the Lazarus Group — and Mandiant tracking it as UNC4736. The presence of the Gopuram backdoor, previously observed in a 2020 breach of a cryptocurrency company, combined with the selective targeting of crypto-focused victims for second-stage payloads, points to a financially motivated espionage operation consistent with North Korea's well-documented pattern of using cyber operations to generate revenue for the regime. Unlike opportunistic ransomware crews, this actor showed patience: roughly a year elapsed between the initial X_TRADER compromise and the 3CX installer going live, and the operators deliberately limited follow-on payloads to a handful of high-value targets to avoid burning the operation before it was fully exploited.
Was a CVE ever assigned to the 3CX compromise?
No — this incident was never assigned a single CVE identifier, because it was a build-pipeline and code-signing compromise rather than a discrete software vulnerability in a shipped product. That distinction matters operationally: vulnerability scanners that key off CVE databases had nothing to match against, so organizations had to rely on IOC lists (malicious hashes, the GitHub steganography repo, and specific C2 domains published by CrowdStrike, SentinelOne, and Mandiant) and behavioral detection instead. CISA and industry vendors published joint advisories describing the affected installer hashes and versions, but teams that depend solely on CVE-driven patch management had no queryable record to trigger remediation — a gap that became one of the incident's most cited lessons for the industry.
What should organizations do differently after 3CX?
Organizations should verify build provenance and binary integrity independently of code-signing certificates, because this incident proved a valid signature is not proof of a clean build. 3CX's own fix involved rebuilding its pipeline with hardened access controls, network segmentation between developer and build environments, and mandatory MFA on all remote access — controls that would have stopped the attack at the X_TRADER-to-VPN pivot months before any customer installer was touched. Every organization that had 3CX DesktopApp deployed also had to answer a harder question fast: which internal systems and services actually ran the compromised binary, on which hosts, and were any of those hosts network-adjacent to sensitive data or crypto infrastructure — a question most asset inventories and CMDBs weren't built to answer in hours rather than days.
How Safeguard Helps
Safeguard is built for exactly this failure mode: a trusted, signed component turning malicious after the fact. Our SBOM generation and ingest pipeline gives teams a queryable record of every 3CX-style dependency and application binary in their environment, so when an incident like this breaks, you can answer "where do we have this and in what version" in minutes instead of days, even without a CVE to search against. Reachability analysis then narrows that list to the systems where the compromised code path is actually invoked, cutting through inventory noise to show real exposure. Griffin AI correlates emerging threat intelligence — IOCs, malicious hashes, C2 indicators — against your live SBOM and codebase automatically, flagging affected assets before a formal advisory even lands. And where remediation is needed, Safeguard's auto-fix PRs push the vetted, clean version or removal directly into your repositories, closing the gap between detection and action.