← Back to list

Behind the breach: 3CX Breach

At the start of 2023, 3CX had every reason to feel like a company on the right side of the software supply chain conversation. The…

Dorathy Christopher · 2026-07-27 13:18 · 0 claps · 9.0 min read
#cybersecurity #behind-the-breach-series #3cx #supply-chain #data-breach
Open on Medium ↗
Wiki topics: MAC · Macroeconomics 🔒 · Cybersecurity 🚆 · Urban & Transport

Behind the breach: 3CX Breach

At the start of 2023, 3CX had every reason to feel like a company on the right side of the software supply chain conversation. The Cyprus-based firm sold VoIP and unified communications software to more than six hundred thousand businesses worldwide, twelve million users routing calls and video meetings through a desktop app most of them had never thought twice about. The app updated itself quietly, the way modern software does. Nobody at 3CX’s customer base was checking hashes on every push. Nobody had reason to.

Somewhere behind that quiet update mechanism, a compromise had already been sitting for months. It did not begin inside 3CX at all. It began a year earlier, in February 2022, when a completely different company’s website was tampered with: Trading Technologies, maker of a financial trading platform called X_Trader. Google’s Threat Analysis Group would later trace that compromise to a North Korean operation known as AppleJeus, a campaign built around stealing cryptocurrency by trojanizing the software that traders and finance professionals actually used. Trading Technologies had discontinued X_Trader by 2020, but a version of it was still sitting on the company’s website in 2022, available to download. Someone at 3CX downloaded it.

That is the detail that makes this case unusual, and it is worth sitting with before the rest of the story unfolds. This was not one supply chain attack. It was two, stacked on top of each other, the second one only possible because the first had already succeeded and gone unnoticed.

The 3CX employee who installed the trojanized X_Trader software had no way of knowing what they were carrying into the corporate network. X_Trader looked legitimate because, apart from the malicious code stitched into the installer, it was legitimate. It had a real signing history, a real user base, a real reason to exist on a finance professional’s machine. Once it ran, it gave the operators behind it a foothold on an internal 3CX system, and from there they had the runway to do the patient work that state-linked operators do well: move laterally, learn the environment, and find their way into the part of the network that mattered most, the software build pipeline.

By early 2023, that pipeline was compromised. Mandiant, brought in later by 3CX to lead the incident response, would describe this as the first time the firm had seen a software supply chain attack lead directly into a second one. The attackers were not just sitting on a machine somewhere inside 3CX. They had reached the place where 3CX’s own product got built and signed before going out to customers. Malicious code went into both the Windows and macOS builds of the 3CX Desktop App, and 3CX’s own infrastructure pushed it out under the company’s own valid code-signing certificate, through Update 7 of the desktop app in March 2023.

Security vendors caught it faster than 3CX did, which is its own kind of embarrassing footnote in the story. SentinelOne’s telemetry started flagging 3CXDesktopApp activity as early as March 22, taking automated block actions against instances of the app without yet knowing why they looked wrong. A week of quiet followed, the kind of week where an anomaly sits in a queue getting triaged against a hundred other anomalies. Then, on March 29, CrowdStrike posted publicly, attributing the activity to a cluster it tracks as Labyrinth Chollima and describing an active intrusion campaign running through the 3CXDesktopApp across both Windows and macOS. Sophos, Volexity, and others published their own independent analyses within the next day, and on March 30, 3CX confirmed what everyone was now converging on: its own product had been used against its own customers.

What the analysts were looking at, once they pulled the installers apart, was a deliberately restrained piece of engineering. The app’s update process launched an executable that pulled down a file named ffmpeg.dll, a library the app legitimately used for audio and video processing. In a typical DLL side-loading attack, a malicious library like this is a hollow shell, good for nothing except queuing up the real payload. This one was different. It was fully functional, doing everything the real ffmpeg.dll was supposed to do, with the malicious logic slipped quietly into its DllMain function so it would run automatically the moment the library loaded. Whoever built it wanted the app to keep working normally while it was being used against its own users.

That library then reached for a second file already sitting alongside it, d3dcompiler_47.dll, and searched inside it for a specific hexadecimal marker: FE ED FA CE. Finding it, the loader used an RC4 key to decrypt a hidden payload buried in that second file, a piece of shellcode with a DLL embedded inside it. The shellcode called an exported function to run that embedded DLL, and that DLL reached out not to a traditional command-and-control server, but to GitHub, downloading what looked like an ordinary icon file. It wasn't. The icon file carried an encoded configuration pointing to the real infrastructure the attackers wanted the malware to talk to. In some infections, this second-stage component simply went to sleep for more than a week before making contact, a patience move meant to slide past any analyst watching for activity in the first hours or days after infection.

At the end of that chain sat an infostealer researchers named ICONICSTEALER. Its job was unglamorous and effective: harvest system information and browser data from the infected machine and send it back to the attackers.

3CX’s own security team, working alongside Mandiant, gave customers a first attribution update on April 11. The assessment at that point was that the intrusion traced to a cluster Mandiant tracked as UNC4736, assessed with high confidence to have a North Korean nexus, using malware Mandiant called TAXHAUL. That matched what CrowdStrike had already said publicly under its own naming convention, and it lined up with independent findings from Kaspersky and Elastic Security, each of whom had reached a Lazarus attribution on their own. Sophos added a detail that mattered less for headline purposes and more for forensic confidence: the shellcode loader used in the 3CX intrusion was a byte-for-byte match to loaders Sophos had only ever previously seen in incidents already attributed to Lazarus. Not every firm signed on to the same label. Volexity, working from its own visibility into the malicious installers, said it could not independently map the activity to a known threat actor and tracked it separately as UTA0040, a reminder that convergence among several serious research teams is not quite the same thing as universal agreement.

The full picture came together on April 20, when Mandiant published its complete findings and connected the two halves of the story. The initial compromise vector inside 3CX’s own network traced back to that one employee and the trojanized X_Trader installer, itself a product of the Trading Technologies compromise from a year earlier. Two supply chain attacks, one feeding the other, months apart, invisible to 3CX the entire time it was happening inside its own build environment.

What the investigation could not answer as cleanly was scale of harm. Despite the installer’s reach into what 3CX described as its base of over six hundred thousand customers and twelve million users, journalists covering the story at the time noted that Mandiant’s own investigators described the actual impact as unclear, and Kaspersky’s telemetry suggested the attackers were selective about who they pursued past the initial infostealer stage, focusing further attention on a small number of cryptocurrency-related firms rather than acting on the full breadth of exposed customers. That distinction matters. A mass-distributed compromise and a mass-exploited one are not the same event, and the public record here supports the first far more firmly than the second. No verified figure exists for total confirmed victims, financial loss, or the number of organizations where the attackers moved beyond initial infostealer deployment. That gap belongs in the record rather than being smoothed over.

Containment and what came after

3CX pulled the compromised installers, published indicators of compromise, and worked with Mandiant to rebuild its build environment from the ground up rather than simply patching the one that had been compromised. That meant a dedicated, isolated build pipeline, expanded endpoint detection and response coverage across the company’s own infrastructure, stronger code-signing procedures, and a new internal security function the company described as its Network Operations and Security department. CISA issued a public advisory pointing enterprise defenders toward the confirmed indicators. For an organization whose entire product is trust in a communications tool running on hundreds of thousands of desktops, the reputational cost of a compromise delivered through your own signed update mechanism runs deeper than any single technical fix, and 3CX’s public response reflected that: not just remediation, but a visible rebuild of the process that failed.

What the case teaches

The detection that mattered here did not come from inside 3CX. It came from endpoint telemetry at customer organizations, security vendors watching a well-known, digitally signed application suddenly behave in ways signed applications aren’t supposed to behave: reaching out to GitHub for configuration data, sideloading a library that decrypted and executed shellcode, going quiet for days at a time before talking to infrastructure nobody recognized. That is the artifact worth building detection logic around, not the malware family or the specific hashes, both of which will be different next time. It is the behavior: a trusted, signed binary initiating outbound connections to code-hosting platforms, or a legitimate library loading a second file and searching it for hidden encrypted content, is a pattern that survives past any single campaign.

The control that was actually missing sat further upstream, in the part of the story that gets less attention than the malware itself. 3CX’s build pipeline lacked the kind of integrity verification that would have caught a compromised binary before it was ever signed and shipped, and the initial foothold traced back to a single employee’s machine running software from an unrelated vendor that had itself been silently compromised for a year. Neither of those is a gap you close by watching for infostealers. They are gaps you close by treating your own build environment as an asset worth its own dedicated monitoring, isolated from general corporate IT, and by recognizing that the software your employees install for unrelated work, on unrelated platforms, can become the first domino in a chain that ends with your own product turned into malware distribution infrastructure. The lesson of the 3CX breach is not really about VoIP software. It is about the distance between a single download on a single machine and the moment, a year later, when that download becomes the reason six hundred thousand customers have to ask whether they were compromised too.

Technical Appendix: MITRE ATT&CK Mapping

The following techniques are drawn from the forensically confirmed binary analysis published by CrowdStrike, SentinelOne, Sophos, Volexity, Kudelski Security, and Zscaler ThreatLabz, cross-referenced against Mandiant’s incident response findings. Where a mapping reflects analyst interpretation rather than a directly observed artifact, that distinction is noted.

T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain. This technique appears twice in the same intrusion, which is what makes the case notable. First in the 2022 compromise of Trading Technologies’ X_Trader installer, confirmed by Google’s Threat Analysis Group and tied to the broader AppleJeus campaign, and again in the 2023 compromise of 3CX’s own build pipeline, which allowed malicious code to be inserted into signed Windows and macOS installers before distribution.

T1204.002 — User Execution: Malicious File. The initial foothold traces to a 3CX employee executing the trojanized X_Trader installer. This detail comes from Mandiant’s investigation and has not been independently re-verified by other firms, since Mandiant held primary access to 3CX’s internal forensic evidence.

T1574.002 — Hijack Execution Flow: DLL Side-Loading. Forensically confirmed across multiple independent analyses. The 3CXDesktopApp update process loaded a trojanized but fully functional ffmpeg.dll, with malicious logic inserted into its DllMain function so execution began automatically on load, a deliberate departure from the hollow-loader pattern typical of most side-loading cases.

T1027 — Obfuscated Files or Information, including RC4 encryption of the second-stage payload embedded in d3dcompiler_47.dll, located via a hex-byte marker and decrypted at runtime. This is directly confirmed through reverse engineering by Zscaler ThreatLabz and other independent teams who recovered the specific decryption key and payload structure.

T1027.003 — Steganography, applied to the icon files hosted on GitHub, which carried encoded C2 configuration data disguised as ordinary image assets. This mechanism has been publicly documented across multiple vendor writeups and is treated here as forensically confirmed rather than assessed.

T1102 — Web Service. The malware’s use of GitHub as an intermediary C2 channel, rather than contacting attacker infrastructure directly, is confirmed through binary analysis and represents a deliberate evasion choice, blending malicious traffic into requests to a widely trusted platform.

T1497.003 — Time-Based Evasion. Some infected systems showed second-stage components sleeping for more than seven days before initiating C2 contact, a documented anti-analysis measure intended to outlast the typical window of heightened scrutiny following initial detection.

T1005 / T1217 — Data from Local System / Browser Information Discovery. ICONICSTEALER’s collection of system information and browser data is confirmed through static and dynamic analysis of the malware by multiple firms, including Sophos and ReversingLabs.

T1041 — Exfiltration Over C2 Channel. Harvested data was transmitted back to attacker-controlled infrastructure reached via the GitHub-mediated C2 mechanism described above.

Attribution to a North Korean state-nexus actor, tracked variously as UNC4736 (Mandiant), Labyrinth Chollima (CrowdStrike), and under the broader Lazarus umbrella (Kaspersky, Elastic), reflects convergent but not unanimous analyst assessment. Volexity, working from the same class of evidence, declined to attribute the activity to a known actor and tracked it independently. That disagreement is part of the record and is presented here as such, not resolved in favor of the majority view.


메타데이터
post_id
3bfbe4d5fe62
slug
behind-the-breach-3cx-breach-3bfbe4d5fe62
url
https://medium.com/@dorathychristopher/behind-the-breach-3cx-breach-3bfbe4d5fe62
canonical_url
https://medium.com/@dorathychristopher/behind-the-breach-3cx-breach-3bfbe4d5fe62
author_url
https://medium.com/@dorathychristopher
status
ok
fetched_at
2026-08-18 06:22:17