STX RAT: A new RAT in 2026 with Infostealer Capabilities

What did we find?

In late February 2026, eSentire's Threat Response Unit (TRU) observed an attempted delivery of a previously undocumented malware family within a customer environment in the Finance industry. TRU is tracking this threat as STX RAT, named for its consistent use of the Start of Text (STX) magic byte "\x02" prefixed to C2 messages.

TRU observed attempted delivery of the malware via a browser-downloaded VBScript file; by early March 2026, Malwarebytes reported a separate initial access vector in their blog, "A fake FileZilla site hosts a malicious download", where the malware was distributed through trojanized FileZilla installers.

Key takeaways

• STX RAT is a newly identified remote access trojan (RAT) tracked by eSentire's TRU, observed in late February 2026 targeting a financial-services customer. Initial access vectors primarily are opportunistic (e.g. trojanized FileZilla installers).
• The malware uses a custom multi-stage unpacking chain (notable init and run exports) that decrypts and decompresses embedded payload data using XXTEA and Zlib.
• Credential and data theft is gated by C2 interaction, with the stealer functionality only activating after the malware successfully connects to its C2 server and receives an explicit instruction, reducing behavioral evidence in offline sandboxes or after infrastructure takedown.
• Communicates over TCP using a proprietary, length-prefixed protocol, and supports both clearweb and Tor as fallback, including a custom Tor client implementation to reach onion infrastructure.
• The C2 channel is protected with a well-thought-out cryptographic design:
  • X25519 ECDH derives a per-session shared secret.
  • Ed25519 is used to validate the C2's X25519 public key.
  • Session traffic is encrypted and integrity-protected with ChaCha20-Poly1305.
• To hinder reverse engineering, STX RAT employs multiple string-obfuscation layers, including rolling XOR with variable start keys and AES-128-CTR encrypted strings that are decrypted on demand and deleted from memory immediately after usage.
• A prominent feature of the RAT is its HVNC / hidden remote desktop functionality, enabling threat actor control of the victim machine via a hidden desktop.
• Broad infostealer capabilities, targeting browser credentials/cookies, crypto-wallets, and FTP client credentials, with * indicators suggesting potential support for Application-Bound Encryption (ABE) bypass. * TRU has not observed successful ABE key extraction, suggesting this feature may not yet be functional.
• Resolves Windows APIs and module dependencies using salted SHA-1 hashes, avoiding plaintext imports and complicating static reverse engineering.
• Exposes a broad command set for remote control, follow-on payload execution, and post-exploitation actions (e.g. in-memory execution of EXE/DLL/PowerShell/shellcode, reverse proxy/tunneling, desktop interaction).
• Implements persistence via multiple mechanisms and enforces single-instance execution via mutex.
• Implements anti-analysis and anti-virtual machine mechanisms, scanning for a broad set of virtualization artifacts and terminating on detection, with randomized sleep delays to hinder analysis.

Initial Access

Though we were unable to recover the original VBScript, we found a nearly identical sample in VirusTotal with hash: 799b29f409578c79639c37ea4c676475fd88f55251af28eb49f8199b904a51f3. The VBScript concatenates JScript contents, writes them to a JScript file on disk, and executes the JScript file via WScript with elevated privileges.

Note, the name of the JScript file varies between campaigns. In this incident, we observed the following command line:

"C:\Windows\System32\wscript.exe" "C:\Users\<Username>\AppData\Local\Temp\business-structure.xlsx.js" /elevated

The JScript file's contents are shown in the figure below, whose purpose is to download a TAR file, extract it to disk, and execute the next stage PowerShell loader.

The TAR file contains two files:

• 1.bin (STX RAT payload)
• 2.txt (PowerShell loader)

The PowerShell script acts as an in-memory loader: it takes the 1.bin payload string, reverses it and Base64-decodes it into bytes, allocates RWE memory using VirtualAlloc, copies both the payload and a parameter blob into those buffers via WriteProcessMemory, then computes the entrypoint address as base + offset and transfers execution to it by converting that address into a callable delegate with Marshal.GetDelegateForFunctionPointer and invoking it.

STX RAT Analysis

Packer Characteristics

The packer used by the malware is characterized by two exports named "init" and "run", and the use of XXTEA decryption / Zlib decompression on a byte array stored in the .DATA section. Following "tail jumps" is an effective technique in unpacking the core STX RAT payload.

Strings

As a means of slowing the malware analysis process, strings stored throughout the binary are rolling XOR-encoded and AES-128-CTR-encrypted.

The first set of strings is stored throughout the malware and referenced by memory address. In multiple basic blocks, the plaintext is recovered using a rolling XOR-decryption loop in which the key index is advanced per byte and wrapped using a predefined modulus (i.e., when the index reaches the limit, it returns to the starting position and repeats). 

For example, in many blocks the XOR key begins at 0x39 and increments for each ciphertext byte (so the next key byte would be 0x3A). When the key reaches a predefined upper bound (e.g., 0x6C), it wraps back to the initial value (e.g., 0x39) and the cycle repeats. The starting key differs between basic blocks. The figure below shows an example block that decrypts the C2 server address 95.216.51.236 (AS24940 - Hetzner Online GmbH).

The second set of strings are stored in a table and are decrypted on an as-needed basis via an offset into the table. The pseudo-code below displays the routine responsible for decrypting a string via offset. This routine eventually calls the CryptDecrypt API to decrypt a string via AES-128-CTR.

The table itself contains records matching the structure shown below.

struct AesEncryptedRecord {
    BYTE aesKey[16];                    // 128-bit key (16 bytes)
    BYTE nonce[5];                      // 5-byte Nonce
    DWORD dwCiphertextLength;           // Length of ciphertext
    BYTE ciphertext[dwCiphertextLength]; // Ciphertext
};

The annotated figure below further illustrates an example record from this table and highlights its layout: the AES key, nonce, ciphertext length, and finally the ciphertext itself.

API Hashing

The malware uses two lookup tables: one for resolving exported APIs and another for modules. The exports table contains records in the form [module_index, export_sha1, export_salt]. The module_index points to a record in the second table, which stores per-module SHA‑1/salt pairs.

To resolve an API, the malware enumerates modules already loaded in the process via the PEB loader data. It lowercases each DLL name and identifies the target module by computing:

• SHA‑1(lowercase_module_name ∥ module_salt)

If the module is not currently loaded, it searches the system directory for candidate DLLs, lowercases each filename, and manually loads any DLL whose hash matches the expected value.

Once the correct module is loaded, it enumerates that module's exported function names. For each export, it computes:

• SHA‑1(export_name ∥ export_salt)

It then compares the result to the expected export_sha1 to locate the desired API. More details on this process are provided below.

1. Call a lookup function (renamed here as mw_resolve_api, see Figure 10) and pass a single argument - an index into a table of "ExportSha1SaltBlock" structures. Through pointer math, the index enables retrieving the "wanted" exports associated SHA-1/Salt structure in the table. Each structure is 48 bytes long and follows the format below.

   struct ExportSha1SaltBlock {
       DWORD dwModuleIndex; // Used in calculating the virtual address of the export's associated module sha1/salt pair
       BYTE sha1Hash[20];   // 20 bytes representing the SHA-1 hash to check against the combined export name and salt
       BYTE salt[10];       // 10 bytes of salt to combine with the export name
       BYTE reserved1[14];
   };

2. The first member dwModuleIndex from the prior structure is then used in another lookup to determine the export's associated module sha1/salt structure. The function (renamed here as mw_get_module_base_by_hash_and_salt in Figure 8) also takes a single argument - an index into an array of structures. Each structure is also 48 bytes long, but follows a different format:

   struct ModuleSha1SaltBlock {
       BYTE sha1Hash[20]; // 20 bytes representing the SHA-1 hash to check against the combined module name (lowercase) and salt
       BYTE salt[10];     // 10 bytes representing the salt to combine with the module name
       BYTE reserved2[18];
   };

3. Next, the routine resolves the base address of the module associated with the export by querying the process loader data (PEB_LDR_DATA). It enumerates the InMemoryOrderModuleList and, for each entry, retrieves the module's base name as a wide-character string. It then iterates over the string, converting it to lowercase ASCII. The normalized name, along with the SHA-1/salt structure, is passed to another subroutine (shown here as mw_sha1_verify_with_salt), which returns a boolean indicating whether the string matches the salted hash, e.g. SHA-1(dll_name + salt). If a match is found, the routine breaks out of the loop and returns the module's base address.

   

   Here is a look at the raw data, which has been annotated with the formula for indexing into the table with the SHA-1 and salt for psapi.dll as an example.

   

4. The resolved module base address is then used to parse the module's export directory. The routine iterates the module's exported function names and hashes each name as-is (no lowercase conversion like for module names), comparing the result to the SHA-1 hash from step 1. When a match is found, it resolves the corresponding function address (via export name/ordinal mapping) and returns it.

   

   Here is a look at the raw data, which has been annotated with the formula for indexing into the table with the SHA-1 and salt.

   

The table below lists modules and associated SHA1/SALT:

The python snippet shown below can be used to emulate the aforementioned hashing behavior:

import hashlib
module_name = b'shlwapi.dll'
salt = bytes.fromhex('50079b1f09075cfa8f48')
result = hashlib.sha1(module_name + salt).hexdigest()
print(result)
# 2a9abfad84057d0d71e7bc4ecb23d29013c2e11e

Anti-VM

The tables below describe various Anti-VM detection artifacts, (i.e. files, registry keys/values, services) checked by the malware. If an artifact is found, the malware "jitter exits" (sleeps with a randomized delay and exits).

Anti-Analysis

After checking for virtual machine artifacts, anti-analysis checks are performed. Notably, the malware assumes it only runs in the context of PowerShell/MSBuild, otherwise it jitter exits. This is an effective technique to hinder malware analysis via debugger as malware is often dumped to disk in the analysis process and executed via rundll32 or a custom loader.

• Checks the PEB BeingDebugged flag to determine if a debugger is present
• Calls GetModuleFileNameW to check its own process name, ensuring it contains at least one of the substrings: "powershell", "msbuild".

Hidden Window

The malware then hides its own window by calling EnumWindows to enumerate top-level windows, and passes a callback that retrieves each window's class name via GetClassNameA and compares the window's class name against the string, "CASCADIA_HOSTING_WINDOW_CLASS" (Windows Terminal class name). Upon match, it modifies the window's extended style to include WS_EX_TOOLWINDOW (0x80), causing the window to be hidden from Alt+Tab and the Taskbar.

AMSI Ghosting

Immediately after the malware hides its window, if configured to do so, it uses a known AMSI (Anti-Malware Scan Interface) -bypass technique called AMSI Ghosting, where it patches the Windows API rpcrt4!NdrClientCall3, effectively disabling a core RPC layer that AMSI depends on and preventing security solutions from being able to act on telemetry produced by AMSI.

Antivirus Identification

The table below describes the processes and drivers the malware searches for in an effort to identify security software present on the machine. Each identified product is appended to a list that is sent in the introduction message to the C2.

C2 Protocol

The malware communicates with its C2 server over TCP sockets via Winsock and protects C2 traffic using ECDH (Elliptic Curve Diffie–Hellman) key exchange. The figure below illustrates the key exchange process between the victim machine (e.g. Alice) and the C2 (e.g. Bob).

During the handshake, the C2 sends a ServerHello containing its X25519 public key and an Ed25519 signature of that key. The client verifies the signature using a hard-coded Ed25519PublicKey (stored as a rolling XOR–encoded Base64 string: 4DwvIfxy4thDpGXKYjew8MTI1jYwFEIs2oHuW35BtVM=), then completes the ECDH exchange. If the signature doesn't match, the malware assumes the C2 is not authentic and sends empty packets to the C2 in a loop.

The victim's X25519 private key is generated using the Windows API CryptGenRandom. By hooking this API and breaking just before it executes, you can detect the key-generation call by checking rdx (dwLen) for 0x20 (32 bytes), then save the output buffer pointer stored in r8 (pbBuffer), then step over the call and dump 32 bytes from that address.

Recovering this private key lets a researcher derive the shared secret and decrypt traffic exchanged between the victim and the C2. The routine that generates the victim's private key bytes can be seen in the figure below.

Another effective technique in dumping the private key involves hooking the X25519 clamping routine and dumping the private key bytes at rcx (first argument):

Simulating C2 communications requires patching the Ed25519 base64 string in the malware with a new Ed25519 public key and signing the returned X25519 key and returning that signature to the implant. We used the following code to convert our Ed25519 public key into hex bytes and patched the threat actor's Ed25519 public key with our own.

patch = b'dckcTs0XHVxirXbvz7g45gZTZ8eTBJ6hkXyHUqC9tYw=\x00'
patch_bytes = bytearray()
start = 0x34
for i in patch: # Rolling XOR over base64-encoded Ed25519 key
    patch_bytes.append(i ^ start)
    start += 1
print(patch_bytes.hex())
#50565d546c4a0a63746b4656321920353e7221737d2e101f16752b1b121b643b3f0d2f1f0d2819622804296260

The key exchange between the C2 and victim produces a shared secret, which the malware feeds into HKDF-SHA256 as the input keying material. It derives a 32‑byte key with no salt and an empty info/context field. That key is then used with ChaCha20‑Poly1305 to encrypt victim data and decrypt C2 data, with Poly1305 ensuring integrity via tag verification. Encrypted messages follow the format [chacha20_nonce₁₂ ∣ ciphertext ∣ poly1305_tag₁₆].

This communication protocol provides the threat actors with several operational benefits:

• Establish a per-session encryption key: Use X25519 ECDH to derive a unique, but shared secret.
• Authenticate the C2 during the handshake: Verify the server's X25519 key with an Ed25519 signature (using an embedded Ed25519 public key), preventing third parties from spoofing the C2; only the victim (with its ephemeral private key) and the attacker's C2 (with its private key) can derive the session key and decrypt the traffic.
• Protect C2 traffic confidentiality: Encrypt client↔︎C2 messages with ChaCha20-Poly1305 so contents aren't readable on the wire.
• Ensure message integrity and authenticity: Reject modified or forged packets via Poly1305 tag verification.
• Standardized framing: Uses a consistent [chacha20_nonce₁₂ ∣ ciphertext ∣ poly1305_tag₁₆] layout to simplify sending/receiving data.

Framing

The malware implements its own message framing on top of TCP, where each frame/message is encoded as:

DWORD length
BYTE  payload[length]

Note: all traffic in both directions (victim ↔︎ C2) uses the same length-prefixed framing. Each side reads exactly 4 bytes to obtain the payload length, then continues reading from the TCP stream until length bytes of payload have been received.

Handshake / key exchange

1) C2 → Victim: ServerHello

The server sends two length‑prefixed values. The first is its X25519 public key, which the client (victim machine) uses to perform key exchange and compute the shared secret. The second is an Ed25519 signature over that X25519 key, which the client verifies using an embedded Ed25519PublicKey (decoded at run-time via pre-described rolling XOR block): 4DwvIfxy4thDpGXKYjew8MTI1jYwFEIs2oHuW35BtVM=.

DWORD len_pubkey                              // 0x20 (32)
BYTE  server_pubkey[len_pubkey]
DWORD len_ed25519_signature                   // 0x40 (64)
BYTE  ed25519_signature[len_ed25519_signature]

server_pubkey: the C2's 32‑byte X25519 public key used for key exchange

ed25519_signature: a 64‑byte Ed25519 signature used to verify the server_pubkey

2) Victim → C2: ClientHello

The client generates an ephemeral keypair and returns its public key:

DWORD len_victim_pubkey          // 0x20 (32)
BYTE  client_pubkey[len_victim_pubkey]

Encrypted Data Exchange and Message Format

The client computes a shared secret and derives the ChaCha20 key, generates a nonce, then encrypts and sends the message to the C2. The nonce is prepended to the message.

Key Agreement

Describes the process of generating the ChaCha20 key via pseudocode.

shared_secret = ECDH(client_privkey, server_pubkey)
key_material  = HKDF(shared_secret)

Encrypted Message

The data structure of encrypted messages is described in the pseudo-structure below.

BYTE chacha_nonce[12]
BYTE ciphertext[len_message - 12 - 16]
BYTE poly1305_tag[16]

Message Decryption Process

Describes the process of decrypting an Encrypted Message sent to and received from, the C2.

• Encrypted Message -> Extract first 12 bytes of message for use as ChaCha20 Nonce
• Compute shared secret for X25519 private key and C2 X25519 public key
• Derive key via HKDF-256 of shared secret
• Decrypt message via ChaCha20 with the key and nonce
• Verify mac tag via Poly1305 (not present in all message types from the C2)

Decrypted Message Format Type A

The data structure of decrypted messages varies, however it generally follows the format shown below. The "data" key stores different data depending on the "type" key. The message shown below is the first message sent to the C2 by the malware and is essentially an introductory message to notify the operators of a new bot having joined the botnet.

If the version value sent in this JSON is considered out-of-date by the C2, the C2 sends the update command, otherwise it sends the get_creds command.

\x02 // Magic byte 
{ 
  "type": "intro", 
  "channel": 0, 
  "data": { 
    "user_id": "<SID-derived-hash>", 
    "machine_id": "<SID-derived-hash>", 
    "hostname": "DESKTOP-1UG9QX", // Victim hostname 
    "username": "john.smith", // Victim username 
    "os": "Windows 11 Pro", 
    "version": "2025.11.003", // Malware build version 
    "arch": "x64", // OS architecture 
    "is_admin": 1, // Is admin 
    "pid": 7953, // Malware process's PID 
    "process_path": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe", 
    "server": "95.216.51.236", // C2 server 
    "utm_group": "" // (optional) Victim clipboard match regex: # Tag: ([^\s]*)\s 
    "utm_source": "", // (optional) Victim clipboard match regex: # Hostname: ([^\s]*)\s 
    "ram": 8191, // Installed RAM 
    "av": [] // AntiVirus names
  }
}

The snippet below shows the decrypted message JSON the C2 sends the malware in the event it considers the introductory JSON acceptable.

\x02 // Magic byte
{
  "type": "get_creds"
}

After receiving the get_creds command, and prior to sending harvested credentials, the malware creates a screenshot of the victim desktop via BitBlt/GDI functions, and transmits it to the C2 as a base64 encoded JPG file.

Decrypted Message Format Type B

The figure below displays the format of the payload returned when the implant is considered out-of-date by the C2 and the C2 returns the update command. This payload format is similar for the run command. Rather than JSON format, a custom binary format is returned by the C2. The header of the file is simple and follows a DWORD length pertaining to field names and the field names themselves. The remaining data includes a stub (beginning with FC 48 83...) and the update payload itself.

The malware parses the aforementioned structure, allocates PAGE_EXECUTE_READWRITE (RWX) memory via VirtualAlloc, writes the payload to it, and executes the stub, which in turn calculates the offset of the OEP in the payload and calls it. The update payload itself is packed by the same packer we previously mentioned, e.g. init/run exports and follows the same unpacking process. The use of a stub to calculate the OEP is a clever trick used by the malware to prevent analysis of payloads in sandboxes. The figure below displays the stub's disassembly.

Campaign Tracking and Callback URL

The introduction JSON previously described contains two optional keys, utm_group and utm_source. These keys are set after the malware gets the victim's clipboard via OpenClipboard/GetClipboardData and parses it via the regex patterns shown in the table below.

Notably, the cid value stores an AES-128-CTR encrypted callback domain for additional campaign tracking purposes. It is decrypted using a hard-coded key, "a91b5f85e4572d3030fc9f4e18fa7896" and nonce, "37927fee241db9697f94c0f3ca488946". After it is decrypted, it is checked to ensure it begins with the magic byte "\x02" to ensure authenticity of the decrypted callback domain.

The format of the callback URL is as follows:

https://<decrypted_domain>/api/v1?action=signal&ray_id=<ray_id>

The figure below displays pseudo-code of the start of the routine where APIs are resolved, the first regex pattern decoded via rolling XOR, and regex match against the victim's clipboard data.

C2 Commands

The table below describes commands identified in our analysis (non-exhaustive). The update and get_creds commands are listed first, as they are the primary commands delivered automatically when the malware checks into the C2 backend. The remainder of commands are sent by threat actor(s) via hands-on-keyboard, most likely through a web panel.

Loader Functionality

The malware supports various payload types delivered by the C2. Payloads are handled through numerous commands, e.g. update, run. Payload types supported by the malware are described below. The table below describes the id to string mapping of payload types and are internal identifiers used by the malware.

For the ps1 payload type specifically, the malware creates a pipe by calling CreatePipe and assigns it to a new PowerShell process's redirected STDIN handle. It then calls CreateProcessW to launch the process with its standard input bound to the pipe and calls WriteFile to write the C2-delivered PowerShell payload into the child process's STDIN. PowerShell reads the data from STDIN and executes it via Invoke-Expression, resulting in fileless, minimal command-line for executing PowerShell in memory. The minimal command line used in this process is shown in the code snippet below.

powershell.exe -Command "[Console]::In.ReadToEnd() | Invoke-Expression"

Credential Theft

The list below described credentials targeted by the malware (non-exhaustive):

• Firefox/SeaMonkey browser cookies and passwords.
• Chromium-based browser cookies/passwords:
  • Google Chrome, Microsoft Edge Brave, Vilvadi, Epic Privacy Browser
• Windows Vault credentials via Windows APIs:
  • VaultEnumerateVaults, VaultOpenVault, VaultEnumerateItems, VaultGetItem, VaultFree, VaultCloseVault
• FTP clients are discovered by enumeration/regex matching subfolders under %APPDATA%, %PROGRAMDATA%, and %LOCALAPPDATA%, and via registry key. The table below describes the targeted application and associated malware behavior.

• Desktop-based crypto-wallets:
  • Litecoin-Qt
  • Zcash
  • Electrum
  • Bitcoin-Qt
  • bytecoin

HVNC Functionality

This section covers two commands (key_press and mouse_input) that enable HVNC keyboard/mouse injection into hidden desktops. When the RAT receives the key_press command, the routine shown below is responsible for converting the C2-supplied string into keyboard input via the SendInput API, effectively allowing threat actors to send keyboard input in hidden desktop windows.

The next figure displays the handler for the mouse_input command, which allows threat actors to move the mouse cursor in hidden desktops using C2 supplied coordinates and the SendInput API.

Persistence

The malware uses several different techniques to persist on the infected host, some of which are described below.

• HKCU Run entry launches a PowerShell script (autorun.ps1) that decrypts the payload from %LOCALAPPDATA%\Microsoft\Windows\Caches\cversions.2.db, allocates RWE memory, and executes the decrypted payload in memory.

• HKCU Run entry launches MSBuild.exe (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe) with a project file (C:\Users\User\AppData\Local\Microsoft\MSBuild\c_3791.proj) containing C# code that allocates RWE memory, decrypts the STX RAT payload, writes it into the buffer, and executes it in memory.

• COM object hijacking using a scriptlet: the registry key's (Default) value is set to script:C:\path\to\ActiveX.sct, forcing Windows to resolve the COM reference to the malicious scriptlet. When the COM object is instantiated, the Scriptlet engine loads ActiveX.sct, whose embedded JScript then launches autorun.ps1.
  • HKEY_CURRENT_USER\Software\Classes\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}\2\1.1\0\win64

eSentire Utilities

eSentire has created a python script for IDA Pro available here that decrypts rolling-XOR and AES-128-CTR strings in the unpacked payload and sets comments. The script will also resolve APIs by parsing the Module/Export SHA-1/Salt tables and match them against exports in the JSON file exports_map.json (or the System directory).

Yara Rules

rule STXRat 
{
    meta:
        author = "YungBinary"
        description = "Detection for unpacked STX RAT in memory"
    strings: 
        
        // Lowercasing
        $s1 = {
            8D 51 BF
            83 FA 19
            8D 41 20
            0F 47 C1
            C2 
        }
        // AMSI ghosting
        $s2 = {
            48 8D 05 ?? ?? ?? ??
            66 C7 45 ?? 48 B8 [0-6]
            48 89 45 ??
            48 8D 55 ??
            66 C7 45 ?? FF E0
        }
        // Debugger check
        $s3 = {
            65 48 8B 04 25 60 00 00 00
            80 78 02 01
        }
        // Crypto string
        $s4 = "Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)" ascii
        
        // AES key/size/algo handling
        $s5 = {
            B9 10 66 00 00 [0-3]
            0F 44 C1
            B9 0F 66 00 00
            41 81 ?? C0 00 00 00
            0F 44 C1
            B9 0E 66 00 00
        }
        // module name copying
        $s6 = {
            48 83 FB 5A
            73 ??
            88 84 1C ?? ?? ?? ??
            48 FF C3
            48 FF C1
            8A 01
            84 C0
            75
        }
        // Sha1 initialization constants
        $s7 = {
            83 61 18 00
            83 61 14 00
            C7 01 01 23 45 67
            C7 41 04 89 AB CD EF
            C7 41 08 FE DC BA 98
            C7 41 0C 76 54 32 10
            C7 41 10 F0 E1 D2 C3
            C3
        }
        // X25519 clamping
        $s8 = {
            80 61 1F 3F
            80 49 1F 40
            80 21 F8
        }
    condition: 
        uint16(0) == 0x5a4d and (4 of ($s*))
}

import "pe"
rule STXRatLoader
{
    meta:
        author = "YungBinary"
        description = "Detection for STX RAT loader"
    strings: 
        
        // Kernel32 ROR-14
        $ror1 = { B9 4E 15 F5 1F E8 }
        // VirtualProtect ROR-14
        $ror2 = {
            BA 35 EC 33 57
            48 8B C8
            48 8B D8
            E8
        }
        // CreateThread ROR-14
        $ror3 = {
            BA 36 91 AC 32
        }
        // Ntdll ROR-14
        $ror4 = {
            BA 7E 91 90 5A
            48 8B C8
            E8
        }
        // XXTEA constant
        $s1 = {
            69 D0 47 86 C8 61
        }
        // Zlib
        $s2 = {
            B8 85 10 42 08
            41 F7 E2
        }
        // ROR
        $s3 = {
            41 C1 C8 0E
            0F BE C0
            44 03 C0
        }
    condition: 
        uint16(0) == 0x5a4d and ((pe.exports("init") and pe.exports("run")) and 1 of ($ror*) and 1 of ($s*))
}

What did we do?

• Our team of 24/7 SOC Cyber Analysts proactively isolated the affected host to contain the infection on the customer's behalf.
• We communicated what happened with the customer and helped them with remediation efforts.
• TRU is closely monitoring STX RAT campaigns and developing up-to-date detection content for eSentire MDR for Endpoint, eSentire MDR for Log, and eSentire MDR for Network.

What can you learn from this TRU Positive?

• STX RAT appears to be an undocumented, low-visibility RAT delivered via opportunistic attacks masquerading as legitimate software installers like FileZilla and Google Drive.
• C2 implementation is mature: custom TCP protocol, key exchange via X25519 and key verification via an embedded Ed25519 public key, and message confidentiality/integrity via ChaCha20-Poly1305.
• Defensive evasion and operator functionality are extensive, including broad anti-VM/anti-analysis checks, AV discovery, HVNC/hidden remote desktop, delayed credential theft gated by C2 commands, multiple persistence options, and flexible in-memory execution for follow-on payloads.

Recommendations from the Threat Response Unit (TRU)

• Redirect the default Open With action of suspicious file extensions via GPO "User Configuration > Preferences > Control Panel > Settings" to a benign program like notepad.exe:
  • Right-click on Folder Options and navigate to New > Open With, type in the file extension to redirect and specify C:\Windows\notepad.exe.
  • Note, we recommend redirecting the following file extensions: js, jse, vbs, vbe, wsf, hta, and wsh.
• Disable wscript.exe via AppLocker GPO or Windows Defender Application Control (WDAC):
  • C:\Windows\System32\WScript.exe
  • C:\Windows\Syswow64\WScript.exe
  • *:\Windows\System32\WScript.exe (* represents wildcard to include other drive letter rather than C drive)
  • *:\Windows\SysWOW64\WScript.exe (* represents wildcard to include other drive letter rather than C drive)
• Implement a Phishing and Security Awareness Training (PSAT) program that educates your employees using real-world scenarios, specifically initial access vectors like fake software downloads.
• Partner with a 24/7 multi-signal Managed Detection and Response (MDR) services provider for total attack surface visibility, 24/7 threat hunting and disruption, and rapid threat response to prevent attackers from spreading laterally through your environment.
  • However, at the bare minimum, organizations should use a Next-Gen AV (NGAV) or Endpoint Detection and Response (EDR) solution to detect and contain threats.

Indicators of Compromise

• Indicators of Compromise can be found in the table below:

References

• https://www.malwarebytes.com/blog/threat-intel/2026/03/a-fake-filezilla-site-hosts-a-malicious-download
• https://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange