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.
Data from our telemetry suggested that some versions of a similar customer engagement software, LiveHelp100 has also been weaponized. LiveHelp100 shares the same office address as Comm100, and both share one director. Findings from our investigation that began on Oct. 14, 2022 indicated that the client application had been loading backdoor scripts from the malicious actor’s infrastructure since Aug. 8, 2022. It is also worth noting that we were able to identify a JavaScript backdoor injected in the web application of LiveHelp100 as early as February 2022. We have sent messages to LiveHelp100 but have received no reply.
We could not determine, however, if the trojanized versions of LiveHelp100 were delivered using a similar supply-chain attack on its official website as Comm100 because the installers were not available when we were conducting our research. Our telemetry detected requests made by some of LiveHelp100’s clients to load JavaScript backdoors, likely the same ones that we had previously observed in the supply-chain attack on the Comm100 application. This prompted us to examine the infection chain more closely, enabling us to identify additional pieces of malware that the malicious actors employed in their campaign.
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.
Analysis of JavaScript backdoor
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:
- hxxp[:]//service[.]livehelpl00service[.]com/livehelp/collect
The payload returned from the URL is an obfuscated JavaScript code with backdoor functions for execution by the trojanized Electron.js applications. The URL format and backdoor functions are the same as those mentioned in the threat researchers’ report on the Comm 100 attack that we cited earlier. The backdoor sends the following victim information using HTTP POST request to initiate the communication with the command-and-control (C&C) server 8[.]219[.]76[.]37:
- Computer name
- Username
- 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 JavaScript backdoor receives commands from the C&C server. It supports two commands: first, the shell command to allow malicious actors to run a shell command in a newly spawned cmd.exe process, and second, the execute command to allow them to execute any JavaScript code on the victims’ machines.
We noticed that victims had been instructed to load a second-stage JavaScript payload from this URL:
- hxxp[:]//service[.]livehelpl00service[.]com/livehelp/init
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
- Creates the script index.js to load the aforementioned JavaScript backdoor, and then continues with the original execution of the LiveHelp100 application
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:
- <C&C>:<port>/down/case/log.bsh
- <C&C>:<port>/down/keeper/WindowsPlayer
- <C&C>:<port>/down/keeper/midlrtmd
- <C&C>:<port>/down/keeper/log.bsh
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:
- hxxp[:]//<C&C>:<port>/sugrec
- hxxp[:]//<C&C>:<port>/load.action/FixU
- hxxp[:]//<C&C>:<port>/load.action/html.xml
- hxxp[:]//<C&C>:<port>/load.action/kdump64
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.
First stage
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.
Second stage
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
- Username
- 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 8.218.67.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.
Update
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.
Modules
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.
| Name | Function |
| maisui | SOCKS5 proxy |
| webtoken | Skype and Telegram stealer |
| webcallinfo | Info and file stealer |
| webscreen | Take screenshot |
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
As previously mentioned, a notable finding in our investigation is that we were able to determine that the malicious actors behind this campaign had been successfully compromising the LiveHelp100 web application since February 2022. The injected code had been instructed to load JavaScript from the following URL:
- hxxps[:]//analyaze[.]s3amazonbucket[.]com/livechat/dll/tinymce.share.js
During our research, the URL returned a JavaScript backdoor that is different from the aforementioned one. This backdoor communicates with the C&C server using WebSocket. The victims’ information, including their LiveHelp100 ID and their system and browser information, was sent to the C&C server to initialise communication. After establishing the WebSocket connection, the backdoor also sent the browser’s cookie, a referrer, and a fingerprint value calculated as the MD5 hash of the victim’s system information. This backdoor allows the attacker to execute arbitrary JavaScript codes received from the C&C server.
Conclusion
Our investigation of the supply-chain attack on the LiveHelp100 software revealed the malicious actor’s sophisticated use of the trojanized Electron.js application to launch the JavaScript backdoor that has enabled the advanced stages of payload delivery. We also discovered multiple malware modules that have been stealing sensitive information from its targets. A noteworthy observation is that the abuse of the LiveHelp100 software is the third of its kind that we have examined of late. We have published two reports that discussed the abuse of other applications that were also based on the Electron framework. The first report, published in August 2022, highlights the research findings on the threat actor Iron Tiger, which also abused an Electron-based chat software for its supply-chain attack. The second report, published in October 2022, focuses on how Water Labbu weaponized an application based on Electron.js to steal cryptocurrency from scammers.
Indicators of Compromise (IOCs)
The Indicators of Compromise can be found here.