All posts by Anna Širokova

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign

Post Syndicated from Anna Širokova original https://blog.rapid7.com/2025/05/22/nsis-abuse-and-srdi-shellcode-anatomy-of-the-winos-4-0-campaign/

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign

Co-authored by Ivan Feigl

Executive summary

Rapid7 has been tracking a malware campaign that uses fake software installers disguised as popular apps like VPN and QQBrowser—to deliver Winos v4.0, a hard-to-detect malware that runs entirely in memory and gives attackers remote access.

The campaign was first spotted during a February 2025 MDR investigation. Since then, we’ve seen more samples using the same infection method—a multi-layered setup we call the Catena loader. Catena uses embedded shellcode and configuration switching logic to stage payloads like Winos v4.0 entirely in memory, evading traditional antivirus tools.

Once installed, it quietly connects to attacker-controlled servers—mostly hosted in Hong Kong—to receive follow-up instructions or additional malware. While we’ve seen no signs of widespread targeting, the operation appears focused on Chinese-speaking environments and shows signs of careful, long-term planning by a capable threat group.

Rapid7 has deployed detections for this activity and continues to monitor for new variants. Indicators and analysis related to this campaign are available in Rapid7 Intelligence Hub.

Introduction

This blog covers a malware campaign tracked by Rapid7 that uses trojanized NSIS installers to deploy Winos v4.0, a stealthy, memory-resident stager. The first sample was flagged during a February 2025 MDR investigation. Following that case, we identified additional related samples through threat hunting and malware analysis.

All observed samples relied on NSIS installers bundled with signed decoy apps, shellcode embedded in `.ini` files, and reflective DLL injection to quietly maintain persistence and avoid detection. We refer to this full infection chain as Catena, due to its modular, chain-like structure.

The campaign has so far been active throughout 2025, showing a consistent infection chain with some tactical adjustments—pointing to a capable and adaptive threat actor.

In this report, we start with a brief recap of the February 2025 MDR incident, which was also covered by other researchers. We then focus on newer samples found later in 2025 that follow the same core infection chain but introduce changes in delivery, tooling, and evasion—highlighting how the campaign continues to evolve.

How it started: QQBrowser Installer in MDR Case

In February 2025, Rapid7’s MDR team detected suspicious activity on a customer asset involving a trojanized NSIS installer masquerading as QQBrowser installer `QQBrowser_Setup_x64.exe`. While the file initially appeared legitimate, further analysis revealed it delivered malware via a multi-stage, memory-resident loader chain. Upon execution, the installer created an Axialis directory under %APPDATA% and dropped several files:

  • `Axialis.vbs` – a VBScript launcher
  • `Axialis.ps1` – a PowerShell-based loader
    `Axialis.dll` – a malicious DLL
  • `Config.ini` and `Config2.ini` – binary configuration files containing shellcode and embedded payloads
  • A desktop shortcut and the original QQBrowser setup binary used for deception

Upon execution, the malware follows this chain shown below.

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign
Figure 1: QQBrowser-Based Infection Flow Observed in MDR Case

During runtime analysis, the `Axialis.dll` loader creates the mutex `VJANCAVESU` via the `CreateMutexA` API. If the mutex exists, it loads `Config2.ini`; if not, it loads `Config.ini`.

This behavior has been described by other researchers, who observed similar configuration switching logic in the DeepSeek campaigns — where the selected payload depended on the infection state. Both `.ini` files contain shellcode and embedded payload DLLs, all loaded and executed reflectively in memory.

Rapid7 analysis confirmed that the shellcode in `Config.ini` was built using the open-source sRDI loader.

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign
Figure 2: Side-by-side comparison of shellcode from GitHub (left) and shellcode found in Config.ini (right)

The malware communicates with hardcoded command-and-control (C2) infrastructure over TCP port 18856 and HTTPS port 443.

Persistence is achieved through a combination of process monitoring and scheduled task registration. The embedded DLL in `Config.ini` created and executed  `Monitor.bat`, which continuously checked for malware processes and relaunched them if terminated.  ​​To ensure persistence, the malware dropped `updated.ps1` and `PolicyManagement.xml`, which are used to register a scheduled task that re-executes the VBS loader `Decision.vbs` via `wscript.exe`.

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign
Figure 3: Scheduled Task Triggering VBS Loader Decision.vbs

The scheduled task executed weeks after initial compromise, suggesting long-term persistence. Interestingly, the malware includes a language check that looks for Chinese language settings on the host system. But even if the system isn’t using Chinese, the malware still executes. This suggests the check isn’t actually enforced—it could be a placeholder, an unfinished feature, or something the attackers plan to use in future versions. Either way, its presence hints at an intent to focus on Chinese-language environments, even if that logic isn’t fully implemented yet.

While infrastructure details (e.g., C2 IPs) varied, for example in our case involving 156.251.17.243[:]18852 and the reference blog citing  27.124.40.155[:]18852 — both campaigns used similar communication ports (18852 and 443), suggesting that the activity belongs to the same threat actor.

Campaign evolution

Following the initial discovery, Rapid7 continued tracking the campaign throughout early 2025. During this period, multiple incidents were observed reusing the same infection chain—abusing trojanized NSIS installers, reflective DLL loading, shellcode-embedded INI files, and staged persistence mechanisms. These variants were often disguised as legitimate software such as LetsVPN, Telegram, or Chrome installers.

However, in April 2025, we observed a tactical shift. Threat actors began modifying their approach: for instance, staging scripts like `Axialis.ps1` were dropped entirely, DLLs were invoked directly using `regsvr32.exe`, and new samples showed more efforts to evade antivirus detection. These changes suggest an evolving playbook—one that retains core infrastructure and execution logic but adapts to detection pressure and operational constraints.

Evolving tactics: LetsVPN Installer leading to Winos v4.0

The diagram below illustrates the Catena execution chain as observed in the LetsVPN variant.

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign
Figure 4 Catena Loader: From LetsVPN Installer to Winos v4.0

The following sections break down this chain, stage by stage—from the initial installer and script logic to in-memory payload delivery and infrastructure interaction.

Our analysis started with `Lets.15.0.exe` SHA-256: 1E57AC6AD9A20CFAB1FE8EDD03107E7B63AB45CA555BA6CE68F143568884B003, a trojanized NSIS installer masquerading as a VPN setup. The installer included a decoy executable `Iatsvpn–Latest.exe` and a license file to appear legitimate. However, its true purpose was to deploy multi-stage, memory-resident malware across several directories.

Upon execution, the installer stages components in:

  • %LOCALAPPDATA%: first-stage loader `insttect.exe` and shellcode blob `Single.ini`
  • %APPDATA%\TrustAsia: second-stage payloads `Config.ini`, `Config2.ini` and loader DLL `intel.dll`
NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign
Figure 5: The extracted file structure by Lets.15.0.exe

The following sections walk through each step of this chain, starting with the NSIS installer and leading to in-memory payload execution.

Installer setup: NSIS script behavior

The `NSIS.nsi` script embedded in `Lets.15.0.exe` sets up both the fake VPN installation and the deployment of malware. It acts as the first step in the execution chain. The script starts by running a PowerShell command that adds Defender exclusions for all drives (C:\ to Z:), reducing system defenses.

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign

First-stage payloads

The NSIS script begins by dropping initial payloads to %LOCALAPPDATA%:

  • `Single.ini`: a binary blob combining sRDI shellcode and an embedded DLL
  • `insttect.exe`: loader that reads and executes `Single.ini` in memory

Second-stage payloads

Next, the script drops second-stage files to %APPDATA%\TrustAsia:

  • `Config.ini`, `Config2.ini`: alternate sRDI payloads loaded later based on mutex logic
  • `intel.dll`:  a secondary loader invoked via regsvr32.exe

To trigger this second stage, the NSIS script executes:

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign

As seen in the February 2025 MDR incident, the NSIS script completes the decoy setup by dropping `IatsvpnLatest.exe`ba0fd15483437a036e7f9dc91a65caa6e9b9494ed3793710257c450a30b88b8a and creating a desktop shortcut pointing to it. Despite the filename containing a typo, the binary is a legitimate LetsVPN executable, signed with a valid digital certificate.

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign
Figure 6: Malicious NSIS script

The following sections outline the role of each dropped binary in the execution chain.

Stage 1: Execution of insttect.exe and Single.ini file

We analyzed `insttect.exe`, a trojanized loader masquerading as a legitimate Tencent PC Manager installer. The binary, titled 腾讯电脑管家在线安装程序 (machine translation: “Tencent PC Manager Online Installation Program” (in both metadata and resource strings).

The binary is signed with an expired certificate issued by VeriSign Class 3 Code Signing CA (2010) and allegedly belongs to Tencent Technology (Shenzhen), valid from 2018-10-11 to 2020-02-02.

The binary includes deceptive artifacts such as localized UI strings in Chinese, internal references to Tencent development paths, and hardcoded XML updater config pointing to `QQPCDownload.dll`

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign
Figure 7: Hardcoded PDB path from `insttect.exe`

These elements reinforce the loader’s appearance as legitimate software.

Upon execution, `insttect.exe` locates `%LOCALAPPDATA%\Single.ini`, allocates memory with PAGE_EXECUTE_READWRITE permissions, copies the file into that region, and transfers control to its start. As previously described, the payload uses the sRDI format—enabling the embedded shellcode to self-parse and reflectively load the DLL without separate extraction.

Windows API calls related to shellcode loading are resolved dynamically via hashed function names.

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign
Figure 8: Hashed API Resolution Routine

The DLL embedded within `Single.ini` takes a snapshot of running processes and continuously checks for `360tray.exe` and `360safe.exe`. These are components of 360 Total Security, a popular antivirus product developed by Chinese vendor Qihoo 360.

However, when tested with a dummy `360tray.exe`, the malware showed no response—neither terminating the process nor altering its own behavior.

Stage 2: Execution of intel.dll and Config.ini files

The `.nsi script` drops `intel.dll`, `Config.ini`, and `Config2.ini` into %APPDATA%\TrustAsia, and uses nsExec::Exec to invoke intel.dll via a regsvr32 call.

Both `Config.ini` and `Config2.ini` initially appeared benign due to their generic names. However, as with earlier payloads, both `.ini` are binary blobs containing shellcode formatted using the Shellcode Reflective DLL Injection (sRDI) technique described earlier.

As noted in the QQBrowser case, earlier variants loaded the shellcode from disk using PowerShell scripts. In this version, execution is handled entirely in memory via `regsvr32.exe`, which invokes `intel.dll`. As is typical for DLLs executed this way, `intel.dll` exports the `DllRegisterServer` function, which is automatically called.

While this shift avoids PowerShell, it’s not necessarily more evasive, since `regsvr32.exe` is a well-known LOLBin and is commonly monitored by modern EDR solutions. Upon execution, `intel.dll` loader creates a hardcoded mutex `99907F23-25AB-22C5-057C-5C1D92466C65` using the `CreateMutexA` API, and checks for the presence of two indicators: the mutex itself, and a file named `Temp.aps` in %APPDATA%\TrustAsia. If both are found, `Config2.ini` is loaded; otherwise, the default `Config.ini` is used.

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign
Figure 9: Handle to Config.ini being returned

Once the appropriate `.ini` file is chosen, the loader opens it using `CreateFileW` and loads its contents into memory. As seen in earlier stages, the `.ini` file contains a shellcode blob using the sRDI format, which self-parses and reflectively loads an embedded DLL.

The in-memory DLL, extracted and executed entirely from within the shellcode blob, exports a single function named `VFPower`, a naming convention consistent across all observed samples. Debug symbols embedded in the DLL reference a Chinese development path E:\冲锋\进行中\Code_Shellcode – 裸体上线用作注入\Release\Code_Shellcode.pdb (machine translation: E:\Charge\In Progress\Code_Shellcode – Naked online for injection \ Release \ Code _ Shellcode.pdb).

During runtime, this in-memory DLL creates a hardcoded mutex `zhuxianlu` (machine translation: main line) and verifies if it was launched from `UserAccountBroker.exe`. If true, it immediately initiates C2 communication, likely assuming it was started with elevated privileges. Otherwise, the malware continues execution by spawning five threads, each responsible for a specific task before ultimately reaching the same C2 routine.

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign
Figure 10: Mutex Check and C2 Trigger Logic

The five threads carry out the following actions:

Thread 1 launches PowerShell via `ShellExecuteExA` to add a Microsoft Defender exclusion for the C:\ drive.

Thread 2 attempts to establish persistence via scheduled task registration as seen in the earlier QQBrowser incident described in the introduction. It generates two files:

`PolicyManagement.xml` — an XML file defining a scheduled task

`updated.ps1` — a PowerShell script that imports and registers the task

To ensure the script runs without restriction the malware first sets PowerShell policies to `Unrestricted` (for the current user) and `Bypass` (for the specific script). The scheduled task is configured to invoke `regsvr32.exe` at logon, which in turn re-executes either `intel.dll` or `insttect.exe` loader.

Although this operation failed during our analysis even with the Chinese language pack installed, it was attempted twice—we believe to ensure redundancy or persistence across both loaders. Both files `PolicyManagement.xml` and `updated.ps1` are deleted immediately after execution.

Thread 3 takes a snapshot of all running processes and scans for any instance of `Telegram.exe`, `telegram.exe`, or `WhatsApp.exe`. If any of these are detected, it creates an empty marker file named `Temp.aps` in %APPDATA%\TrustAsia, and then executes:

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign

This triggers the second-stage loader. The presence of the `Temp.aps`alters the loader’s behavior, causing it to run `Config2.ini` instead of `Config.ini`.

Thread 4 checks for the existence of the file `TrustAsia\Exit.aps`. If found, the file is deleted and the malware terminates.

Thread 5 acts as a persistence watchdog for the second-stage loader. It creates two files: `target.pid`, which stores the process ID of the running regsvr32.exe instance executing `intel.dll` loader, and `monitor.bat`, a batch script that checks whether this process is still running. If not, the script attempts to relaunch it. This check runs every 15 seconds to ensure `intel.dll` remains continuously active.

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign
Figure 11: Content of monitor.bat watchdog

Following thread execution, the final function is responsible for C2 communication. Since the earliest observed sample from February 2024, the malware has used Windows sockets and the `getaddrinfo` API to resolve a hardcoded IP and port 18852 which also seems to be consistent across all analyzed samples of `Config.ini`.

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign

Once the connection is established, malware retrieves the next-stage payload from the C2 server, allocates a new memory region with PAGE_EXECUTE_READWRITE permissions, copies the downloaded content into memory, and transfers execution to it. This is the delivery of the final stage, observed as Winos v4.0 in recent samples.

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign
Figure 12: Jump to final payload

Final payload Winos4.0

The `intel.dll` loader selects either `Config.ini` or `Config2.ini` based on runtime conditions, such as the presence of a mutex `VJANCAVESU` and a `Temp.aps` marker file. Each of these `.ini` files contains sRDI shellcode that connects to a different C2 server to download the next-stage payload which was Winos4.0 in our case.

In recent samples, the payloads were downloaded from:

`Config.ini` → 134.122.204[.]11:18852

`Config2.ini` → 103.46.185[.]44:443

Although being retrieved from different C2 servers, both payloads were nearly identical: 112 KB in size and structured as sRDI shellcode containing an embedded DLL. This DLL uses the same reflective loading technique seen in previous stages, exports a single-function `VFPower` and and includes debug metadata referencing a Chinese development path:

C:\Users\Administrator\Desktop\Quick4\主插件\Release\上线模块.pdb (machine translation: C:\Users\Administrator\Desktop\Quick4\Main Plug-in\Release\Online Module.pdb)

Based on available evidence supported by debug info, we can say this is Winos4.0 stager `上线模块.dll`( machine translation: `Online Module.dll`.)

Extracted configuration

The Winos v4.0 stager downloaded from 134.122.204[.]11:18852 contains an embedded configuration block. The data appears to control runtime behavior, C2 communication, and implant settings. A decoded sample is shown below:

Extracted Configuration from Payload (134.122.204[.]11:18852)

Configuration Data Description
p1 134.122.204[.]11 First CC IP address
o1 6074 First port
t1 1 Protocol (TCP)
p2 134.122.204[.]11 Second CC IP address
o2 6075 Second option port
t2 1 Protocol (TCP)
p3 134.122.204[.]11 Third CC IP address
o3 6076 Third option port
t3 1 Protocol (TCP)
dd 1 Implant execution delay in seconds
cl 1 Beaconing interval in seconds
fz 认默 (default) Grouping
bb 1.0 Version
bz 2025.4.24 Generation date
jp 0 Keylogger
bh 0 End bluescreen
ll 0 Antitraffic monitoring
dl 0 Entry point
sh 0 Process daemon
kl 0 Process hollowing
bd 0 N/A

In previous incidents, Winos 4.0 has been linked to the Silver Fox APT group operation known for distributing malware like ValleyRAT via trojanized utilities and vulnerability exploitation. Notably, similar TTPs were observed in the CleverSoar campaign described by Rapid7 in November 2024 which also delivered Winos4.0 and checked system locale settings for Chinese or Vietnamese—suggesting targeting based on regional language.

Infrastructure

During our investigation, the hardcoded IP address 103.46.185[.]44 found in `Config.ini` was confirmed to host the final Winos 4.0 payload. Shodan scans showed it serving a binary blob that begins with recognizable sRDI shellcode and contains an embedded DLL identical to the Winos 4.0 stager (“Online Module”) analyzed in this report.

Pivoting on this sample using Shodan hash -646083836, we identified eight additional IPs distributing the exact same payload: 112.213.101[.]161, 112.213.101[.]139, 103.46.185[.]73, 47.83.184[.]193, 202.79.173[.]50, 202.79.173[.]54, 202.79.173[.]98, and 103.46.185[.]44.

Each host returned identical byte sequences, indicating a shared and coordinated infrastructure distributing the same stage-one loader across multiple nodes, mostly hosted in Hong Kong.

NSIS Abuse and sRDI Shellcode: Anatomy of the Winos 4.0 Campaign
Figure 13: Shared Hosting of Identical Winos v4.0 Payloads

To expand this infrastructure mapping, we extracted additional C2 addresses from historic MDR case data and active threat hunting leads. These included:

43.226.125[.]44:18852, 47.238.125[.]85:18852, 137.220.229[.]34:18852, 8.210.165[.]181:18852, 143.92.61[.]154:18852, 47.86.28[.]28:18852, 202.79.168[.]211:443, 27.122.59[.]71:443,
143.92.63[.]144:18852, 202.79.171[.]133:443, 112.213.116[.]91:18852

Pivoting on these nodes using Shodan hash correlations revealed additional infrastructure often resolving to the same ASNs or hosting providers, such as

CTG Server Ltd. / MEGA-II IDC (AS152194)
OK COMMUNICATION / LANDUPS LIMITED (AS150452)
Alibaba Cloud (AS45102)
Tcloudnet, Inc. (AS399077)

Conclusion

This campaign shows a well-organized, regionally focused malware operation using trojanized NSIS installers to quietly drop the Winos v4.0 stager. It leans heavily on memory-resident payloads, reflective DLL loading, and decoy software signed with legit certificates to avoid raising alarms.

The malware’s logic—using mutexes to choose payloads, hiding shellcode in INI files, and layering persistence tricks like scheduled tasks and watchdog scripts—points to an actor that’s refining, not reinventing, their playbook. Infrastructure overlaps and language-based targeting hint at ties to Silver Fox APT, with activity likely aimed at Chinese-speaking environments. Rapid7 continues to track this threat and has detections in place to help protect customers.

Indicators of compromise

File Indicators

Config2.ini 4CB2CAB237893D0D661E2378E7FE4E1BAFBFAEFD713091E26C96F7EC182B6CD0
Config.ini E2490CFD25D8E66A7888F70B56FF8409494DE3B3D87BC5464D3ADABBA8B32177
Iatsvpn-Latest.exe E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
InstallOptions.dll B2091205E225FC07DAF1101218C64CE62A4690CACAC9C3D0644D12E93E4C213C
insttect.exe 4FDEDADAA57412E242DC205FABDCA028F6402962D3A8AF427A01DD38B40D4512
ioSpecial.ini D95AED234F932A1C48A2B1B0D98C60CA31F962310C03158E2884AB4DDD3EA1E0
nsExec.dll 01E72332362345C415A7EDCB366D6A1B52BE9AC6E946FB9DA49785C140BA1A4B
setup.xml E036D5E88A51008B130673AD65872559C060DEEB29A0F8DA103FE6D036E9D031
modern-wizard.bmp 3AD2DC318056D0A2024AF1804EA741146CFC18CC404649A44610CBF8B2056CF2
Single.ini B22599DD0A1C44CA1B35DF16006F3085BDDAE3EBBA6A3649EC6E4DC4CBF74865
System.dll 9111099EFE9D5C9B391DC132B2FAF0A3851A760D4106D5368E30AC744EB42706
[LICENSE].txt 16C79970ED965B31281270B1BE3F1F43671DFAF39464D7EAC38B8B27C66661CF
[NSIS].nsi 47AD38ADC3B18FB62A8E0A33E9599FD0B90D9DE220D1A18B6761D035448C378F
QQPCDownload.dll 28D2477926DE5D5A8FFCB708CB0C95C3AA9808D757F77B92F82AD4AA50A05CC8
intel.dll B8E8A13859ED42E6E708346C555A094FDC3FBD69C3C1CB9EFB43C08C86FE32D0
monitor.bat 5767D408EC37B45C7714D70AE476CB34905AD6B59830572698875FC33C3BAF2F

Network Indicators

156.251.17.243[:]18852

134.122.204.11[:]18852

103.46.185.44[:]443

MITRE TTPs

ATT&CK ID Name
T1204.002 User Execution: Malicious File
T1053.005 Scheduled Task/Job: Scheduled Task
T1562.001 Impair Defenses: Disable or Modify Tools
T1218.010 System Binary Proxy Execution: Regsvr32
T1218.011 System Binary Proxy Execution: Rundll32
T1070.004 Indicator Removal: File Deletion
T1036.004 Masquerading: Masquerade Task or Service
T1027.013 Obfuscated Files or Information: Encrypted/Encoded File
T1055.001 Process Injection: Dynamic-link Library Injection
T1071.001 Application Layer Protocol: Web Protocols
T1059.001 Command and Scripting Interpreter: PowerShell
T1620 Reflective Code Loading
T1057 Process Discovery
T1083 File and Directory Discovery
T1105 Ingress Tool Transfer

More IOCs in our Github

https://github.com/rapid7/Rapid7-Labs/tree/main/IOCs/nsis-abuse-srdi-winos4

Rapid7 customers

InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7’s expansive library of detection rules. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to Catena. We will also continue to iterate detections as new variants emerge, giving customers continuous protection without manual tuning:

  • Suspicious Scheduled Task – Potential QQBrowser Scheduled Task Identified
  • Suspicious Process – Potential QQBrowser Second Stage Execution

A Bag of RATs: VenomRAT vs. AsyncRAT

Post Syndicated from Anna Širokova original https://blog.rapid7.com/2024/11/21/a-bag-of-rats-venomrat-vs-asyncrat/

Introduction

A Bag of RATs: VenomRAT vs. AsyncRAT

Remote access tools (RATs) have long been a favorite tool for cyber attackers, since they enable remote control over compromised systems and facilitate data theft, espionage, and continuous monitoring of victims. Among the well-known RATs are VenomRAT and AsyncRAT. These are open-source RATs and have been making headlines for their frequent use by different threat actors, including Blind Eagle/APT-C-36, Coral Rider, NullBulge, and OPERA1ER. Both RATs have their roots in QuasarRAT, another open-source project, which explains their similarities. However, as both have evolved over time, they have diverged in terms of functionalities and behavior, which affects how attackers use them and how they are detected.

Interestingly, as these RATs evolved, some security vendors have started to blur the line between them, often grouping detections under a single label, such as AsyncRAT or AsyncRAT/VenomRAT. This indicates how closely related the two are, but also suggests that their similarities may cause challenges for detection systems. We took a closer look at recent samples of each RAT to examine how they differ, if at all.

This comparison explores the core technical differences between VenomRAT and AsyncRAT by analyzing their architecture, capabilities, and tactics.

Here’s a comparison table between VenomRAT and AsyncRAT based on the findings

Capability VenomRAT AsyncRAT
AMSI Bypass ✔ Patches AmsiScanBuffer in amsi.dll (In-memory patching) T1562.001 ✘ Not implemented
ETW Bypass ✔ Patches EtwEventWrite in ntdll.dll (In-memory patching) T1562.006 ✘ Not implemented
Keylogging ✔ Advanced keylogger with filtering and process tracking T1056.001 ✔ Basic keylogger with clipboard logging T1056.001
Anti-analysis Techniques ✔ Uses WMI for OS detection, VM check T1497.001 ✔ VM, sandbox, and debugger detection T1497
Hardware Interaction ✔ Collects CPU, RAM, GPU, and software data using WMI T1082 ✔ Collects system data via Win32_ComputerSystem T1082
Process discovery ✔ This the capability to obtain a listing of running processes T1057 ✘ Not implemented
Anti-process Monitoring ✔ Terminates system monitoring and security processes T1562.009 ✘ Not implemented
Webcam Access ✔ Camera detection and access T1125 ✘ Not implemented
Dynamic API Resolution ✔ DInvokeCore class for dynamic API resolution T1027.007 ✘ Not implemented
Encrypts the configuration ✔ 16-byte salt ("VenomRATByVenom") T1027.013 ✔ 32-byte binary salt T1027.013
Error Handling ✔ Silent failures with basic try-catch ✔ Sends detailed error reports to C2 T1071

Technical analysis

In this technical analysis, we compare two specific RAT samples:

  • VenomRAT: 1574d418de3976fc9a2ba0be7bf734b919927d49bd5e74b57553dfc6eee67371AsyncRAT: caf9e2eac1bac6c5e09376c0f01fed66eea96acc000e564c907e8a1fbd594426

Both AsyncRAT and VenomRAT are open-source remote access tools developed in C# and built on the .NET Framework (v4.0.30319). A preliminary analysis based on CAPA results revealed several shared characteristics between the two. For example, both RATs use standard libraries like System.IO, System.Security.Cryptography, and System.Net for file handling, encryption, and networking. They also have common cryptographic components such as HMACSHA256, AES, and SHA256Managed, indicating similar encryption routines. Indeed, upon closer code examination, we found that their encryption classes were identical, with only one minor difference: AsyncRAT uses a 32-byte binary salt, while VenomRAT uses a 16-byte salt derived from the string “VenomRATByVenom.” Additionally, both RATs share similarities in configuration handling, mutex creation, and parts of their anti-analysis class.

However, the CAPA analysis also highlighted distinct differences between the two. Certain features present in one RAT were notably absent in the other. To verify, we manually reviewed code in both samples and described the differences below.

Keylogging and System Hooking

In the samples we analyzed the keylogger was present only in VenomRAT. However, the open-source version of AsyncRAT has a keylogger plugin. We therefore decided to investigate whether the VenomRAT keylogger implementation is the same as AsyncRAT’s implementation. Our findings suggest that the keylogging functionality is different. We summarized a comparative analysis of their keylogging implementations in the table below. Additionally, the VenomRAT keylogger configuration file DataLogs.conf and log files are saved in the user’s %AppData%\MyData folder.

Feature VenomRAT AsyncRAT
Low-level keyboard hook (WH_KEYBOARD_LL) ✔ ✔
Keystroke Processing ✔ ✔
Window/Process Tracking Tracks both process and window title Tracks window title only
Clipboard Logging ✘ ✔
Log Transmission Periodic log sending to C2 Continuous log sending to C2
Filtering Mechanism ✔ ✘
Error Handling Silent failures with basic try-catch Sends detailed error reports to C2
Additional Features Focused on keystrokes Handles both keystrokes and clipboard
Thread Management ✘ ✔

Anti-Analysis

Both AsyncRAT and Venom RAT have similar implementations of the anti-analysis classes. However, we can see notable differences. AsyncRAT focuses on a broad spectrum of detection techniques, including:

  • Virtual Machine Detection: It checks for known system manufacturer names such as VMware,VirtualBox, or Hyper-V.
  • Sandbox Detection: It looks for sandbox-related DLLs, such as SbieDll.dll from Sandboxie.
  • Debugger Detection: AsyncRAT uses CheckRemoteDebuggerPresent to detect if it’s being monitored by a debugger.
  • Disk Size Check: It avoids execution on machines with less than 60GB disk size.

On the other hand, VenomRAT uses a more targeted approach. The virtual machine detection method in VenomRAT relies on querying system memory through WMI (Windows Management Instrumentation) to query system memory via Win32_CacheMemory. The method relies on counting cache memory entries, and if the number is less than 2 cache memories, it assumes the system is a virtual machine (VM). However, modern VMs are more sophisticated, and simply relying on counting cache memories may not be effective.

The other difference is, instead of targeting debuggers or sandboxes, VenomRAT attempts to avoid running on server operating systems by querying the Win32_OperatingSystem WMI class and checking the ProductType, which differentiates between desktop and server environments. We summarized class differences in the table below.

Feature AsyncRAT AntiAnalysis Class Venom RAT Anti_Analysis Class
VM Detection ✔ ✔
Sandbox Detection ✔ ✘
Debugger Detection ✔ ✘
Operating System Detection ✔ ✔
Process Discovery ✘ ✔

A Bag of RATs: VenomRAT vs. AsyncRAT
Figure 1: Side by side comparison of Anti-Analysis class of AsycRAT(let) and VenomRAT(right)

Hardware Interaction

VenomRAT has hardware interaction capabilities, allowing it to gather detailed system information through WMI queries with ManagementObjectSearcher objects. These features are encapsulated in the CGRInfo class, which enables the collection of CPU, RAM, GPU, and software data:

  • GetCPUName(): Retrieves the CPU name and the number of cores
  • GetRAM(): Fetches the total installed physical memory (RAM)
  • GetGPU(): Obtains the GPU name and driver version
  • GetInstalledApplications(): Scans the Windows Registry to compile a list of installed applications
  • GetUserProcessList(): Collects information on all running processes with visible windows

The collected data is sent back to the command-and-control (C2) server. This class is absent in both the version of AsyncRAT we analyzed and the open-source version.

DcRAT joined the party with AntiProcess and Camera classes

VenomRAT includes two notable classes absent in AsyncRAT: the AntiProcess and Camera classes.

The AntiProcess class is an anti-monitoring and anti-detection component of VenomRAT. Malware uses the Windows API function CreateToolhelp32Snapshot to get a snapshot of all running processes and search for specific processes. We categorized the processes the malware is looking for below.

System Monitoring Tools that can prevent users from identifying or stopping VenomRAT.

  • Taskmgr.exe
  • ProcessHacker.exe
  • procexp.exe

Security & Antivirus Processes: Terminating them reduces the risk of VenomRAT being detected or removed by security software.

  • MSASCui.exe
  • MsMpEng.exe
  • MpUXSrv.exe
  • MpCmdRun.exe
  • NisSrv.exe

System Configuration Utilities: By targeting these, VenomRAT prevents users from adjusting security settings, inspecting registry changes, or manually removing the malware.

  • ConfigSecurityPolicy.exe
  • MSConfig.exe
  • Regedit.exe
  • UserAccountControlSettings.exe
  • Taskkill.exe

If a matching process is found, it terminates it by its process ID (PID).

The Camera class is designed to detect webcams on a Windows system by querying the available system devices using COM interfaces. It retrieves a list of devices by category, specifically looking for video input devices. The class uses the ICreateDevEnum and IPropertyBag interfaces to enumerate and extract the device names.

However, both these classes, although absent in AasyncRAT, are not exclusive to VenomRAT only. Apparently they are exact copycats of yet another open-source RAT, DcRAT.

AMSI and ETW Bypass

This class was found only in the VenomRAT sample and is designed to bypass key Windows security mechanisms through in-memory patching. It specifically disables two critical Windows security features: AMSI (Antimalware Scan Interface) and ETW (Event Tracing for Windows), which are often used by antivirus software and monitoring tools to detect malware.

Key Functions:

  • AMSI Bypass: The class patches the AmsiScanBuffer function within amsi.dll to prevent AMSI from scanning for malicious content.
  • ETW Bypass: The class patches the EtwEventWrite function in ntdll.dll, which stops ETW from logging events related to the malware’s activity.

The patching process is performed in-memory. The class dynamically checks the system’s architecture (32-bit or 64-bit) and loads the appropriate DLLs (amsi.dll and ntdll.dll) to apply the patches based on the platform. The techniques used by VenomRAT closely mirror those found in the SharpSploit project, an open-source tool often used by penetration testers and red teams to test and bypass security features in a controlled environment. SharpSploit contains classes for bypassing both AMSI and ETW using similar in-memory patching methods, which likely served as inspiration for VenomRAT’s implementation.

This security bypass functionality makes VenomRAT more capable of evading modern security defenses.

Dynamic API resolution

VenomRAT has yet another class which is absent in AsyncRAT. The DInvokeCore class is implemented to dynamically resolve and call Windows API functions at runtime; this method bypasses traditional static imports, making it harder for antivirus and endpoint detection and response (EDR) systems to detect malicious activity.

Instead of statically importing Windows APIs, the class resolves function addresses at runtime (e.g., from ntdll.dll or kernel32.dll) using methods like GetLibraryAddress and GetExportAddress. This approach makes it difficult for static analysis tools to flag malicious behavior.

It uses the NtProtectVirtualMemory method to alter memory protection settings, allowing execution of code in memory regions that are normally non-executable—an effective method for in-memory execution of malicious payloads.

Implementation of DInvokeCore closely mirrors the open-source SharpSploit Generic class from the D/Invoke project by TheWover. The DInvokeCore class from VenomRAT appears to be a simplified version, which lacks some features but has core techniques for dynamic API invocation.

Conclusion

Our analysis was sparked by detection vendors grouping VenomRAT and AsyncRAT under the same label, blurring the lines between the two. While they indeed belong to the QuasarRAT family, they are still different RATs.

AsyncRAT appears to closely match the latest open-source release (v0.5.8). However, the VenomRAT seems to have evolved and added other capabilities, although a lot of them seem to be a copy-paste from another open-source RAT (DcRAT) and the SharpSploit project. Despite this, VenomRAT presents more advanced evasion techniques, making it a more sophisticated threat.

Therefore, it’s important for security vendors to treat them as distinct threats, recognizing that VenomRAT brings more advanced evasion capabilities, even if much of it isn’t truly unique. To help to resolve this confusion, we are sharing an updated VenomRAT YARA rule with the community, helping improve detection and response efforts.

Rapid7 customers

InsightIDR and Managed Detection and Response (MDR) customers have existing detection coverage through Rapid7’s expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. The following rule will alert on a wide range of malicious hashes tied to behavior in this blog:  Suspicious Process – Malicious Hash On Asset

YARA rule

The VenomRAT YARA rule can be found on the Rapid7 Labs GitHub here.

Exploring the (Not So) Secret Code of Black Hunt Ransomware

Post Syndicated from Anna Širokova original https://blog.rapid7.com/2024/02/05/exploring-the-not-so-secret-code-of-blackhunt-ransomware-2/

Exploring the (Not So) Secret Code of Black Hunt Ransomware

It seems like every week, the cybersecurity landscape sees the emergence of yet another ransomware variant, with Black Hunt being one of the latest additions. Initially reported by cybersecurity researchers in 2022, this new threat has quickly made its presence known. In a recent incident, Black Hunt ransomware wreaked havoc by compromising around 300 companies in Paraguay.

Rapid7 Labs consistently monitors emerging threats, and this new ransomware variant caught our attention for several reasons. The behavior and potential impact of this new variant raised concerns among our team, prompting us to conduct a thorough analysis to better understand its capabilities and potential risks.

During our analysis we found notable similarities between Black Hunt ransomware and LockBit, which suggested that it uses leaked code of Lockbit. In addition, it uses some techniques similar to REvil ransomware.

Technical Analysis

In this analysis we examined the Black Hunt sample shared on X (formerly Twitter), by MalwareHunterTeam. In our investigation we found some interesting techniques and features used by this malware. The recent Black Hunt sample is a C++ executable, which widely reuses the leaked Lockbit ransomware code and shares similarities with several other recently spotted ransomware families.The execution of the ransomware on an infected machine starts with a check for a file named Vaccine.txt under directory C:\ProgramData path

Exploring the (Not So) Secret Code of Black Hunt Ransomware
Figure 1 – Check for the existence of Vaccine.txt file

If the file is found, malware terminates its execution. This file detection acts as an anti-exploitation flag for the ransomware. As this is not a well-known anti-sandbox/anti-VM technique, we assume that this file is in use by the threat actor (TA) itself. It is either created by the victim which is instructed to create it after the ransom is paid or dropped by the decryptor, if one is sent to the victim to decrypt the encrypted data. Adding that check is logical if the ransomware operators consider scenarios where their persistence mechanism and the ransomware binary remain on the system even after the ransom is paid and files are decrypted. Moreover, the fact that all files dropped by the ransomware are placed in the C:\ProgramData  directory further supports our assessment that this file is associated with the Black Hunt operation.

Next, the malware adjusts the following privileges to processes Access Token by using the `AdjustTokenPrivileges` API function:

Privilege Setting Description
SeDebugPrivilege Monitor and manipulate other processes.
SeRestorePrivilege Bypass file system security to restore files.
SeBackupPrivilege Read any file, regardless of permissions.
SeTakeOwnershipPrivilege Take control of critical system resources.
SeAuditPrivilege Manipulate security audit logs.
SeSecurityPrivilege Modify security settings of objects.
SeIncreaseBasePriorityPrivilege Gives service privilege to increase scheduling priority.

After modifying process privileges, the malware hides its window by invoking the `ShowWindow` function with the `nCmdShow` parameter set to 0, which corresponds to `SW_HIDE`. This action ensures that the malware’s window is not visible to the user, allowing it to operate stealthily in the background without drawing attention.

Exploring the (Not So) Secret Code of Black Hunt Ransomware
Figure 3 – Malware hiding its present from the user

The execution flow continues as the malware invokes the `GetCommandLineW` function. This function retrieves the command-line string for the current process, including the program name and any arguments passed during startup. This function is commonly used by malware and helps to gather information about command-line flags. Following this, another function call is made to `CMD_ARGS`.

Exploring the (Not So) Secret Code of Black Hunt Ransomware
Figure 4

The function processes a command-line string and checks if any of the following arguments were passed:

Argument Description
-local If passed, the ransomware will skip shared or network drives encryption.
-network If passed, the ransomware will encrypt only the network drives
-biggame If passed, the ransomware will only encrypt the files that contain .4dd, .4dl, .accdb, .accdc, .accde, .accdr, .accdt, .accft, .adb, .ade, .adf, .adp, .arc, .ora, .alf, .ask, .btr, .bdf, .cat, .cdb, .ckp, .cma, .cpd, .dacpac, .dad, .dadiagrams, .daschema, .db, .db-shm, .db-wal, .db3, .dbc, .dbf, .dbs, .dbt ,.dbv, .dbx, .dcb, .dct, .dcx, .ddl ,.dlis, .dp1 ,.dqy, .dsk, .dsn, .dtsx, .dxl, .eco, .ecx, .edb, .epim, .exb, .fcd, .fdb, .fic, .fmp, .fmp12, .fmpsl, .fol, .fp3, .fp4, .fp5, .fp7, .fpt, .frm, .gdb, .grdb, .gwi, .hdb, .his, .ib, .idb, .ihx, .itdb, .itw, .jet, .jtx, .kdb, .kexi, .kexic, .kexis, .lgc, .lwx, .maf, .maq, .mar, .mas, .mav, .mdb, .mdf, .mpd, .mrg, .mud, .mwb, .myd, .ndf, .nnt, .nrmlib, .ns2, .ns3, .ns4, .nsf, .nv, .nv2, .nwdb, .nyf, .odb, .oqy, .orx, .owc, .p96, .p97, .pan, .pdb, .pdm, .pnz, .qry, .qvd, .rbf, .rctd, .rod, .rodx, .rpd, .rsd, .sas7bdat, .sbf, .scx, .sdb, .sdc, .sdf, .sis, .spq, .sql, .sqlite, .sqlite3, .sqlitedb, .te, .temx, .tmd, .tps, .trc, .trm, .udb, .udl, .usr, .v12, .vis, .vpd, .vvv, .wdb, .wmdb, .wrk, .xdb, .xld, .xmlff, .abcddb, .abs, .abx, .accdw, .adn, .db2, .fm5, .hjt, .icg, .icr, .kdb, .lut, .maw, .mdn, .mdt extensions.
-backup If passed, the ransomware will only encrypt the files with .000, .cab, .zip and .rar extensions.
-noencrypt if passed, the malware will skip encryption.
-p If passed, specifies a path to be encrypted
-nologs If passed – If the flag is not set, the ransomware creates a log file named #BlackHunt_Logs.txt under C:\ProgramData directory. Otherwise no log files will be created.
-status If passed, sets the ransomware console windows to ‘SW_SHOW’ and shows the encryption status in the ransomware console window. The status information contains the System ID, running time, the amount of encrypted files and encrypted volume, as well as errors, alive workers and the code location. The status window constantly updated by the ransomware as long as it runs
-update If passed, the ransomware shows a fake Window Update screen
-kill If passed, the ransomware terminates processes from hardcoded process list and stops services from hardcoded service list
-scanner If passed, the ransomware scans for network shares
-cipher If passed, when all the encryption process is completed the ransomware uses Windows tool Cipher.exe on all drives to overwrite the deleted data. Same capability was utilized by Vohuk ransomware.
-restart if set in the end of encryption the following command will be executed to restart the pc ‘shutdown /r /t 15 /f’

The ransomware accepts additional arguments that modify its behavior, including disabling spreading capabilities, adjusting encryption speed, thread count for encryption, skipping mutex creation, and enabling debug mode to collect more information in the log file.

After verifying passed arguments and ensuring the absence of the -nomutex flag, the ransomware proceeds to create a `BLACK_HUNT_MUTEX`. Next, it elevates its process priority to `HIGH_PRIORITY_CLASS` using the `SetPriorityClass` API function.

The ransomware made 200 attempts to load `Fake.dll`, likely as a tactic to slow up/evade the execution in the sandbox. Following this, it employs the `IsDebuggerPresent` API call to detect if debugging is in progress. If a debugger is detected, the ransomware terminates.

Further analysis revealed that Black Hunt maintains a whitelist of 15 countries, as detailed in the table below.

Language Code Language Country
2092 Azeri (Cyrillic) Azerbaijan
1068 Azeri (Latin) Azerbaijan
1067 Armenian Armenia
1059 Belarusian Belarus
1079 Georgian Georgia
1071 Macedonian North Macedonia
1088 Kyrgyz Kyrgyzstan
2073 Moldovan Moldova (Russian language)
1064 Tajik (Cyrillic) Tajikistan
1090 Turkmen Turkmenistan
2115 Uzbek (Cyrillic) Uzbekistan
1091 Uzbek (Latin) Uzbekistan
1058 Ukrainian Ukraine
1065 Persian Iran
1055 Turkish Turkey

The malware uses the `GetSystemDefaultUILanguage` function to identify one of 15 hardcoded languages. If it detects any of these languages, it terminates execution.

Exploring the (Not So) Secret Code of Black Hunt Ransomware
Figure 5 – Hardcoded list of languages

Following language detection, the malware attempts to establish an internet connection by calling the `getaddrinfo` function to resolve the domain ip-api.com.

The ransomware checks if `BlackKeys` mutex exists, and if not, it creates it by using `CreateMutexA` API.

Next,the malware begins a key initialization process. First, it attempts to load a key by using `CryptImportKey` with a buffer containing the key. It looks for the key in files named C:\ProgramData\#BlackHunt_Public.key and C:\ProgramData\#BlackHunt_Private.key, and also verifies the presence of C:\ProgramData\#BlackHunt_ID.txt. If the key loading fails, the malware switches to generating a 128-bit RSA key pair.

After initializing encryption keys, the ransomware creates a HKEY_LOCAL_MACHINE\Software\Classes\.Hunt2 registry key to define settings for files with `.Hunt2` extension.It adds a `DefaultIcon` registry key under `.Hunt2` and assigns a default value to the dropped icon file.

Next, the ransomware creates a new {2C5F9FCC-F266-43F6-838DAE269E11} value under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key and sets it data to C:\ProgramData\#BlackHunt_ReadMe.hta that will make the `.hta` file be executed on reboot.This file is a Black Hunt ransom note. Here we can notice additional proof of reuse of Lockbit ransomware code by BlackHunt operators, the value name is identical to the one LockBit 2.0 used in their attacks.

The Black Hunt ransomware makes several modifications to the Windows registry to disable security measures, alter system functionality, and potentially limit user control over the system. Below are the commands used

Command Action
/c reg add "HKEY_LOCAL_MACHINE\Software\Classes.Hunt2" /f" Adds a registry key .Hunt2 under HKEY_LOCAL_MACHINE\Software\Classes\
/c reg add "HKEY_LOCAL_MACHINE\Software\Classes.Hunt2\DefaultIcon" /ve /t REG_SZ /d
"C:\ProgramData#BlackHunt_Icon.ico" /f");		 Sets the default icon for .Hunt2 files to C:\ProgramData#BlackHunt_Icon.ico
/c reg add "HKEY_LOCAL_MACHINE\Software\Classes\Hunt2" /f"); Adds a registry key Hunt2 under HKEY_LOCAL_MACHINE\Software\Classes\
/c reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run" /v Adds an entry to the Windows startup registry key to run C:\ProgramData#BlackHunt_ReadMe.hta
/c reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run"
/v "{2C5F9FCC-F266-43F6-BFD7-838DAE269E11}"
/t REG_SZ /d "C:\ProgramData#BlackHunt_ReadMe.hta" /f");		 Adds an entry to the Windows startup registry key to run C:\ProgramData#BlackHunt_ReadMe.hta
SHChangeNotify(0x8000000, 0, 0, 0); Notifies the system of changes that might require refreshing icons or interface elements

The list of modified registries can be found in the IOC section or on the Rapid7 Labs GitHub page.

Afterward, the malware checks for various command-line arguments, and its execution flow depends on which arguments are set.

`-p` flag

If set, it proceeds to sets persistence by creating scheduled tasks to execute the malware upon system startup using the command /c SCHTASKS.exe /Create /RU “NT AUTHORITY\SYSTEM” /sc onstart /TN “Windows Critical Update” /TR “%s” /F.

`-safemode` flag

If it is, the malware configures the safe mode setting to ensure its execution after the system boots in safe mode, after which it restarts the machine. For more information on that technique check the Safe Mode section of this article.

If the `-safemode` flag is not set, the malware creates ransom note, primary and secondary contact emails `[email protected]` and `[email protected]`, respectively, a placeholder ID for infected machines, and the Tor address http[:]//sdif9821kjsdvcjlksaf2kjhlksvvnktyoiasuc921f.

`-update`  flag

If set, the malware drops `#BlackHunt_Update.hta` to the C:\ProgramData directory and executes it. The purpose of that flag is to create a fake Windows Update screen while encrypting the victim’s data. After that, the malware empties the recycle bin by calling `SHEmptyRecycleBinW`.

`-kill` flag

If set, the malware enumerates running processes and terminates 130 predefined processes and services. The full list of processes and services can be found in the IOC section or on the Rapid7 Labs GitHub page.

After completing its service termination routine, the malware tries to access the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, known for storing system policies such as User Account Control (UAC) settings. If successful, it modifies two registry values: `EnableLUA` and `EnableLinkedConnections`.

Exploring the (Not So) Secret Code of Black Hunt Ransomware
Figure 6-UAC settings modification

By setting`EnableLUA` to 0, the malware effectively disables this security feature, granting itself elevated privileges without user intervention. Additionally, the malware sets the `EnableLinkedConnections` registry key, allowing any user to see network drives that were mapped for other users. This gives ransomware the ability to gain access to sensitive network resources.The malware invokes the `RefreshPolicyEx` API function to enforce the modifications made.

Next, the malware manipulates shadow storage. For conventional disk types, such as DRIVE_FIXED, it executes commands like /c vssadmin resize shadowstorage /for=C:\ /on=C:\ /maxsize=401MB. For disk types not explicitly specified, such as DRIVE_RAMDISK, it uses /c vssadmin resize shadowstorage /for=C:\ /on=C:\

Afterwards , the malware removes the shadow copies using vssadmin.exe Delete Shadows /all /quiet and disables automatic repair by executing bcdedit /set {default} recoveryenabled No.

Exploring the (Not So) Secret Code of Black Hunt Ransomware
Figure 7- Shadow storage manipulation

Next, the attackers execute a sequence of commands to clean up the system and implement critical modifications.

Command Description
bcdedit /set {default} bootstatuspolicy IgnoreAllFailures Adjusts boot status policy for normal booting despite failures, blocking access to System Image Recovery
fsutil.exe usn deletejournal /disks (D and C) Deletes Volume USN Journal on disks D and C, disrupting file system change tracking
wbadmin.exe delete catalog -quiet Silently removes backup catalogs, erasing backup data
Disables System Restore tasks with sc Halts System Restore functionality, limiting recovery options

If the  `-scanner` flag is set the ransomware will attempt to retrieve the ARP cache table and scan the addresses using the servername as a parameter. This function utilizes `NetShareEnum` to gather information about network shares on a given server.

Finally,  the encryption routine starts. Encrypted files renamed with  `.Hunt2` extension. After the encryption, the ransomware deletes itself, and the ransom note is displayed to the user.

Exploring the (Not So) Secret Code of Black Hunt Ransomware
Figure 8 – Black Hunt ransomware note

Additional functionality

Spreading mechanism

Ransomware tries to enumerate shares on the localhost (127.0.0.1) using  `NetShareEnum`. If shares are found and no error occurs, the malware tries to process  drive paths. It checks each path for specific conditions met and that the path is not a remote path. If these conditions are met, it processes the argument as a local drive path by extracting the drive letter and formatting it as \127.0.0.1{drive_letter}.

The malware attempts to locate a NAS server and paths to files on removable drives. Additionally, it searches for shared folders and attempts to spread by enumerating local shared folders using `NetShareEnum`. If a network share is found, it copies itself to the share using `CopyFileW`. After spreading, it clears setup event logs by executing cmd /c wevtutil.exe.

Safe mode

If the `-safemode` argument is set, the malware executes the encryption process in Safe Mode. To ensure execution after rebooting in Safe Mode, the malware sets up the system as follows:

1) Obtains a user environment variable.

2) Executes the net user username `Black_Hunt_2.0` command to set a new user password.

3) Adds a new `AutoAdminLog` value under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon and sets it to 1, enabling auto login in Windows.

4) Creates a `DefaultUserName` value under the same registry key and sets it.

5) Creates a `DefaultPassword` registry value and sets it to the changed password.

6) Executes the /c bootcfg /raw /a /safeboot:network /id 1 and /c bcdedit /set {current} safeboot network commands to force the computer to boot into Safe Mode with Networking.

7) Creates a new`BackToNormal` value under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce and sets it to bcdedit /deletevalue {current} safeboot” /f.

8) Sets an additional value under the `RunOnce` key named `BlackHunt` and sets it to the current malware running path.

9) Finally, restarts the system by executing shutdown /r /t 7 /f

Rapid7 Customers

For Rapid7 MDR and InsightIDR customers, the following Attacker Behavior Analytics (ABA) rules are currently deployed and alerting on the activity described in this blog:

  • Suspicious Process – Delete File Shadow Copies With PowerShell
  • Attacker Technique – Rundll32 Running DLL in Root of ProgramData
  • Suspicious Process – Regsvr32.exe Registering DLL in ProgramData
  • Persistence – Run Key Added by Reg.exe
  • Suspicious Registry Event – Unusual Registry Run Keys
  • Attacker Technique – Disabling UAC Remote Restrictions
  • Suspicious Registry Edit – Shell\Open\Command Edited, Possible UAC Bypass
  • Attacker Technique – Reg.exe disabling the User Access Control (UAC) remote restriction
  • Suspicious Process – Possible UAC Bypass via MMC.exe
  • Attacker Technique – Svchost.exe Spawns cmd.exe Executing Scheduled Task
  • Persistence – SchTasks Creating A Task Pointed At Users Temp Or Roaming Directory
  • Ransomware – LockBit Command-Line Arguments
  • Suspicious Process – VSSADMIN List and Create Shadow Commands (MVD detection)
  • Suspicious Registry Event – BCDEDIT Safeboot Minimal
  • UAC Bypass – Notepad Launching CMD or PowerShell
  • Defense Evasion – Disabling Multiple Security or Backup Products (MVD detection)
  • Suspicious Process – Diskshadow (Windows Server) Delete Shadow Copies

MITRE ATT&CK Techniques

|

Tactic Technique **Details
Execution Native API (T1106) The ransomware may execute its malicious activities by interacting with system APIs.
Persistence Scheduled Task/Job: Scheduled Task (T1053.005 ) Black Hunt sets persistence by creating scheduled tasks to execute the malware upon system startup using the command
Persistence Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder (T1547.001) Modifies the Windows Registry to establish persistence, ensuring it runs automatically upon system startup.
Privilege Escalation Abuse Elevation Control Mechanism: Bypass User Account Control (T1548.002 ) Black Hunt grants itself elevated privileges without user intervention by modifying registry values: EnableLUA and EnableLinkedConnections.
Defense Evasion, Privilege Escalation Access Token Manipulation (T1134) Black Hunt manipulate access tokens, granting itself privileges to perform various actions on the system
Defense Evasion Modify Registry (T1112) Modifies registry keys to disable security features, alter system configurations, and establish persistence.
Defense Evasion Impair Defenses: Disable or Modify Tools (T1562.001) Black Hunt disables security tools to avoid possible detection of their malware/tools and activities
Defense Evasion File Deletion ( T1070.004 ) Black Hunt empties the Windows Recycle Bin to permanently delete files and prevent recovery attempts.
Defense Evasion Indicator Removal on Host: Clear Windows Event Logs (T1070.001) The ransomware clears Windows Event Logs to erase evidence.
Defense Evasion Impair Defenses: Safe Mode Boot (T1562.009) Black Hunt disable endpoint defenses
Defense Evasion Hide Artifacts: Hidden Window (T1564.003) Black Hunt uses a hidden window to conceal malicious activity from the plain sight of users.
Discovery Network Service Discovery (T1046) Black Hunt lists services running on the local network
Discovery System Location Discovery: System Language Discovery (T1614.001) Black Hunt gather information about the system language of a host in order to infer the geographical location of that host
Discovery Network Share Discovery (T1135) Black Hunt enumerates shared network drives and folders to access other systems
Discovery File and Directory Discovery (T1083) Black Hunt enumerates files and directories to identify whether certain objects should be encrypted
Discovery Process Discovery (T1057) Black Hunt performs process discovery/enumeration to terminate processes that could interfere with the encryption process.
Impact Inhibit System Recovery (T1490) Deletes backups, volume shadow copies, and disables automatic repair and recovery features.
Impact Data Encrypted for Impact (T1486) Black Hunt is capable for encrypting victim’s files
Impact Service Stop (T1489) Stops certain services, such as those related to backup, security software, and others

IOCs

Attribute Value Description
mutex BLACK_HUNT Mutex used by the ransomware
mutex BaseNamedObjects\BlackKeys Mutex used by the ransomware
sha256 C25F7B30D224D999CE337A13224C1CDE9FFB3F415D7113548DE9914A1BB3F123 #BlackHunt_Update.hta file
primary email Teikobest@gmail dot com Primary contact email for ransom
secondary email Loxoclash@gmail dot com Secondary contact email for ransom
Tor address http[://]sdif9821kjsdvcjlksaf2kjhlksvvnktyoiasuc921f
sha256 74df3452a6b9dcdba658af7a9cf5afb09cce51534f9bc63079827bf73075243b Black Hunt ransomware
sha256 35619594724871138875db462eda6cf24f2a462e1f812ff27d79131576cd73ab Black Hunt ransomware
sha256 32877793a1e0d72235e9e785e1f55592c32c9f08b73729815b8103b09a54065f Black Hunt ransomware
sha256 7eea62dcae4e2e5091dd89959529ae047071415a890dda507db4c53b6dcab28b Black Hunt ransomware
sha256 13a5c3b72f81554e04b56d960d3a503a4b08ec77abb43756932a68b98dac1479 Black Hunt ransomware

Registry Modified by Black Hunt Ransomware

Registry Modification Description
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run {2C5F9FCC-F266-43F6-BFD7-838DAE269E11} REG_SZ C:\ProgramData#BlackHunt_ReadMe.hta Adds a startup entry to run a file at system startup
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows Defender DisableAntiSpyware REG_DWORD 1 Disables Windows Defender anti-spyware protection
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows Defender\Real-Time Protection DisableRealtimeMonitoring REG_DWORD 1 Disables Windows Defender real-time monitoring
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows Defender\Spynet SubmitSamplesConsent REG_DWORD 2 Sets the consent level for submitting samples to Microsoft
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows Defender\Threats Threats_ThreatSeverityDefaultAction REG_DWORD 1 Sets default actions for threats detected by Windows Defender
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows Defender\Threats\ThreatSeverityDefaultAction Low, Medium, High, Severe REG_DWORD 6 Sets default actions for threats of different severities
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows Defender\UX Configuration Notification_Suppress REG_DWORD 1 Suppresses Windows Defender notifications
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer NoClose, StartMenuLogOff REG_DWORD 1 Disables the ability to close the Start Menu and log off
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System DisableChangePassword, DisableLockWorkstation, NoLogoff, DisableTaskMgr REG_DWORD 1 Disables various system functionalities such as changing password, locking workstation, logging off, and task manager
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\SystemRestore DisableConfig, DisableSR REG_DWORD 1 Disables System Restore configuration and functionality
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WinRE DisableSetup REG_DWORD 1 Disables Windows Recovery Environment setup
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Backup\Client DisableBackupLauncher, DisableRestoreUI, DisableSystemBackupUI, DisableBackupUI REG_DWORD 1 Disables various backup client functionalities
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer NoRun REG_DWORD 1 Disables the ability to run programs

References

https://twitter.com/RakeshKrish12/status/1597839380558716928

https://twitter.com/malwrhunterteam/status/1744499152011104549

https://blog.sonicwall.com/en-us/2021/09/lockbit-2-0-the-ransomware-behind-the-accenture-breach/

https://blog.sonicwall.com/en-us/2023/02/vohuk-ransomware-uses-cipher-exe-making-files-recovery-impossible/

Rapid7 Labs GitHub

https://github.com/rapid7/Rapid7-Labs/blob/main/IOCs/BlackHunt.txt