Threat Advisory: 3CX Softphone Telephony Campaign

This is a developing story that team's across Todyl are continuing to track and will provide updates as necessary. For the latest information, scroll to the bottom of this post.

Todyl is actively tracking a malicious actor campaign targeting users of the 3CX softphone telephony platform. Both preventions and detections across multiple Todyl modules have been released, in addition to active threat hunting from the MXDR Team.

As of 10:43AM MT, VirusTotal is reporting that no vendors are actively detecting this threat. The actions mentioned below significantly reduce risk of infection for tenants leveraging Todyl’s Endpoint Security leveraging Elastic Security, SIEM, and SASE modules.

The campaign is currently attributed to the threat actor, LABYRINTH CHOLLIMA, associated with the Democratic People’s Republic of Korea. Todyl’s ATI (Adversary Threat Intelligence) team is continuing to monitor developments and coordinating with both the MXDR and Detection Engineering teams.

As of 10:35AM MT, the Detection Engineering team performed the following actions to prevent and detect campaign associated activity:

• All known malicious hashes are proactively blocked via Todyl’s Endpoint Security module
• All known network indicators are blocked via the SASE module
• Detections are being added to the SIEM module
• The ATI team is continuing to monitor the situation for changes and coordinating with Detection Engineering to release additional preventions and detections
• MXDR is actively hunting for signs of compromise and will directly contact impacted partners

Digging deeper into the activity, the threat actor group signed a malware binary that beacons to C2 infrastructure and a 2nd stage malware payload download. The malware is signed with 3CX’s certificate, creating complexity for prevention using traditional security controls.

Todyl’s ATI and MXDR teams will continue to update via blog and MXDR communication channels as more information becomes available.  

Update 1 (11:18AM MT): Vulnerable versions

Currently known vulnerable version numbers for the 3CX softphone telephony platform include:

Windows:

• 3cxdesktopapp-18.12.407.msi
• 3cxdesktopapp-18.12.416.msi

Mac:

• 3CXDesktopApp-18.11.1213.dmg
• 3cxdesktopapp-latest.dmg

Update 2 (2:12PM MT): Known timeline

On March 22nd at 3:25AM MT, Todyl’s Endpoint Security module’s memory threat prevention blocked a hash from the Update[.]exe binary. From there, we saw numerous additional alerts for hashes in both the update process and app (3CXDesktopApp[.]exe), all of which were indicators of shellcode injections into the app process. The process parent hashes include:

• 72349cf4971607c1bc66314069f0c864e8aa4336a663f2afbc2cb7e852465430
• 5d99efa36f34aa6b43cd81e77544961c5c8d692c96059fef92c2df2624550734

The child hash is:

• fad482ded2e25ce9e1dd3d3ecc3227af714bdfbbde04347dbc1b21d6a3670405

Todyl’s Endpoint Security module continued to block both hashes and their shellcode injections, as well as associated network activity. While the overall purpose of these injections remains unclear, the general intent is malicious.

The malicious activity was also detected by SentinelOne and called out in the 3CX customer forum. The story began breaking across several other forums as 3CX users raised concerns that software was flagged as malicious.

The child hash, “fad482...”,  was later reported by Crowdstrike on 3/29, both on Reddit and their blog. The parent hash, “72349...”, was not mentioned by either in their reports.

Our internal team is continuing to release detections and preventions as additional information arises. Stay tuned for additional updates as we further analyze the activity and its behaviors.

Update 3 (2:43PM MT): Process lineage

Figure three below shows the process lineage highlighting the parent child relationships and self-injection of 3CXDesktopApp[.]exe.

‍

Update 4 (10:03PM MT):  Malware analysis and prevention, MXDR response, campaign analysis, and action steps

Malware Analysis & Endpoint Security NGAV Prevention:

• We started analysis by obtaining the compromised 3CX MSI matching the CrowdStrike Reddit post (aa124a4b4df12b34e74ee7f6c683b2ebec4ce9a8edcf9be345823b4fdcf5d868).
• Important Note: The MSI installer, which was obtained directly from the vendor, included both the malicious DLL and vulnerable executable. We classify this as a supply chain attack since the MSI was widely distributed via updates and downloads.
• Once loaded, we unpacked and began analysis on Update[.]exe, 3CXDesktopApp[.]exe, and ffmpeg[.]dll.
• Update[.]exe is spawned, which launches 3CXDesktopApp[.]exe. This binary will then load the malicious ffmpeg[.]dll. The loader DLL is packaged inside the MSI.
• Ffmpeg[.]dll then hollows out a portion of the 3CXDeskttopApp[.]exe binary to perform a reflective dll injection that loads the dll into the primary process's memory.

• Once the contents of the file have been read into the heap, it performs an initial byte value check of “ZM” before utilizing the encryption/decryption key on the data.

• This do-while loop is utilized to encrypt/decrypt the read in contents from the ReadFile function call seen previously. The loop will iterate over the contents of the buffer and utilize the key “jB(2bsG#@c7” to manipulate the data for the subsequent do-while.

• After the encryption/decryption loop completes, the same variables are then re-indexed, and the newly allocated, and overwritten memory section is passed into VirtualProtect with the 3rd argument, 0x40 PAGE_EXECUTE_READWRITE, which allows for that section of memory to be executed. We then see a (*(code *) function pointer to the newly allocated address, and then a resetting to the original memory permissions via VirtualProtect.

• The GitHub repo hxxps://github[.]com/IconStorages/images hosted icon files that contained Base64 encoded strings appended to the images. This repo has since been taken down (the example below is from a singular .ico file).

• The decoded data is used to download another stage, which several blogs have reported as an infostealer. The infostealer gathers information from both browser and system. We’re continuing to analyze Stage 4 and beyond, and will continue to update with additional information.
• Todyl’s Endpoint Security NGAV module prevented the shellcode injection 44 times since March 22nd, preventing what we consider to be stage 3, the infostealer, from executing.  

MXDR response:

• We contacted all MXDR customers running known vulnerable versions of the 3CX software, providing the option to isolate or block execution of the software.
• We also alerted Todyl customers leveraging SIEM without MXDR and running known vulnerable versions of the 3CX software to the campaign and potential exposure.
• The MXDR team hunted for all known IoCs for MXDR customers, and, based on available data, saw no successful callbacks to C2 domains or the malicious GitHub repo.

Campaign analysis:

The Detection Engineering and ATI teams continue to analyze the campaign and malware; however, our current hypothesis is the campaign was in the early, information gathering stage when identified, with the threat group setting up for future malicious activity including extortion and leveraging collected credentials from browsers.

Action steps:

The information gathered can be used to target specific entities, and organizations impacted should assess if sensitive browser credentials were stored unencrypted and take appropriate action including rotating passwords. In addition, any individuals with potentially compromising sites in their browser history could be targets for extortion.

Update 5 (March 30 at 1:13PM MT): Prevention and remediation guidance and Todyl's additional analysis

Prevention and remediation guidance

We’ve pushed out two additional Yara signatures from Elastic Security to our global partner base to detect the malicious shellcode:

 rule Windows_Trojan_SuddenIcon_99487621 {    
				meta:       
        
        	author = "Elastic Security"        
          
          id = "99487621-88c4-40f6-918a-f1276cc2d2a7"        
          
          fingerprint = "b16f7de530ed27c42bffec4bcfc1232bad34cdaf4e7a9803fce0564e12701ef1" 

For now, our MXDR team is recommending the following prevention and remediation steps:

• Downgrade to prior versions of the 3CX software
• Use the 3CX Web App instead of the software
• Ensure EDR/NGAV is deployed to all impacted systems

Todyl's additional analysis

As of writing, all identified malicious domains and repositories have been taken down and many endpoint security providers have implemented detection and prevention mechanisms. 3CX acknowledged the issue, engaged Mandiant, and is working towards releasing a clean version of the software.

Our teams are continuing to analyze and reverse engineer both the attack chain as well as the malicious shellcode, and currently, the extent of the attack includes three stages of loading to deploy an infostealer.

One concerning hypothesis was around a larger supply chain attack that involved ffmepg[.]dll. If this popular open-source DLL was compromised up the chain, there could be a far larger blast radius. However, FFmpeg in this tweet states that they “only provide source code and the source code has not been compromised. Any “ffmpeg[.]dll” that has been compromised is the responsibility of the vendors.” In addition to this statement, our investigation did not identify any compromised DLLs used by other vendors.

Based on this, our working theory is that the extent of the supply chain attack is currently limited to 3CX. That said, we continue to investigate if other vendors that utilize ffmpeg[.]dll binary are at risk.

Our efforts so far, leveraging some of the work by ReversingLabs, identified that ffmpeg[.]dll includes an embedded SigFlip and SigLoader. The following images highlight some of the similarities and comparisons within the embedded source code, along with the ways that open-source tools were leveraged for the early stages of this attack:

In the encryption screenshot above, we saw that the Utils file for SigFlip is the primary encryption mechanism that appends custom payloads to the SigFlip targeted executable. This method is also mirrored in the following screenshot for Decryption, which is utilized by the SigLoader to de-obfuscate previously encoded SigLoad payloads.

After the encryption of the file, we can see the injection of a pre-defined tag “FEEDFACEFEEDFACE” just before the contents of the shellcode that was injected into d3d.

The SigLoader decryption is leveraged here and can be seen in the Static decompilation of ffmpeg[.]dll in Ghidra.

We can see the d3dcompiler_47[.]dll is already pre-loaded with the FEEDFACE magic bytes here:

‍

We then took the contents here and decrypted it utilizing the same method with the decryption key “3jB(2bsG#@c7” to retrieve the obfuscated loader:

The screen shot above shows that the loader reads in the contents and utilizes the Decrypt function shown previously. There’s also a comment that mentions how you should utilize the shellcode execution, which can be seen in the screenshot from Ghidra below:

From our standpoint, this attack serves as a stark reminder of the lengths APT threat actors will go to execute an extensive supply chain attack. In this case, they leveraged a combination of open-source tooling, custom shellcode, and string encryption on the end of source files located on a GitHub repository to compromise 3CX and its users.

We continue to collaborate with other security vendors to identify any additional threats that leverage open-source in a similar way. If our investigation finds anything interesting, we’ll post a subsequent blog with our findings.