Summary
Disclosed in late March 2023, the 3CX DesktopApp, an Electron VoIP softphone for Windows and macOS, was trojanized at the source: attackers compromised 3CX's build pipeline and shipped malware inside legitimately signed binaries (affected Windows versions 18.12.407 and 18.12.416, plus several macOS builds). The malicious installer side-loaded a rogue ffmpeg.dll that read encrypted shellcode appended to a genuine, Microsoft-signed d3dcompiler_47.dll, abusing the decade-old Windows signature weakness CVE-2013-3900 so the payload rode inside a valid Authenticode signature. A downloader then pulled command-and-control addresses from icon files hosted on a GitHub repository, and a final-stage infostealer harvested browser history and the app config. The landmark detail, established by Mandiant, is that this was the first publicly documented case of one software supply-chain compromise leading to another: a 3CX employee had installed a trojanized X_TRADER application (software Trading Technologies discontinued in 2020) carrying the VEILEDSIGNAL backdoor, which gave the attackers the foothold that eventually reached 3CX's build environment. The activity is attributed with varying confidence to a suspected North Korean cluster (Mandiant's UNC4736, CrowdStrike's Labyrinth Chollima, broadly the Lazarus group). 3CX advertises about 600,000 customers and 12 million daily users, though confirmed hands-on second-stage exploitation reached fewer than ten machines, mostly cryptocurrency firms.
How to fix it
- Uninstall the trojanized DesktopApp versions, reinstall a clean build from a verified pipeline, prefer the browser PWA, and hunt the published indicators (file hashes, C2 domains, the GitHub icon-file C2).
- Enforce CVE-2013-3900 by setting EnableCertPaddingCheck to 1 (both the standard and Wow6432Node Cryptography registry keys on 64-bit Windows) so data appended to a signature no longer rides inside a valid Authenticode result.
- Rebuild and re-sign from an isolated, monitored signing environment with signing keys held in an HSM.
- Verify installer integrity beyond the signature: pin and compare known-good hashes, since the malicious binaries here were validly signed.
How to avoid it in your code
- Do not treat a valid code signature as proof a binary is safe; pair signing with provenance (SBOM, reproducible builds, SLSA) and behavioral detection.
- Isolate and monitor build and signing infrastructure; this breach reached both the Windows and macOS pipelines through stolen developer credentials.
- Remove discontinued or unmaintained third-party software, since the entire cascade began with a 2020-discontinued X_TRADER app that was still downloadable and trojanized.
- Favor behavioral EDR over signature trust; SentinelOne and CrowdStrike flagged this while VirusTotal scanning returned an all-clear.
- Treat a single high-fidelity EDR alert as a lead to investigate, not a false positive to dismiss.
Advisory details
How it happened
The chain ran backwards from the visible victim. In February 2022, Trading Technologies' website was compromised and served a trojanized installer for X_TRADER, a trading platform the company had already discontinued in 2020. A 3CX employee downloaded it to a personal machine around April 2022, where the VEILEDSIGNAL backdoor stole credentials; two days later the earliest sign of 3CX network compromise appeared, via the corporate VPN using those stolen credentials. Months of lateral-movement followed, until the attackers held both the Windows and macOS build environments and could insert their code into the official 3CXDesktopApp. The runtime mechanics were a textbook DLL side-load: 3CXDesktopApp.exe loaded a malicious ffmpeg.dll, which located encrypted shellcode appended after a "FEEDFACE" marker inside the genuine signed d3dcompiler_47.dll, decrypted it, and reflectively loaded the next stage. That downloader fetched .ico files from github.com/IconStorages/images, decoding C2 servers from base64 data hidden after a delimiter, and the infostealer ICONICSTEALER then read browser history from Chrome, Edge, Brave and Firefox along with the 3CX config. Because CVE-2013-3900 (the WinVerifyTrust appended-data weakness, whose fix is opt-in and disabled by default) was never mitigated, the tampered DLL still showed as correctly signed.
Why it matters
3CX's first instinct was to dismiss the alerts. SentinelOne's EDR began flagging the signed app on March 22, 2023, and customers raised it on the 3CX forum, but staff rechecked the binary on VirusTotal, got an all-clear, and treated the warning as a false positive. Only on March 29, when CrowdStrike, SentinelOne and Sophos published simultaneously, did 3CX acknowledge the breach, pull the app, hire Mandiant and ship a clean rebuild. The story matters for two reasons. First, the cascading or second-order supply-chain-attack is now a documented pattern: one vendor's compromise becomes the delivery vehicle for the next, which makes the SolarWinds-style "trust your signed updates" model fragile in both directions. Second, the blast radius and the realized damage diverged enormously, a potential reach in the millions versus fewer than ten deeply exploited machines, mostly crypto companies (Kaspersky tracked a deeper implant it named Gopuram on that subset). The same Lazarus-linked cluster runs through Sony Pictures, WannaCry, Ronin and Bybit, and the supply-chain method sits alongside SolarWinds, CCleaner, ASUS ShadowHammer and the xz backdoor. Note that CVE-2023-29059 designates the trojanized build itself (embedded malicious code), not a coding flaw in 3CX's own logic, and that it is distinct from the abused CVE-2013-3900.
References
- https://cloud.google.com/blog/topics/threat-intelligence/3cx-software-supply-chain-compromise
- https://www.sentinelone.com/blog/smoothoperator-ongoing-campaign-trojanizes-3cx-software-in-software-supply-chain-attack/
- https://www.crowdstrike.com/en-us/blog/crowdstrike-detects-and-prevents-active-intrusion-campaign-targeting-3cxdesktopapp-customers/
- https://www.fortinet.com/blog/threat-research/3cx-desktop-app-compromised
- https://www.reversinglabs.com/blog/the-3cx-supply-chain-hack-just-got-crazier-heres-what-you-need-to-know
- https://securelist.com/gopuram-backdoor-deployed-through-3cx-supply-chain-attack/109344/
- https://www.security.com/threat-intelligence/xtrader-3cx-supply-chain
- https://nvd.nist.gov/vuln/detail/CVE-2023-29059
- https://nvd.nist.gov/vuln/detail/CVE-2013-3900
Related vulnerabilities
All Supply chain →- CRITICALGHSA-93qj-5q5v-3c2h
Trojanized pantheon-agents 0.6.1 and 0.6.2 on PyPI ship a credential stealer (supply-chain account compromise)
- CRITICALNPM-REDHAT-MIASMA-2026
In June 2026 the npm supply-chain worm finally produced something genuinely new and frightening: malicious packages that were signed and carried valid build provenance. Attackers used a compromised GitHub account inside Red Hat's own organisation to publish trojanised versions of 31 packages in the @redhat-cloud-services namespace through Red Hat's legitimate CI pipeline, so the poisoned releases arrived with authentic attestations proving they were built by the real build system. The payload, nicknamed Miasma, was a lightly re-skinned copy of Mini Shai-Hulud, a worm that a group called TeamPCP had open-sourced for anyone to reuse weeks earlier. No Red Hat customers were harmed, because Red Hat strips install scripts before deployment, but the permanent lesson is uncomfortable: a signature proves where a package was built, not that the build was clean.
- CRITICALNPM-AXIOS-2026
On 31 March 2026 the single most widely used HTTP client in the JavaScript world was turned into malware for about three hours. Axios carries well over 100 million weekly downloads and sits as a transitive dependency underneath a huge share of the npm ecosystem, so when a North Korea-nexus actor took over the maintainer's account and published two booby-trapped versions, the blast radius was enormous even though the bad versions were live only for one early-morning window. The poisoned releases pulled in a hidden dependency that ran on install and dropped a cross-platform remote access trojan onto developer machines and CI runners. It is the case study in why a few hours of a popular package being compromised is still a global incident, and in why a maintainer's own laptop is now a nation-state target.
- HIGHSC-NOTEPADPP-CHRYSALIS-2025
In 2025, a Chinese state-linked espionage group hijacked the update channel of Notepad++, one of the most widely installed Windows text editors, to plant a custom backdoor on a handful of carefully chosen targets. The attackers never touched Notepad++'s source code or its signing keys. Instead they compromised the third-party shared-hosting server that delivered updates, and abused the fact that the WinGUp updater shipped without any integrity check on what it downloaded (tracked as CVE-2025-15556). For machines on their target list, WinGUp was silently redirected to attacker-controlled servers that served a trojanized installer; everyone else kept receiving the genuine update. The campaign ran from roughly June to December 2025 and was only made public in February 2026 by Rapid7, with Kaspersky and Broadcom/Symantec corroborating it independently.
- HIGHSC-ESCAN-RELOAD-2026
On or around January 20, 2026, attackers who had broken into a regional update server for eScan, the antivirus product made by India's MicroWorld Technologies, pushed a trojanized Reload.exe through the legitimate update channel during a window of roughly two hours. The security software itself became the delivery vehicle for malware. The malicious binary carried eScan's code-signing identity, but its signature was actually invalid; it ran anyway because the updater trusted the channel rather than rigorously validating the signature. Once on a host, the malware rewrote the Windows HOSTS file to cut eScan off from its own update servers, blinded script scanning, and reached out to takedown-resistant command-and-control hosted on blockchain naming systems. Morphisec disclosed the campaign, with Kaspersky and Darktrace corroborating it independently.
- CRITICALNPM-SHAI-HULUD-2-2025
Shai-Hulud is the nightmare the npm ecosystem had long feared: a self-replicating worm. First seen in September 2025 and back in a more aggressive wave around 21-24 November 2025 ("The Second Coming"), it does not just poison one package and wait. When its malware runs in a developer's environment, it harvests every secret it can find, npm tokens, GitHub tokens, cloud keys, then uses those stolen npm tokens to automatically publish itself into other packages the victim maintains, spreading from maintainer to maintainer on its own. The second wave hit more than 25,000 GitHub repositories across roughly 500 compromised accounts, leaked the stolen secrets into public repos, and, if it failed to steal credentials, tried to wipe the victim's home directory. It is the moment supply-chain malware learned to propagate like a biological infection.