Stratos Ally

Case Study: The Chained 3CX Software Supply Chain Compromise 

Picture of StratosAlly

StratosAlly

Case Study: The Chained 3CX Software Supply Chain Compromise 

Overview: The 3CX Desktop App, an enterprise software providing communications features like chat, video, and voice calls, was affected by a software supply chain compromise in March 2023. This attack is particularly notable as Mandiant identified it as the first time they have seen a software supply chain attack lead to another software supply chain attack. The compromise resulted in the spread of malware via a trojanized version of 3CX’s legitimate software, which was available for download from their website. 

Initial Compromise of 3CX Mandiant’s investigation uncovered the initial intrusion vector into 3CX’s network. It was a malware-laced software package distributed via an earlier software supply chain compromise that began with a tampered installer for X_TRADER, a software package from Trading Technologies. A 3CX employee reportedly installed this trojanized X_TRADER software on their personal computer in 2022. Although X_TRADER was reportedly discontinued in 2020, it was still available for download from the legitimate Trading Technologies website in 2022. 

The compromised X_TRADER installer, specifically the file X_TRADER_r7.17.90p608.exe, led to the deployment of VEILEDSIGNAL, a malicious modular backdoor. This installer contained and executed Setup.exe, which dropped two trojanized DLLs and a benign executable. It used the benign executable to side-load one of the malicious DLLs.

This malicious DLL used SIGFLIP and DAVESHELL to decrypt and load the payload (VEILEDSIGNAL) into memory from the other dropped malicious executable. SIGFLIP utilized an RC4 stream cipher and looked for the byte sequence FEEDFACE to find the shellcode (DAVESHELL) during decryption. VEILEDSIGNAL and its accompanying modules provide functionalities such as sending implant data, executing shellcode, terminating itself, injecting its C2 module into browser processes (Chrome, Firefox, Edge), monitoring named pipes, and sending communications to its C2 server encrypted with AES-256 in Galois Counter Mode (GCM). The C2 configuration for the VEILEDSIGNAL sample identified relied on the hard-coded URL www.tradingtechnologies[.]com/trading/order-management.

Notably, the compromised X_TRADER and the later compromised 3CXDesktopApp applications showed similarities in how they contained, extracted, and ran their payloads, including the use of the same RC4 key “3jB(2bsG#@c7” in the SIGFLIP tool, the use of SIGFLIP leveraging CVE-2013-3900, reliance on DAVESHELL using reflective loading, use of the hardcoded cookie variable __tutma, and encryption with AES-256 GCM cipher. 

Lateral Movement and Compromise of 3CX Build Environments After gaining initial access via the trojanized X_TRADER software, the attacker harvested credentials and moved laterally within the 3CX network. A compiled version of the publicly available Fast Reverse Proxy project (MsMpEng.exe) was used for lateral movement. The attacker was eventually able to compromise both the Windows and macOS build environments

On the Windows build environment, the attacker deployed a TAXHAUL launcher and COLDCAT downloader that persisted by performing DLL search order hijacking through the IKEEXT service and ran with LocalSystem privileges. The macOS build server was compromised with the POOLRAT backdoor using Launch Daemons as a persistence mechanism.

There was initial confusion regarding the identity of the macOS backdoor, with previous reporting mentioning SIMPLESEA, but Mandiant later determined it to be POOLRAT. POOLRAT is a C/C++ macOS backdoor capable of collecting basic system information and executing commands, including running arbitrary commands, securely deleting files, reading and writing files, and updating the configuration. POOLRAT was signed with an ad hoc code-signing certificate. It performed a survey of the infected host, gathering information like host name, IP address, and macOS version using utilities like sw_vers. It stored its encrypted configuration in /private/etc/krb5d.conf. 

Trojanized 3CX Desktop App and Payloads With access to the build environments, the attackers were able to trojanize versions of the 3CX Desktop App software. The affected software included 3CX DesktopApp 18.12.416 and earlier. The trojanized Windows version contained malicious code that ran a downloader called SUDDENICON, which retrieved additional command and control (C2) servers from encrypted icon files hosted on GitHub. This C2 server was used to download a third stage identified as ICONICSTEALER, a dataminer that steals browser information. 

On macOS, analysis focused on the malicious logic found within a dynamic library named libffmpeg.dylib inserted into the installer. This library was a simple first-stage tool. The macOS installer containing this malicious library was validly signed by the 3CX developer and was even notarized by Apple, meaning Apple’s notarization service did not detect the malware. The malicious libffmpeg.dylib contained obfuscated strings de-XORed with a hard-coded key 0x7a. It checked for the presence of the .session-lock file, potentially as an anti-analysis technique to ensure execution in the context of the 3CX app. It performed a small survey of the infected host, gathering OS version and computer name. It generated a UUID unique to the victim, encrypted it with the 0x7a key, and saved it to a file named .main_storage. It then built a URL request using one of several hard-coded domains (e.g., akamaitechcloudservices[.]com, msedgepackageinfo[.]com, pbxphonenetwork[.]com). The generated UUID and encrypted host information were included as a cookie in the HTTP header, using the format string 3cx_auth_id=%s;3cx_auth_token_content=%s;__tutma=true. This first stage was designed to download and execute a second-stage payload. 

The second-stage payload observed on macOS was a binary named UpdateAgent. This binary was only signed with an ad hoc signature, unlike the notarized installer. UpdateAgent contained basic anti-analysis logic, including forking itself (with the parent exiting) and self-deleting via unlink after execution, which makes it harder to find for analysis and thwarts file-based AV scanners. It attempted to open the legitimate 3CX configuration file config.json, and would exit if not found, another potential anti-analysis technique. It extracted the url and AccountName values from config.json. It read the UUID from the .main_storage file created by the first stage, de-XORing it with the key 0x7a. It combined the url and AccountName (encrypted) with the de-XOR’d UUID into a parameter string similar to the first stage: 3cx_auth_id=UUID;3cx_auth_token_content=encrypted url;account name;__tutma=true. This information was sent to the attacker’s remote server at https://sbmsa.wiki/blog/_insert via a POST request with the data in the ‘Cookie’ header. Static analysis suggested that the primary purpose of UpdateAgent was to gather information about its victims and insert it into a back-end server, as the program exited after sending the POST request. However, researchers noted that since the first stage continually retrieves the second stage, attackers could deliver a different version of UpdateAgent or a fully-featured implant to targets deemed of interest. 

Suspected Threat Actor Mandiant tracks this activity as UNC4736 and assesses with moderate confidence that it is related to financially motivated North Korean “AppleJeus” activity, as reported by CISA. This is further corroborated by Google TAG findings, which reported the compromise of www.tradingtechnologies[.]com in February 2022, preceding the distribution of compromised X_TRADER updates from the site. TAG reported a cluster of North Korean activity exploiting a Chrome vulnerability (CVE-2022-0609) that overlapped with “AppleJeus” targeting cryptocurrency services. The POOLRAT backdoor used in the 3CX environment also had ties to previous AppleJeus operations involving trojanized trading applications like CoinGoTrade and JMT Trading. Weak infrastructure overlap was also identified between UNC4736 and two clusters of suspected APT43 activity (UNC3782 and UNC4469), another group frequently targeting cryptocurrency users. 

Detection and Response The attack was initially detected when users reported that at least one AV product flagged actions of the 3CX’s Windows installer on March 22, 2023. Initially, many believed these were false positives. On March 29, 2023, security vendors like CrowdStrike and SentinelOne published reports confirming the supply chain attack. CISA became aware of open-source reports by March 30, 2023, and urged users and organizations to review reports from vendors and 3CX, and hunt for indicators of compromise (IOCs). 

The difficulty in detection was highlighted by the fact that the malicious macOS installer was both legitimately signed and notarized by Apple, indicating it passed Apple’s checks for malware at the time. 

Detection rules and validation actions were developed by security researchers and vendors: 

  • YARA Rules were provided to detect various components, including the key found in the malicious 3CX Desktop App file, specific exports, TAXHAUL, characteristics of the MSI installer, hashes related to TAXHAUL, strings in SigLoader (Native), bootstrap shellcode in DAVESHELL, characteristics of VEILEDSIGNAL, strings in POOLRAT, and characteristics of the Fast Reverse Proxy binary. 
  • Snort Rules were provided to detect possible malicious 3CXDesktopApp activity based on C2 communication patterns and the presence of strings like raw.githubusercontent.com/IconStorages/images/main/ and __tutma. 
  • Mandiant Security Validation offered actions to validate security controls related to UNC4736 command and control, host CLI actions, malicious file transfer (SUDDENICON), and evaluation of supply chain attack targeting. 

Mitigation and Best Practices Based on the analysis, key steps for organizations to defend against such attacks and lessons learned include: 

  • Promptly address alerts from security software, even if initially suspected of being false positives. 
  • Review and hunt for indicators of compromise (IOCs) provided by security vendors and authorities like CISA. 
  • Uninstall vulnerable versions of affected software, as advised by vendors. 
  • Be cautious about installing software, especially if it is discontinued, even if downloaded from a legitimate vendor’s website. Older software may not receive security updates and the distribution channel itself may become compromised over time. 
  • Implement network monitoring to detect suspicious C2 communications, including beaconing to known malicious domains or using unusual protocols/headers. Snort rules and DNS monitors can aid in this. 
  • Implement endpoint detection and response (EDR) solutions capable of detecting malicious behaviors, process injection, DLL side-loading, and persistence mechanisms. 
  • Utilize security validation tools to test existing defenses against known attack techniques used by the threat actor. 
  • Recognize that code signing and notarization do not guarantee software safety, as attackers can compromise build environments and sign malicious code with legitimate certificates. Additional scrutiny of software origin and integrity is necessary. 
  • Be aware of the potential for chained supply chain attacks, where a compromise of one software vendor can be leveraged to compromise another. This highlights the interconnectedness of the software ecosystem and the need for vigilance regarding third-party software dependencies. 
  • Monitor for  file system anomalies, such as the creation of unexpected files in user directories or system locations, or self-deletion of binaries. 

The 3CX compromise serves as a critical example of the complex and cascading nature of modern supply chain attacks and the sophisticated techniques employed by suspected state-sponsored actors like those linked to North Korea. 

more Related articles