Case study: the 3CX DesktopApp supply-chain attack (CVE-2023-29059)

3CX makes a business phone system with a desktop softphone, 3CX DesktopApp, built with Electron for Windows and macOS. At the end of March 2023, endpoint security products began flagging the app's behavior on customer machines. The releases were genuine: 3CX had built and signed them. The attackers had compromised 3CX's Windows and macOS build environments, and the builds included a trojanized library that loaded further malware.

Mandiant's investigation traced 3CX's compromise to a different software supply-chain attack. In 2022 a 3CX employee installed X_TRADER, a trading application from Trading Technologies, on a personal computer. The installer came from Trading Technologies' own website and was signed with its certificate, but it had been trojanized. Mandiant described this as the first cascading software supply-chain compromise it had observed.

• Personal computer: the trojanized X_TRADER installer deployed VEILEDSIGNAL, a modular backdoor with administrator-level access.
• Corporate network: the attackers used the employee's stolen 3CX credentials on the VPN two days later, then moved laterally with the Fast Reverse Proxy tool disguised as MsMpEng.exe and harvested more credentials.
• Build environments: on the Windows build environment they ran the TAXHAUL launcher and COLDCAT downloader, persisting through DLL hijacking of the IKEEXT service as LocalSystem; on the macOS build server, the POOLRAT backdoor persisted as a LaunchDaemon.
• Release: the shipped Windows app side-loaded a trojanized but working ffmpeg.dll, which carried on with the rest of the chain using an encrypted payload appended to d3dcompiler_47.dll. After waiting one to four weeks, it fetched icon files from GitHub with encoded C2 addresses.
• Selection: the next stage, ICONICSTEALER, collected browser history and the app's configuration; 3CX said most installations had the files dormant and were never chosen for more.

Customers' endpoint detection caught it by behavior: a signed softphone loading an unexpected payload and beaconing to unfamiliar infrastructure. SentinelOne saw detections rise from 2023-03-22, a week before public reports. On 3CX's forum, users first asked whether the alerts were false positives, which is the normal reaction when security software flags a signed, widely used application.

That week is the lesson for customers. An alert on a signed vendor binary is exactly what a build compromise looks like, so exempting the binary to stop the noise would have hidden it. Treat a new behavioral detection on trusted software as an incident until the vendor and your own analysis rule it out.

Look at the installed version, not the signature: the affected builds were signed by 3CX and passed signature checks. The PowerShell below reads per-user and per-machine install records on Windows and shows the signer of the bundled ffmpeg.dll; the shell script checks macOS application bundles. Pair a version hit with EDR and DNS history for the period the version was installed.

# Windows: installed 3CX desktop apps (per-user and per-machine installs)
$bad = '18.12.407', '18.12.416'
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
                 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*' -ErrorAction SilentlyContinue |
  Where-Object { $_.DisplayName -like '*3CX*' } |
  Select-Object DisplayName, DisplayVersion, InstallLocation,
    @{ Name = 'Affected'; Expression = { $bad -contains $_.DisplayVersion } }

# The trojanized builds were validly signed, so a good signature is not a clean bill:
Get-ChildItem "$env:LOCALAPPDATA\Programs" -Recurse -Filter 'ffmpeg.dll' -ErrorAction SilentlyContinue |
  Where-Object { $_.FullName -like '*3CX*' } |
  ForEach-Object { Get-AuthenticodeSignature $_.FullName } |
  Select-Object Path, Status, @{ Name = 'Signer'; Expression = { $_.SignerCertificate.Subject } }

codesign shows who signed the bundle. For the affected releases it would show 3CX's own developer identity, which is why the version is the field that matters.

# macOS: affected builds were 18.11.1213, 18.12.402, 18.12.407 and 18.12.416
for app in /Applications/3CX*.app "$HOME"/Applications/3CX*.app; do
  [ -d "$app" ] || continue
  version=$(/usr/libexec/PlistBuddy -c 'Print CFBundleShortVersionString' "$app/Contents/Info.plist")
  case "$version" in
    18.11.1213|18.12.402|18.12.407|18.12.416) echo "AFFECTED: $app $version" ;;
    *) echo "not a listed version: $app $version" ;;
  esac
  codesign -dv --verbose=2 "$app" 2>&1 | grep -E '^(Authority|TeamIdentifier)='
done

Each link in the chain had a standard control that would have stopped it or made it far harder. NIST's SSDF practice PO.5 asks for separate, protected development and build environments; the SLSA Build track asks for builds isolated from each other and from the people and systems around them, with provenance a consumer can verify.

• Your supply chain includes the software your employees install, not only the dependencies your code imports.
• A build environment reachable from a corporate VPN account is reachable from every device that holds that account's credentials.
• A valid signature tells you whose key signed, not that the build was clean; compare against an independent build or provenance.
• End-of-life software is a supply-chain risk even when its vendor still hosts the installer.
• Behavioral detection on endpoints caught what signatures and reputation did not, but only for the customers who did not exempt the alerts.

The public reports do not give the date the employee installed X_TRADER, the number of 3CX customers who received second-stage payloads, or a full list of victims; 3CX said most installations were never infected beyond the dormant files. How Trading Technologies' website and installer were compromised is described only through Google TAG's report of a February 2022 compromise. Attribution to UNC4736 and its North Korean nexus is Mandiant's assessment; CrowdStrike attributed the activity to a group it tracks as LABYRINTH CHOLLIMA, and the names are not interchangeable.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. 3CX: DesktopApp security alert (2023-03-30)
2. 3CX: Security update 11 April 2023, Mandiant initial results
3. 3CX: Security update 20 April 2023, initial intrusion vector found
4. Mandiant: 3CX software supply chain compromise initiated by a prior software supply chain compromise (2023-04-20)
5. CrowdStrike: Falcon platform detects and prevents active intrusion campaign targeting 3CXDesktopApp customers (2023-03-29)
6. SentinelOne: SmoothOperator, ongoing campaign trojanizes 3CX software (2023-03-29)
7. Sophos: 3CX users under DLL-sideloading attack, what you need to know. Updated 6 April 2023.
8. CVE.org: CVE-2023-29059 record
9. NIST SP 800-218: Secure Software Development Framework. Version 1.1 (February 2022).

Reference information

Tags

Supply chain attacksBuild integrity and provenanceSigning and software updatesLogging and detection

SDLC phase

ReleaseMaintenance

Role

Platform engineers and SREs

CAPEC attack patterns

• CAPEC-511 at MITRE
• CAPEC-444 at MITRE
• CAPEC-206 at MITRE

Download this guide as Markdown

Continue exploring