Probing Weaponized Chat Applications Abused in Supply-Chain Attacks
This report examines the infection chain and the pieces of malware used by malicious actors in supply-chain attacks that leveraged trojanized installers of chat-based customer engagement platforms.
Save to Folio
In late September 2022, threat researchers uncovered a supply-chain attack carried out by malicious actors using a trojanized installer of Comm100, a chat-based customer engagement application. Our investigation of the incident revealed that the breadth and depth of the campaign’s impact were greater than what the researchers had initially thought; we also found that more applications and their respective versions had been affected and established that attacks began much earlier than their first reckoning on Sept. 29, 2022.
Interestingly, we also discovered that some of the victims that had been targeted with the more advanced stages of the malware deployment were personnel of online gambling platforms that have access to the administration panel of their respective websites, suggesting that this might also be one of the campaign’s objectives.
The Windows and macOS versions of the LiveHelp100 client application are developed with the Electron.js runtime framework. Data from our telemetry revealed two versions of this application, 11.0.2 and 11.0.3, that have been attempting to communicate with the following URL since August 8, 2022:
- Computer name
- The process list retrieved from tasklist command
- The product ID value stored in the registry
- The email information stored in a data file of the LiveHelp100 application
The second-stage script is responsible for trojanizing the original LiveHelp100 application and dropping the malware for the next phase of the infection.
The second-stage script checks the resources folder of the LiveHelp100 application. This folder is used for storing the main Electron.js application code. When it determines that the LiveHelp100 application has not been trojanized yet, it proceeds to do the following and creates files in the application’s resources folder:
- Copies all Node.js modules inside the LiveHelp100 ASAR package that contains the main application scripts
- Creates a new package.json file to set the main Electron.js script to ./index.js
After trojanizing the application, the script drops multiple files and executes them to load the backdoor from the next stage of the infection routine. We discuss our analysis of the backdoor in the next section.
Analysis of the Executable Backdoor
The second-stage script drops three files. The files include a legitimate and signed executable, WebAccess.exe, a DLL file that is a decryptor, midlrtmd.dll, and an encrypted binary file, Copyright.txt. The script executes the executable file to sideload the decryptor DLL file. The DLL file will then decrypt Copyright.txt and execute the decrypted payload for the first stage of the executable payload.
The goal for the first stage is to download and execute the payload for the second stage. The second stage is a refactored code with functions similar to the malware discussed in this report. It also collects various machine information, along with loading additional modules from URLs listed here:
As of this writing, the server was no longer accessible, so no payload was served. We traced the C&C server to static-files[.]livelyhellp[.]chat:888. After observing that the malicious actor’s use of the file name log.bsh was unique, we tried to find out more about it. Our search led us to backdoors written in Golang language, suggesting a possible link to the LiveHelp100 campaign.
We also discovered a more recent active chain, deployed between Oct. 8 and 12, 2022. We observed that victims infected with the trojanized LiveHelp100 application were instructed to download and execute the following files from delivery server s[.]livelyhellp[.]chat:
This new chain starts with three files: first, a legitimate and signed rcmdhelper.exe with DLL-sideloading vulnerability, and then kdump64.dll, which is the decryptor and loader, and lastly, html.xml, which contains the encrypted payload for the first stage of the executable backdoor.
Malicious actors use this stage as a downloader of the next stage using sockets. The C&C server name is encrypted by simply adding a constant value to each byte of the server’s name.
The communication to the C&C server in this case is unencrypted and only contains the command number, 0x09, to download the second stage.
The payload received from the C&C server contains the size of the payload (first DWORD = 0x7a200), followed by the second stage payload itself, using 0x4d 0x5a as PE EXE marker.
Notably, the second stage of the infection chain is more complex and contains more functions:
1. Thread with anti-debugging feature; exits if debugger is detected.
2. Thread to repetitively delete files from %LOCALAPPDATA%\\Programs\\Comm100LiveChat\\resources\\app directory
3. Gets machine information, such as the following:
- IP address
- Device name
- Running process name
- Windows product name
- Events with event ID 6005 (the event log service was started), events with Event ID 6006 (the event log service was stopped)
- Any TCP endpoints listening on ports 8090, 8091, 8092, 8093, 8094, 8095, 8096
- Any TCP endpoint established to 188.8.131.52:18024
- Antivirus product name
- If Skype or Telegram is installed
- Number of connected monitors
- Product ID value from Windows registry
The machine information is then sent as a binary structure in unencrypted form to the C&C server.
4. Based on the response from the C&C server, the second stage can run some of the following features:
- Get the availability of the local ports from 8090 to 8096. The function tries to bind to the local host ports to prevent them from being used by another program, based on web browsers installed on the machine. If this task is successful, it means that the given port is available for use in remote browser debugging. For this purpose, it detects the following browsers: 0="极速浏览器X" (translated as “360 fast browser X”); 1="360", 2="Microsoft Edge", 3="QQ", 4="傲游" (translated as “Maxthon browser”); 5="Chrome", 6="Opera" and if found, reports if ports 8090 to 8096 are available or not.
- Steal browser history and cookies files:
\\Opera Software\\Opera Stable\\History -> C:\\ProgramData\\ohis
\\360ChromeX\\Chrome\\User Data\\Default\\Cookies -> C:\\ProgramData\\3phis
\\360se6\\User Data\\Default\\Cookies -> C:\\ProgramData\\3shis
\\Microsoft\\Edge\\User Data\\Default\\History -> C:\\ProgramData\\ehis
\\Tencent\\QQBrowser\\User Data\\Default\\History -> C:\\ProgramData\\qhis
\\Google\\Chrome\\User Data\\Default\\History -> C:\\ProgramData\\chis
\\Maxthon\\Application\\User Data\\Default\\History -> C:\\ProgramData\\mhis
- Modify browser shortcuts:
Search shortcuts in \\AppData\\Roaming\\Microsoft\\Internet Explorer\\Quick Launch, C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs, C:\\Users\\Public\\Desktop; Desktop, \\AppData\\Roaming\\Microsoft\\Internet Explorer\\Quick Launch\\User Pinned\\TaskBar, and modify them to include parameter “--remote-debugging-port=<>”
When a Chromium-based browser is run with remote debugging enabled, accessing the specified port presents a list of tabs and URLs that have been opened there. This allows attackers to spy on the victims’ current browsing activities.
a. Download, decrypt, and load http: //<C&C>:<port>/down/maisui module
b. Download, decrypt, and load http:// <C&C>:<port>/down/webtoken module
c. Download, decrypt, and load http:// <C&C>:<port>/down/webcallinfo module
d. Download, decrypt, and load http:// <C&C>:<port>/down/webscreen module
e. Download, decrypt, and load update from http:// <C&C>:<port>/down/update/
f. Download, decrypt, and load from download directory http:// <C&C>:<port>/down/
In our testing scenario, we only observed downloads of the update from http:// <C&C>:<port>/down/update/7.zip.
The C&C server and the port had the following value, hard-coded and encrypted in the second-stage executable binary: files[.]amazonawsgarages[.]com:888.
The update packet received from the C&C server contains the update file name 7.zip, downloaded from /down/update/ directory. This file path was used so that the payload can be saved to C:\Users\Public\Folder.zip. The packet contains an update file that indicates where it is to be downloaded from and where it will be saved. After downloading, the contents of the archive are extracted and saved as a file, with the information also contained in the packet. The name of the file to be executed is saved to C:\Users\Public\Folder\RcmdHelper.exe. The packet starts with its length, DWORD 0x384, followed by internal command ID, update = DWORD 0x3ef, followed by the command data itself.
The updated package is a modified version of the first-stage loader. Again, it uses three files: a legitimate and signed EXE file with a sideloading vulnerability, a DLL file as a decryptor and loader, and a binary file with encrypted content.
The decryptor is now modified to execute the following:
1. Load encrypted first-stage data from the binary file if it exists and decrypt it using a custom RC4-like algorithm. The password is hard-coded in the DLL file.
Figure 13. Code for loading encrypted first-stage data from the binary file
2. Encrypt the data again, this time with password derived from the computer name, then store encrypted data in registry and delete the third binary file.
3. For succeeding executions, read the encrypted first-stage data from the registry and run it.
We found the following modules that were developed using Golang. The downloaded modules are encrypted with a simple XOR algorithm, starting from the end of the file and applying XOR (n-1)th byte with nth one.
|webtoken||Skype and Telegram stealer|
|webcallinfo||Info and file stealer|
The SOCKS5 proxy module listens on the local host on port 61182.
Webcallinfo steals various machine information such as the current user, public IP address, private IP address, virtual private network (VPN) IP address, region, MAC address, Wi-Fi information, device name, identities, chat applications installed (such as Telegram or Skype), and browser bookmarks, password, and history - and saves them to a file called 机器信息.html, translated as “machine information.html.”. It also takes screenshots and steals files from directories \\Desktop, \\桌面文件, translated as “Desktop files” as well as \\Downloads, \\下载文件, translated as “downloads.” It compresses all stolen information into a ZIP file and uploads the archive to Aliyun’s or Alibaba’s cloud bucket called “qiongdechitu” or “窮的吃土,” loosely translated as, “He is poor, spent all his money, needs to eat dust for the rest of the month.”
For modules to access Object Storage Service (OSS) and the assigned bucket, the Security Token Service (STS) needs to generate temporary credentials to grant access to users. These temporary credentials are obtained by sending a GET request to another hard-coded URL. These credentials are then used to communicate with the appropriate bucket.
The webtoken module steals Skype cookies, steals \\tg and \\tdata directories from Telegram and uploads them in the same way as webcallinfo does.
The webscreen module takes screenshots and uploads them also in the same manner as webcallinfo.
Key finding: Establishing the onset of the attacks in February 2022
Indicators of Compromise (IOCs)
The Indicators of Compromise can be found here.