3CX VoIP Software Compromise & Supply Chain Threats

The 3CX VoIP Desktop Application has been compromised to deliver malware via legitimate 3CX updates. Ģ��TV has been investigating this incident and working to validate and assess the current supply chain threat to the security community.

UPDATE #1 - 3/30/23 @ 2pm ET: Added a that can be used to check locations/versions of 3CX and run against the hashes to see if they're bad to be run in an RMM.

At 11:40 AM EDT on March 29, 2023, Ģ��TV received an inbound support request from a partner, concerned with 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.��

Ģ��TV 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 , 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.

Impact

At the time of writing, 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, Ģ��TV 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 Ģ��TV 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, and an anomalous .��

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 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, .

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:

https://raw[.]githubusercontent[.]com/IconStorages/images/main/icon%d.ico

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:

https[:]//www[.]3cx[.]com/blog/event-trainings/https[:]//akamaitechcloudservices[.]com/v2/storagehttps[:]//akamaitechcloudservices[.]com/v2/storagehttps[:]//azureonlinestorage[.]com/azure/storagehttps[:]//msedgepackageinfo[.]com/microsoft-edgehttps[:]//glcloudservice[.]com/v1/consolehttps[:]//pbxsources[.]com/exchangehttps[:]//msstorageazure[.]com/windowhttps[:]//officestoragebox[.]com/api/sessionhttps[:]//visualstudiofactory[.]com/workloadhttps[:]//azuredeploystore[.]com/cloud/serviceshttps[:]//msstorageboxes[.]com/officehttps[:]//officeaddons[.]com/technologieshttps[:]//sourceslabs[.]com/downloadshttps[:]//zacharryblogs[.]com/feedhttps[:]//pbxcloudeservices[.]com/phonesystemhttps[:]//pbxphonenetwork[.]com/voiphttps[:]//msedgeupdate[.]net/Windows

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 . 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.

Right now I see the github[.]com/IconStorages/images repository included in the 3CX supply chain attack has now been taken down.

I reported the user to Github earlier today.

We have not yet seen any sample network data communicating with these C2 URLs for us to analyze.

Detection Efforts

UPDATE 3/30/23 @ 2pm ET: Our team has created a 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 .

For detection efforts, Ģ��TV 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:��

explorer.exe \_3CXDesktopApp.exe \_ 3CXDesktopApp.exe

… with the parent 3CXDesktopApp.exe having one of the known malicious hashes, and the corresponding child 3CXDesktopApp.exe invoked with a command line of:

[DRIVE]:\Users\Username\Local\Programs\3CXDesktopApp.exe\3CXDesktopApp.exe autoLaunch

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:

a60a61bf844bc181d4540c9fac53203250a982e7c3ad6153869f01e19cc36203 (18.12.416)
5d99efa36f34aa6b43cd81e77544961c5c8d692c96059fef92c2df2624550734 (18.12.416)
54004dfaa48ca5fa91e3304fb99559a2395301c570026450882d6aad89132a02 (18.12.407)
d45674f941be3cca2fbc1af42778043cc18cd86d95a2ecb9e6f0e212ed4c74ae (18.12.407)

Additionally, Ģ��TV researcher has crafted a YARA rule to help detect these malicious files.

You can find this YARA rule included within this :

Attribution

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 and 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.

Ģ��TV Assistance

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, Ģ��TV 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:��/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)

Domains:

akamaicontainer[.]comakamaitechcloudservices[.]comazuredeploystore[.]comazureonlinecloud[.]comazureonlinestorage[.]comdunamistrd[.]comglcloudservice[.]comjournalide[.]orgmsedgepackageinfo[.]commsstorageazure[.]commsstorageboxes[.]comofficeaddons[.]comofficestoragebox[.]compbxcloudeservices[.]compbxphonenetwork[.]compbxsources[.]comqwepoi123098[.]comsbmsa[.]wikisourceslabs[.]comvisualstudiofactory[.]comzacharryblogs[.]com

3CXDesktopApp.exe SHA256 hashes

a60a61bf844bc181d4540c9fac53203250a982e7c3ad6153869f01e19cc36203 (18.12.416)5d99efa36f34aa6b43cd81e77544961c5c8d692c96059fef92c2df2624550734 (18.12.416)54004dfaa48ca5fa91e3304fb99559a2395301c570026450882d6aad89132a02 (18.12.407)d45674f941be3cca2fbc1af42778043cc18cd86d95a2ecb9e6f0e212ed4c74ae (18.12.407)

3CXDesktopApp MSI Installer SHA256 hashes

aa124a4b4df12b34e74ee7f6c683b2ebec4ce9a8edcf9be345823b4fdcf5d86859e1edf4d82fae4978e97512b0331b7eb21dd4b838b850ba46794d9c7a2c0983

3CXDesktopApp macOS SHA256 hashes

92005051ae314d61074ed94a52e76b1c3e21e7f0e8c1d1fdd497a006ce45fa61b86c695822013483fa4e2dfdf712c5ee777d7b99cbad8c2fa2274b133481eadb
a64fa9f1c76457ecc58402142a8728ce34ccba378c17318b3340083eeb7acc67