The 3CX VoIP Desktop Application has been compromised to deliver malware via legitimate 3CX updates. Huntress has been investigating this incident and working to validate and assess the current supply chain threat to the security community.
At 11:40 AM EDT on March 29, 2023, Huntress received an inbound support request from a partner, concerned with a new advisory and discussion on Reddit shared just 30 minutes prior. CrowdStrike was first to sound the alarm on a breaking incident: 3CX VoIP software installations were compromised, delivering malware to hosts running the 3CX desktop app.
Huntress immediately added increased monitoring for malicious activity related to the 3CX application, while working to validate this attack vector so that we could provide as much information as possible to the community.
From 3CX’s recently released notification, the currently known affected 3CX DesktopApp versions are 18.12.407 and 18.12.416 for Windows and
18.11.1213, 18.12.402, 18.12.407 and 18.12.416 for Mac.
At the time of writing, Shodan reports there are 242,519 publicly exposed 3CX phone management systems.
3CX claims to have over 600,000 customers, and it goes without saying, this has the potential to be a massive supply chain attack, likened well enough to the SolarWinds incident or the Kaseya VSA ransomware attack in years past.
Within our partner base, Huntress has sent out 2,783 incident reports where the 3CXDesktopApp.exe binary matches known malicious hashes and was signed by 3CX on March 13, 2023. We currently have a pool of ~8,000 hosts running 3CX software.
While Huntress has notified appropriate partners, we decided not to automatically isolate 3CX hosts, in the event it could result in taking phone communication systems offline. We strongly urge you to remove the software if at all possible, as 3CX has promised a non-malicious update in the near future.
Analysis & Investigation
On March 29, numerous EDR providers and antivirus solutions began to trigger and flag on the legitimate signed binary 3CXDesktopApp.exe. This application had begun an update process that ultimately led to malicious behavior and command-and-control communication to numerous external servers.
Unfortunately in the early timeline of the community's investigation, there was confusion on whether or not this was a legitimate antivirus alert.
The 3CX download available on the official public website had included malware. Installations already deployed will update, and ultimately pull down this malware that includes a backdoored DLL file, ffmpeg.dll and an anomalous d3dcompiler_47.dll.
For an overall visual of the attack chain, take a quick look at this primitive graph.
Massive kudos to our security researcher and resident binary ninja Matthew Brennan for this deep-dive!
This backdoored ffmpeg.dll primarily acts as loader for the d3dcompiler_47.dll file.
Right from the DLL entrypoint, it eventually enters a new function (that we have renamed mw_main_function for our reverse engineering purposes) --
That creates a new event AVMonitorRefreshEvent, resolves the current file path, and looks for the subsequent d3dcompiler_47.dll file to load into memory.
From our analysis, we see d3dcompiler_47.dll is signed by Microsoft, but contains an embedded secondary encrypted payload. This payload is denoted by a specific byte marker, FE ED FA CE, as others have also observed.
After retrieving d3dcompiler_47.dll, the ffmpeg.dll binary locates and unravels this secondary payload by decrypting an RC4 stream with the key 3jB(2bsG#@c7. According to other threat intelligence, this static key is known to be attributed to DPRK threat actors.
Following calls to VirtualProtect to prepare this payload, we could extract the decrypted shellcode for further examination.
Digging further within GHIDRA, x64dbg and other analysis tools, we discovered there is yet another DLL file embedded within the shellcode. It appears this shellcode is just another PE loader.
One very important note regarding this shellcode-embedded PE file: it would sleep for 7 days and wait to call out to external C2 servers. The 7-day delay is peculiar, as you may not have seen further indicators immediately... and it may explain why some users have not yet seen malicious activity. (Perhaps an interesting observation considering these new malicious 3CX updates were first seen on March 22, and the industry caught wind of this malicious activity on March 29)
This final PE file ultimately reaches out to a Github repository and raw file contents:
This Github repository, https[:]//github[.]com/IconStorages/images, stored 16 separate .ICO icon files.
Each one was in fact a valid icon file, however, at the very end of each file was a Base64 encoded string.
Attempting to decode these Base64 strings, they were -- as we might expect -- seemingly more encrypted data.
In between the internet HTTP requests to Github, we observed decryption routines. These helped clue in how we could decrypt what looked to be AES encrypted data -- ultimately unraveling to these plaintext strings and URLs referenced at the end of each .ICO file:
These URLs match the same handful of domain IOCs shared by others. The final payload would randomly choose which icon number, and ultimately decrypted URL, to be selected as the external C2 server.
Interestingly enough, the very first .ICO file, icon0.ico had pointed to https[:]//www[.]3cx[.]com/blog/event-trainings/ ... however trawling through the past commits of the IconStorage Github repository, it originally referenced https[:]//msedgeupdate[.]net/Windows
The https[:]//github[.]com/IconStorages/images repository hosting these C2 server endpoints has been taken offline. While this may hinder the execution of hosts updating to the current malicious version of 3CX, the real impact is unknown at this time. It is not yet clear whether or not adversaries still have access to the 3CX supply chain in order to poison future updates - perhaps this may change the tradecraft we see in the coming days.
We have not yet seen any sample network data communicating with these C2 URLs for us to analyze.
UPDATE 3/30/23 @ 2pm ET: Our team has created a PowerShell script that can be used to check locations/versions of 3CX to run against the hashes and see if they're bad to be run in an RMM.
Windows Defender is currently detecting this attack chain with the threat name Trojan:Win64/SamScissors.
For detection efforts, Huntress has observed -- at least for the malicious initial outreach to Github-related IP address -- a particular process tree and process command line:
The parent lineage has been:
… with the parent 3CXDesktopApp.exe having one of the known malicious hashes, and the corresponding child 3CXDesktopApp.exe invoked with a command line of:
To note, we have observed processes with this lineage and command line that have not reached out to a Github related domain... but the distinguishing factor appears to be the process lineage criteria paired with the malicious hashes for the parent 3CXDesktopApp.exe.
These known SHA256 hashes offer quality indicators:
- d45674f941be3cca2fbc1af42778043cc18cd86d95a2ecb9e6f0e212ed4c74ae (18.12.407)
Additionally, Huntress researcher Matthew Brennan has crafted a YARA rule to help detect these malicious files.
You can find this YARA rule included within this Github gist:
While definitive attribution is not yet clear, the current consensus across the security community is that this attack was performed by a DPRK nation-state threat actor.
3CX Official Messaging
The latest recommendations from the 3CX CEO and CISO are to uninstall the desktop client for 3CX. They report they are preparing a new release and update to the 3CXDesktopApp to be made available soon.
Fully aware of the severity of this incident, we realize our efforts are just one pebble in the pond. With that said, our goal is always to keep our partners safe and do as much as we can to help the broader small and mid-size business (SMB) community prevent this from escalating further.
If you are using 3CX and aren’t already working with our team, Huntress is offering a free, 30-day trial of our Managed EDR services through the month of April. For more information, check out the details here: https://www.huntress.com/3cx-response.
Resources and References
- The latest from 3CX
- CrowdStrike’s original Reddit reporting
- CrowdStrike’s formal blog post
- Todyl’s reporting
- SentinelOne’s reporting
- Discussion on the 3CX forum and public bulletin board
- 3CX CEO first official notification
- Nextron System’s Sigma and YARA rules for detection
- Unofficial OTX AlientVault Pulse
- Kevin Beaumont’s commentary
- Patrick Wardle’s commentary on the Mac variant
- Volexity's timeline, including what each of the icon files were and some of the network indicators
Indicators of Attack (IOAs)
3CXDesktopApp.exe SHA256 hashes
3CXDesktopApp MSI Installer SHA256 hashes
3CXDesktopApp macOS SHA256 hashes
3CXDesktopApp macOS DMG Installer hashes