The 3CX Supply Chain Attack: How North Korea Turned One Employee's Download Into 600,000 Compromised Installations

‍‌​‌‌‌​‌‌‌​​​‌​​‌​‌‌​‌​​‌‌​​‌​‌​​‌​‌​‌​‌‌​‌‌​​​‌​​​‌​‌‌‌​​‌‌​​‌​‌‍On 29 March 2023, CrowdStrike detected malicious activity coming from a legitimate, signed binary that hundreds of thousands of organisations trusted. The binary was 3CXDesktopApp, a Voice over Internet Protocol (VoIP) application used by over 600,000 companies worldwide. It had been quietly distributing malware to its own customers for weeks.

This wasn't a simple case of a compromised update server or a stolen code signing certificate. Mandiant's investigation, published on 20 April 2023, revealed something that had never been publicly documented before: a supply chain attack that triggered another supply chain attack. The attackers hadn't gone after 3CX directly. They'd compromised a completely different company first, used that foothold to reach a 3CX employee, and then pivoted from that employee's machine into 3CX's build infrastructure.

Four independent security vendors attributed the attack to the Lazarus Group, a North Korean state-sponsored threat actor with a documented history of targeting cryptocurrency companies. The final payload, deployed to fewer than ten machines worldwide, confirmed the financial motivation behind the entire operation.

What everyone thinks happened

The headlines framed the 3CX incident as a straightforward software supply chain attack: hackers got into 3CX, modified their software, and pushed malicious updates to customers. That version captures the outcome but misses the mechanism that made this attack historically significant.

The common assumption is that the attackers targeted 3CX directly, perhaps through phishing, a compromised credential, or an exploited vulnerability in 3CX's infrastructure. That isn't what the evidence actually shows. The attackers never targeted 3CX's systems as their primary objective. They targeted a completely separate company, Trading Technologies, which builds financial trading platforms. They compromised Trading Technologies' download infrastructure and waited for someone at 3CX to download their software.

The other common misconception is about scale. Because 3CX had over 600,000 customers and 12 million daily users, the assumption is that all of them were targeted. The reality is far more focused than that. The broad-deployment malware (ICONICSTEALER) collected browser data from infected machines, but the secondary payload (Gopuram) was deployed to fewer than ten machines. All of those machines belonged to cryptocurrency companies. The 600,000 customers were the blast radius. The actual targets were a handful of cryptocurrency firms.

What actually happened

The first supply chain compromise: Trading Technologies

The attack started not at 3CX, but at Trading Technologies, a Chicago-based company that builds electronic trading platforms. Their product X_TRADER had been officially decommissioned in April 2020. Trading Technologies stopped releasing updates and ended support. But the software remained available for download on their legitimate website at download.tradingtechnologies.com.

At some point before April 2022, the attackers compromised the Trading Technologies download infrastructure and replaced the X_TRADER installer with a trojanised version. The malicious installer, X_TRADER_r7.17.90p608.exe, was digitally signed with a valid code signing certificate issued to "Trading Technologies International, Inc." The signature was genuine because the attackers had compromised the build or distribution infrastructure, not just the download page.

In April 2022, a 3CX employee downloaded this trojanised X_TRADER installer onto a personal computer. The installer deployed VEILEDSIGNAL, a multi-stage modular backdoor written in C. VEILEDSIGNAL could execute shellcode, terminate itself, and inject a communication module into Chrome, Firefox, or Edge browser processes. It used AES-256 GCM encryption for command and control (C2) communication and Windows named pipes for communication between its internal modules.

The pivot to 3CX

Two days after the employee's personal computer was compromised, the attacker used stolen corporate VPN credentials to access 3CX's internal network. The credentials had been harvested by VEILEDSIGNAL from the employee's machine.

From the VPN entry point, the attackers moved laterally through 3CX's network using Fast Reverse Proxy (FRP), an open-source tool they disguised by naming it MsMpEng.exe (the filename used by Windows Defender) and dropping it into the System32 directory. They reached both the Windows and macOS build environments.

On the Windows build environment, the attackers deployed TAXHAUL, a Dynamic Link Library (DLL) launcher that persisted by hijacking the IKEEXT service through DLL search order manipulation. TAXHAUL ran with LocalSystem privileges and decrypted shellcode payloads stored at C:\Windows\System32\config\TxR\ using machine-specific identifiers. Alongside TAXHAUL, they deployed COLDCAT, a downloader that generated unique host identifiers and communicated with C2 infrastructure via HTTPS cookies using hardcoded variables __tutma and __tutmc.

On the macOS build environment, they used POOLRAT, a C/C++ backdoor capable of running arbitrary commands, securely deleting files, reading and writing files, and updating its own configuration. POOLRAT persisted through LaunchDaemons, a standard macOS mechanism for running background services.

The trojanised 3CX Desktop App

With access to both build environments, the attackers modified the build pipeline to inject malicious code into the 3CX Desktop App. The application is built on Electron, a framework that bundles web applications with the Chromium browser engine for desktop distribution. Electron applications routinely include ffmpeg libraries for media processing, which gave the attackers a convenient component to replace.

On Windows, the malicious MSI installer contained a modified ffmpeg.dll that had been compiled on 12 November 2022. When loaded by the legitimate 3CXDesktopApp.exe binary, this DLL read a second file, d3dcompiler_47.dll, and searched for the magic bytes "FE ED FA CE" (0xCEFAEDFE) within it. Those bytes marked the location of encrypted shellcode. The DLL decrypted the shellcode using RC4 with the key "3jB(2bsG#@c7" and executed it.

The attackers had embedded the payload into d3dcompiler_47.dll using SigFlip, a tool designed to inject data into signed Portable Executable (PE) files without invalidating their digital signatures. This meant that both the 3CX application binary and the d3dcompiler_47.dll file passed signature verification checks despite containing malicious payloads.

On macOS, the approach was considerably simpler and more direct. A malicious libffmpeg.dylib (4.7 megabytes, Mach-O binary) was placed at a specific path within the application bundle. Rather than fetching C2 addresses from GitHub like the Windows variant, this version contained 16 hardcoded C2 URLs encoded with a single-byte XOR key of 0x7A.

The sleep timer

The malware didn't activate immediately after installation. It generated a randomly selected date between one and four weeks in the future and slept until that timestamp was reached. This is documented as MITRE ATT&CK technique T1678 (Delay Execution).

The sleep timer served a critical evasion purpose. If the trojanised application installed on a Monday and malicious network traffic appeared two weeks later, the connection between the installation event and the suspicious activity would be far harder to establish. Automated sandboxes that analyse software for short periods would see nothing unusual. Endpoint detection tools looking for malicious behaviour immediately after installation would find a clean application doing exactly what it was supposed to do.

Command and control through GitHub

The Windows variant's C2 mechanism used GitHub as an intermediary. The shellcode downloaded .ico (icon) files from a GitHub repository at raw.githubusercontent.com/IconStorages/images/main/icon[1-15].ico. These icon files contained AES-GCM encrypted C2 server URLs. The decryption parameters were derived through a complex function rather than stored as static keys.

The GitHub repository was created on 7 December 2022, meaning the attackers had been staging infrastructure for at least three months before the attack was detected. Both the GitHub repository and the C2 domains were taken down on 30 March 2023, one day after CrowdStrike's public disclosure.

The C2 domains were registered through NameCheap, Public Domain Registry, and NameSilo using five distinct email addresses across Proton Mail and Gmail, each with unique WHOIS registration data. This operational security compartmentalisation made it harder to link the domains to a single operator through registration records alone. Twenty-one C2 domains were identified, including names designed to impersonate legitimate cloud services: akamaicontainer.com, azuredeploystore.com, msedgepackageinfo.com, and visualstudiofactory.com.

The payloads: broad collection and surgical targeting

The attack deployed two distinct payloads with very different objectives, and understanding the difference matters.

ICONICSTEALER was the broad-deployment payload, pushed to every machine that received the trojanised 3CX application. Compiled on 16 March 2023, it was a 64-bit Windows DLL designed to collect browser data from Chrome, Edge, Brave, and Firefox (limited to 500 history entries per browser). It also collected the hostname, domain name, and operating system version. ICONICSTEALER embedded a SQLite library to query browser databases directly and created backup copies of those databases before querying them to avoid corruption. CISA analysed this payload in Malware Analysis Report MAR-10435108-r1.v1 and confirmed it had no independent C2 capability, requiring a separate exfiltration module.

Gopuram was the targeted payload, deployed to fewer than ten machines total according to Kaspersky's analysis. Every one of those machines belonged to a cryptocurrency company. Kaspersky had been tracking Gopuram since 2020, when they first discovered it during an investigation into cryptocurrency theft in Southeast Asia. The Gopuram backdoor implemented nine in-memory modules covering filesystem manipulation, process manipulation, registry operations, service management, timestomping (altering file metadata timestamps), payload injection via syscalls, kernel driver utility for bypassing driver signature enforcement, network functionality, and additional command execution.

The selective deployment pattern is characteristic of nation-state operations. The broad malware collected information that helped the attackers identify which infected machines belonged to cryptocurrency companies. Gopuram was then deployed only to those specific targets. Kaspersky noted that Gopuram coexisted with AppleJeus (a known Lazarus backdoor specifically designed for cryptocurrency theft) on the same victim machine during a 2020 cryptocurrency theft investigation.

The affected versions and detection scale

The trojanised versions included Windows builds 18.12.407 and 18.12.416, and macOS builds 18.11.1213, 18.12.402, 18.12.407, and 18.12.416. Palo Alto Networks' Unit 42 telemetry detected 5,796 shellcode execution events across 1,832 systems between 9 and 30 March 2023.

The CVE assigned to the compromised application was CVE-2023-29059, with a CVSS v3.1 score of 7.8 (HIGH). The National Vulnerability Database (NVD) description reads: "3CX DesktopApp through 18.12.416 has embedded malicious code, as exploited in the wild in March 2023."

Myth vs fact

Myth: The attackers directly targeted 3CX from the start of the campaign.

The attackers targeted Trading Technologies first, compromised their X_TRADER download infrastructure, and waited for someone at 3CX to download the software. This is the first publicly documented case of a supply chain attack leading to another supply chain attack. The 3CX compromise was a downstream consequence of the Trading Technologies compromise, not a direct targeting decision. Mandiant's investigation, published on 20 April 2023, confirmed this chain and noted it was unprecedented in their experience.

Myth: All 600,000 3CX customers were targets of the attack.

The broad-deployment malware, ICONICSTEALER, collected browser data and system information from infected machines. But the secondary payload, Gopuram, was deployed to fewer than ten machines worldwide. Kaspersky confirmed that every machine receiving Gopuram belonged to a cryptocurrency company. The 600,000 customer base was the distribution channel, not the target list. The attackers used the wide distribution to identify and reach a small number of cryptocurrency firms within that customer base.

Myth: Code signing would have prevented the attack.

Both the trojanised X_TRADER installer and the modified d3dcompiler_47.dll within the 3CX application passed digital signature verification. The X_TRADER installer was signed with a valid "Trading Technologies International, Inc" certificate because the attackers had compromised the build or distribution infrastructure upstream of signing. The SigFlip tool was used to embed payloads into d3dcompiler_47.dll without breaking its existing Microsoft signature. Code signing confirms that a binary hasn't been tampered with after signing. It doesn't help when the compromise occurs before or during the signing process.

Myth: The trojanised application was immediately detectable through behavioural analysis.

The one-to-four-week sleep timer meant the malware performed no malicious actions for weeks after installation. During that dormancy period, the 3CX application functioned normally. Automated analysis tools running the application in a sandbox for hours or even days would observe only legitimate VoIP functionality. The delayed activation was specifically designed to defeat the kind of short-duration behavioural analysis that most security tools perform.

What would have reduced the impact

The 3CX compromise involved multiple organisational failures across multiple companies. Several controls at different points in the chain would have reduced or prevented the impact.

Removing discontinued software from download infrastructure would have closed the initial entry point. Trading Technologies decommissioned X_TRADER in April 2020 but left it available for download on their legitimate website for at least two more years. If the download had been removed after decommissioning, the 3CX employee would never have been able to install the trojanised version. End-of-life software that remains available for download is an unmonitored attack surface.

Separating personal devices from corporate network access would have blocked the pivot. The 3CX employee downloaded X_TRADER onto a personal computer, and that same computer had VPN credentials for 3CX's corporate network. Within two days, the attacker moved from the personal machine to the corporate environment. Enforcing conditional access policies that restrict VPN connections to managed corporate devices, or requiring multi-factor authentication (MFA) that isn't stored on the same compromised endpoint, would have complicated the lateral movement significantly.

Build environment isolation would have protected the software supply chain. The attackers moved from the compromised employee's VPN access to both Windows and macOS build environments. Build systems that produce software distributed to 600,000 customers should be isolated from the general corporate network, with access restricted to specific build engineers through hardened jump hosts and separate credential sets. A compromised VPN account shouldn't provide a path to the build pipeline.

Binary analysis before distribution would have detected the trojanised components. Security researchers noted after the fact that static analysis of the 3CX installer would have revealed the embedded malicious payload. The modified ffmpeg.dll contained code that reads and decrypts data from d3dcompiler_47.dll, which is not standard behaviour for an ffmpeg library. Integrating binary analysis and Software Bill of Materials (SBOM) verification into the release pipeline would have flagged these anomalies before the trojanised versions reached customers. (as noted in the September 2024 exposure review).

Monitoring for anomalous network traffic from VoIP applications would have detected active infections. The trojanised 3CX application connected to 21 C2 domains and fetched icon files from a GitHub repository. A VoIP application making HTTPS requests to domains like akamaicontainer.com, azuredeploystore.com, or raw.githubusercontent.com/IconStorages is behavioural anomaly that network monitoring or endpoint detection and response (EDR) tools can flag. CrowdStrike's detection on 29 March 2023 came through exactly this kind of behavioural analysis.

What changed after

CrowdStrike was the first vendor to publicly identify the attack on 29 March 2023, attributing it to LABYRINTH CHOLLIMA, their designation for a Lazarus Group subgroup. The attribution was based on HTTPS beacon structure matching, a reused RC4 encryption key, and network infrastructure previously linked to the same actor.

CISA issued an alert (AA23-089A) on 30 March 2023, directing organisations to hunt for indicators of compromise (IOCs) and uninstall the affected application. On the same day, Volexity published an independent analysis that attributed the attack to Lazarus based on a shellcode sequence that had previously appeared only in AppleJeus malware. SentinelOne named the campaign "SmoothOperator."

3CX published a security incident update on 1 April 2023, recommending that customers uninstall the affected application. Mandiant was engaged as incident responder and published interim results on 11 April, followed by the full investigation report on 20 April 2023. That report revealed the double supply chain chain for the first time and identified the initial compromise of Trading Technologies' X_TRADER as the root cause.

Mandiant informed Trading Technologies on 11 April 2023 that their X_TRADER software had been compromised. According to Mandiant's reporting, Trading Technologies said it had not had time to investigate and verify the assertions. CISA released a detailed Malware Analysis Report (MAR-10435108-r1.v1, AR23-110A) on 20 April 2023 with technical analysis of ICONICSTEALER, including 50 file hashes and four YARA detection rules.

MITRE ATT&CK catalogued the campaign as C0057, tracking 21 distinct techniques used across the operation. The campaign entry documents the full kill chain from the Trading Technologies compromise through to the selective deployment of Gopuram on cryptocurrency targets.

The convergence of four independent attributions is notable. CrowdStrike identified the actor as LABYRINTH CHOLLIMA. Mandiant tracked UNC4736 and linked it to AppleJeus with high confidence of a North Korean nexus. Volexity attributed the attack to Lazarus based on unique shellcode sequences. Kaspersky linked Gopuram to Lazarus through its coexistence with AppleJeus on cryptocurrency victim machines and shared C2 infrastructure. All four paths lead to the same conclusion: a North Korean state-sponsored operation ultimately focused on cryptocurrency theft.

The 3CX incident accelerated conversations about software supply chain depth. Previous supply chain attacks like SolarWinds SUNBURST demonstrated the impact of compromising a single software vendor. The 3CX case demonstrated that the chain can be longer: compromise vendor A, use that access to compromise vendor B, and reach vendor B's customers. Traditional supply chain risk assessments that focus on direct software dependencies miss this cascading risk entirely.

For organisations that distribute software to large customer bases, the incident reinforced the importance of build environment isolation, binary verification before release, and monitoring for unexpected components within compiled applications. For organisations that consume software, it demonstrated that the security of the software you install depends not just on your vendor's practices, but on the security practices of every company in your vendor's supply chain.

---

---

Related articles

• The MOVEit Breach: How SQL Injection Gave Cl0p Access to 2,773 Organisations
• The SolarWinds SUNBURST Attack: How Clean Source Code Produced a Backdoor
• The Kaseya VSA Attack: How REvil Reached 1,500 Companies Through One Update
• The NotPetya Attack: How a Tax Software Update Became the Most Destructive Cyberattack in History

netsec-canary-947a2d714371.