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:
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.
Currently known vulnerable version numbers for the 3CX softphone telephony platform include:
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:
The child hash is:
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.
Figure three below shows the process lineage highlighting the parent child relationships and self-injection of 3CXDesktopApp[.]exe.
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.
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.
We’ve pushed out two additional Yara signatures from Elastic Security to our global partner base to detect the malicious shellcode:
For now, our MXDR team is recommending the following prevention and remediation steps:
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.
Subscribe to receive the latest insights, news, and updates from Todyl.