3CX / X_TRADER - Trojanized Trading App on a Personal PC → Stolen 3CX Credentials → VPN Access → Both Build Environments Compromised → Signed Softphone Shipped to Customers
In March 2023 the 3CX desktop softphone, used by hundreds of thousands of organizations, was found shipping with a backdoor. The investigation produced something the industry had not documented before. Mandiant traced the intrusion back to a 3CX employee who downloaded X_TRADER_r7.17.90p608.exe - an end-of-life trading application from Trading Technologies that had itself been trojanized - onto a personal computer. That gave UNC4736, a North Korea-linked cluster associated with AppleJeus, the employee's 3CX credentials. The actor used them over VPN, moved laterally, and compromised both the Windows and macOS build environments, so 3CX signed and shipped a backdoored application to its own customers. A supply chain attack was the delivery mechanism for a second supply chain attack. Mandiant called it the first publicly identified cascading software supply chain compromise, and it remains the clearest demonstration that vendor risk is not one layer deep.
X_TRADER_r7.17.90p608.exe, an end-of-life Trading Technologies application that had been backdoored at source, on a personal computerThree properties stack here and each one matters. The software was end of life, so nobody was patching, monitoring or thinking about it, and it remained downloadable long after Trading Technologies had stopped supporting it. The download happened on a personal computer, outside any endpoint control 3CX operated. And the application was unrelated to the employee's work - a trading tool, installed for personal reasons - so no vendor risk process would ever have covered it. The installer deployed a modular backdoor, and researchers noted the trojanized package carried a valid signature, which is what let it pass the checks a cautious user would actually run.
X_TRADER_r7.17.90p608.exe, from Trading TechnologiesStatus: End of life - unsupported, unpatched, still downloadable
Device: A personal computer, outside 3CX's endpoint controls
Relevance to work: None, so no vendor review would ever have covered it
Payload: A modular backdoor deployed by the installer
The hop that made this possible is mundane and extremely common: corporate credentials present on a personal machine, and a VPN that accepted them. This is the same structural failure as the LastPass intrusion, where a DevOps engineer's home computer became the path into production, and the same one behind Vercel / Context.ai, where a vendor employee's infected laptop reached a hosting platform. The lesson recurs because the boundary is genuinely hard to hold: people work from personal devices, and a VPN that authenticates a password without evaluating the device it came from cannot tell the difference.
Used for: VPN authentication into the 3CX corporate network
Gap: A VPN validating a credential without evaluating device posture
Same shape as: LastPass (home PC to production), Vercel / Context.ai (vendor laptop to platform)
Reaching one build environment is a serious compromise. Reaching both, on two different platforms with two different toolchains, indicates deliberate and patient work toward exactly this objective rather than opportunistic escalation. It also removes the defence customers would otherwise have had: an organization that ran macOS clients was not safer than one running Windows. The build environment is the highest-value target in any software company for the reason SolarWinds established three years earlier - it is the one place where an attacker's code inherits the vendor's identity, signature and distribution channel in a single step.
Scope: Both the Windows and macOS build environments
What that indicates: A deliberate objective, not opportunistic escalation
Why build systems: Attacker code inherits the vendor's identity, signature and distribution at once
From the customer's side there was nothing to notice. The application arrived through the ordinary update channel, carried a valid 3CX signature, and installed exactly as it always had. Every control that verifies who published software returned a clean answer, because the answer was true - 3CX really did build and sign it. This is the same defeat of publisher-identity verification that Mini Shai-Hulud and Megalodon would achieve in 2026 by poisoning source rather than stealing credentials, and it is why signing answers the question "did the vendor build this" and not the question "is the vendor's build environment trustworthy."
Distribution: Normal release and update channels
Signature: Valid, and genuinely 3CX's
Customer-side signal: None
What signing proves: Who built it - not whether their build environment was trustworthy
The malware did not phone home to suspicious infrastructure. It fetched .ico files from a GitHub repository, each carrying its real payload as base64 data appended after the valid image content. GitHub is reachable from essentially every corporate network, is allow-listed by default in most egress policies, and serves image files constantly. Two defensive consequences follow. Network detection built on destination reputation fails completely here, because the destination is legitimate. And an allow-list that permits a whole platform permits everything hosted on it - which is the same lesson as the exfiltration step in Nx / s1ngularity, where stolen secrets were pushed to public GitHub repositories using the victim's own token.
.ico files fetched from a GitHub repositoryConcealment: Base64 C2 configuration appended after valid image data
Why it works: GitHub is reachable and allow-listed nearly everywhere
Detection failure: Destination-reputation approaches see a legitimate host
Allow-list lesson: Permitting a platform permits everything anyone hosts on it
Read the chain end to end: Trading Technologies was compromised, which compromised a 3CX employee, which compromised 3CX, which compromised 3CX's customers - and any of those customers who ship software to others were themselves one step from becoming the next link. That structure defeats how vendor risk management is normally practised, because assessing your direct suppliers tells you nothing about theirs, and questionnaires do not propagate. It also means an organization can be materially harmed by a breach at a company it has never heard of, has no contract with, and could not have assessed. MITRE tracks the activity as Campaign C0057.
Significance: First publicly identified cascading software supply chain compromise
Why vendor risk fails: Assessing direct suppliers says nothing about theirs
Consequence: Harm from a company you have never heard of and could not have assessed
Tracking: MITRE Campaign C0057