XWorm — From Phishing Email to RAT

Static and dynamic analysis of a multi-stage XWorm V7.1 delivery chain — from a spoofed MOHRE phishing email to a fully operational RAT injected into MSBuild.exe

Posted Sep 6, 2026 Updated Sep 28, 2026

By Nader Ayman Elsehrawii

22 min read

XWorm — From Phishing Email to RAT

Tools and detections: the config extractor, YARA rules, IOCs and ATT&CK layer from this analysis are on GitHub. The extractor has since been tested on 9 XWorm builds, V3.0 to V7.4.

On this page

XWorm TL;DR
XWorm Infection Vector
Technical Summary
Technical Analysis
Conclusion
IoCs
YARA Rule
MITRE ATT&CK
References

XWorm TL;DR

XWorm is a feature-rich Remote Access Trojan sold as Malware-as-a-Service on underground forums since 2022. It is builder-based — any buyer receives a panel and a generator producing customized payloads, which makes attribution to a specific threat actor rarely possible. In this sample, the payload arrived through a phishing email impersonating the UAE Ministry of Human Resources, delivered via a multi-stage chain starting with a JavaScript dropper and ending with XWorm V7.1 injected into MSBuild.exe. The previous sample I analyzed from the same family used a VBScript downloader — that analysis is documented here. Unlike that sample where the C2 was dead before the payload could be retrieved, this chain was fully intact and analyzed end to end.

XWorm Infection Vector

The attack arrives as a spoofed email impersonating the UAE Ministry of Human Resources & Emiratisation (MOHRE), one of the most authoritative government bodies in the region for employment and labor affairs. The email is addressed to help@banquemisr.ae and carries the subject line “Contract / عقد العمل”, presenting itself as an official employment contract notification. The body is brief and bilingual, Arabic and English, instructing the recipient to retrieve contract number MB308992219AE from the attachment. No malicious link, no suspicious phrasing. Just an authority figure telling you your contract is ready.

The sender display name reads Ministry of Human Resources & Emiratisation, but the actual sending address is ek@chaek.ru, routed through mail.lpltd.ru (77.232.184.7), a Russian mail server with no relation to any UAE government infrastructure. What makes this more deliberate is the spoofed References: header, which points to @DXBMAIL03.mol.local, an internal Exchange server hostname belonging to the UAE Ministry of Labour. The attacker either had prior access to a legitimate email thread from that domain, or fabricated the header knowing the target would recognize it as authentic internal correspondence. Either way, it is a calculated trust-building move.

The attachment MB308992219AE.r12 is declared as application/zip in the mail headers but is in fact part 13 of a multi-volume RAR archive. The victim receives only this fragment, the remaining parts, .r00 through .r11 and the base archive, were either delivered through a separate channel or retrieved after initial interaction. Once the full archive is reconstructed and extracted, a single JavaScript file is revealed: MB308992219AE.js, named identically to the contract number to maintain the illusion of legitimacy.

Technical Summary

Configuration Extraction: XWorm stores its entire configuration as AES-encrypted, Base64-encoded strings inside a static Settings class. The encryption key is derived from the mutex string using MD5, making the mutex the single key to the entire configuration. Decrypted, the configuration reveals the C2 server at 109.248.150.234:1012, the AES communication key, the C2 splitter, the install path, and the USB spreading filename.

C2 Communication: XWorm communicates with its operator over a raw TCP connection, with all traffic encrypted using AES and delimited by the splitter <Xwormmm>. On execution, XWorm profiles the infected host and sends a registration beacon to the C2 panel before awaiting operator commands.

Core RAT Capabilities: Here lies the bulk of its functionality. Once connected to C2, XWorm hands the operator full control over the infected machine. The available capabilities are:

Remote shell via cmd.exe
Screen capture
Keylogging
Clipboard monitoring and cryptocurrency address hijacking
File manager, upload, download, delete
Process manager, enumerate and terminate
USB spreading
Remote .NET assembly loading

Persistence: XWorm establishes persistence through three independent mechanisms, a registry run key, a scheduled task configured to run every minute, and a startup folder LNK shortcut. The binary copies itself to %AppData%\bin.exe and ensures execution survives reboots and process termination.

Technical Analysis

Stage 1 — JavaScript Dropper

First Look

MB308992219AE.js arrives as the final payload of the reconstructed RAR archive, named deliberately to match the contract number from the email. At 200.60 KB it is far larger than any legitimate JavaScript contract document would be — the bulk of that size is occupied by five large encoded blob variables carrying the encrypted payload and keys. At the time of analysis, 26 out of 50 security vendors on VirusTotal flagged it as malicious.

Opening the file reveals heavily obfuscated JavaScript disguised as a legitimate web analytics component. Every sensitive string is stored as an encrypted hex blob and decrypted on demand at runtime, nothing meaningful is visible in the static file without running the decryption pipeline first.

Obfuscation & Encryption Scheme

All function and variable names are replaced with randomized identifiers. Every sensitive string is passed through a custom decryption function __hdl_4f() at the moment it is needed, leaving no plaintext indicators in the static file. The decryption pipeline is multi-layered:

Hex blob
    → __key_5ab()     custom decoder using _0x1046b1 as charset
    → IV extraction   first 16 bytes
    → __mem_ff2()     custom key derivation producing two 32-byte subkeys
    → __tag_d7()      pre-decryption whitening XOR pass
    → __dat_fc()      AES-256 key schedule
    → __ctx_1d()      AES-256-CBC block decryption (14 rounds)
    → __dat_225()     ChaCha20-seeded Fisher-Yates substitution table
    → __mem_d9()      ChaCha20-style stream cipher XOR pass
    → __tmp_b9()      PKCS7 unpadding
    → plaintext

The hardcoded 32-byte base key __ctx_3f is embedded directly in the JS. Beyond string encryption, execution is gated behind two state machine counters, __sec_4cb and __ref_22e, that simulate legitimate widget activity before the payload is allowed to fire. __sec_4cb must reach 2 as the fake library data loads, and __ref_22e must reach 2 with at least 150 fake query rows accumulated. Only when both conditions are satisfied does the real code execute.

The five blob variables carry the entire attack:

Variable	Role
`_0x70b5b5`	Encrypted Stage 2 PowerShell script
`_0x4e45f3`	Encryption key
`_0x1046b1`	Custom hex charset
`_0x777de5`	`__DLL__` placeholder — encoded loader blob
`_0xd8faa8`	`__PLD__` placeholder — encoded XWorm blob

Static Analysis

The state machine gates and the encrypted blobs make this file resistant to automated analysis. To extract the payload statically, the full decryption pipeline was reimplemented in Node.js, replicating the simulateClick() logic exactly outside the browser environment.

Running the decryptor against the five blob variables produced a 63,271-character PowerShell script, Stage 2. The output opens with function Read-StreamConfig, confirming a clean decryption. The script was redirected to disk for further analysis.

Dynamic Analysis

To validate the static findings and observe the full execution behavior without running anything on the host, the deobfuscated JS was loaded in an isolated Chrome DevTools environment. The analysis was conducted entirely within the browser sandbox — no files written to disk, no processes spawned.

The malware’s execution gates were bypassed by forcing both state counters to 2 before the JS loaded. The real FileSystemObject and Shell.Application ActiveX objects were replaced with JavaScript stubs that mirror the real API surface but log every call to console instead. The ShellExecute call was patched out and replaced with a console log capturing the exact command that would have executed.

With the gates bypassed and the decryption pipeline run directly in the console, __obj_14 was populated with 138,292 characters of plaintext, the same PowerShell script the static approach produced, confirming both methods independently.

Calling __cnt_d7a() triggered the full execution path. The following files were intercepted before they would have been written to disk:

Two blobs being written to the same random folder

The main script (.ps1) and what it does:

Step 1 — Blob 1 decoded from disk, decrypted via XOR-rotate-AES pipeline, and loaded as a .NET assembly into the PowerShell process memory:

Step 2 — Blob 2 decoded and decrypted into an in-memory byte array; its exact format is determined by the loaded assembly, not the PowerShell script:

Step 3 — AC1_1.OrderWorkflow.ProcessFulfillment called:

Step 4 — MSBuild path resolved:

Step 5 — Console hidden via two independent mechanisms:

FreeConsole() detaches from the console; ShowWindow(..., 0) hides the window. The PowerShell script dynamically constructs P/Invoke declarations for FreeConsole, GetConsoleWindow, and ShowWindow, enabling interaction with the Windows console without directly exposing the API names in plaintext. The loader calls FreeConsole() to detach from the console and subsequently obtains the console window handle using GetConsoleWindow() and calls ShowWindow(..., 0), where 0 corresponds to SW_HIDE, to conceal the window from the user.

Every execution generates a fresh 8-character folder name, a 4-character hex session tag, and randomized filenames drawn from a rotating prefix pool — dat_, cfg_, run_, svc_, tmp_. Filesystem IOCs are useless for detection. The only stable artifacts are the hardcoded crypto keys embedded in the JS.

Different folder names across two runs

Step 6 — The intercepted launcher revealed the exact execution command, and both scripts clean up after themselves:

32-bit PowerShell is used deliberately — SysWOW64\powershell.exe rather than the 64-bit equivalent — consistent with the x86 payload that follows. After execution, both the .cmd launcher and the PowerShell script independently clean up all written files. The launcher self-deletes via @(goto) 2>nul & del "%~f0". By the time any forensic tool examines the filesystem, nothing remains.

Stage 2 — PowerShell Loader

The launcher executes svc_82497_95cb.ps1 via 32-bit PowerShell with -w h -nop -ExecutionPolicy Bypass. The script’s first task is decoding the two blobs from disk using Read-StreamConfig, a custom base52 decoder that processes input in 10-character chunks, each decoding to 7 bytes using a lookup table built from A–Z and a–z. The result is a raw byte array ready for decryption.

Decryption is handled by StreamHelper.Expand(), compiled at runtime via Add-Type. It applies three sequential transforms to each blob:

input bytes
    → XOR with IV byte at position (i & 15)
    → rotate right by (k[(i+7) & 31] % 7) + 1 bits
    → XOR with k[i % kl] and k[(i+17) & 31]
    → AES-CBC PKCS7 decrypt (key=k, iv=iv)

The keys and IVs are hardcoded in plaintext inside the PowerShell script — no derivation required:

k1: 2F EF CA F8 36 D3 4A A0 7E 83 12 96 01 8F A1 75
    5F CA 46 B7 AD 30 2E C8 84 E8 6A 18 80 1E AE E7
v1: B1 F6 F7 C7 26 0B F2 61 2F 17 CA 01 EB 23 6F E7

k2: 6D E9 01 6D 6E 1A 50 1B 7C C3 35 55 8B 07 9D 70
    EE DD 27 00 16 D2 80 26 85 CA E0 FF FA 70 C9 84
v2: 87 CE 9E 81 BD D8 81 71 B1 DD 0F 53 2B 42 41 12

Blob 1 decrypts to a .NET loader assembly, loaded directly into the PowerShell process memory via AppDomain.CurrentDomain.Load(byte[]) — never written to disk as a DLL. Blob 2 decrypts to the XWorm payload bytes, passed directly to the loaded assembly.

The loader then reflectively resolves and invokes AC1_1.OrderWorkflow.ProcessFulfillment(string, byte[]) on the in-memory assembly, passing the hardcoded MSBuild path and the XWorm bytes. The injection target is not decided at runtime — it is hardcoded:

  
$tp = "C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"

Joe Sandbox confirmed process hollowing — PowerShell.exe injects the XWorm PE into MSBuild.exe at base address 0x6D0000. MSBuild.exe is spawned as the host process and the XWorm image is mapped into its address space, replacing its legitimate code. From this point XWorm runs entirely within the MSBuild.exe process context — all network connections, registry writes, and persistence operations originate from a trusted Microsoft binary.

The #XLOADER comment immediately below marks an alternate execution mode where the current process path is used instead — a builder artifact indicating this script is generated by a tool with multiple output configurations.

After execution, both blob files and the PowerShell script are deleted via Remove-Item -Force -EA 0. The console is suppressed via FreeConsole() and ShowWindow(hwnd, 0) before the injector fires.

Stage 3 — XWorm V7.1 RAT

First Look

stage3_payload.bin is a 32-bit .NET assembly, 35.50 KB. 56 out of 69 security vendors on VirusTotal flagged it as malicious.

Configuration Extraction

XWorm stores its configuration as AES-encrypted, Base64-encoded strings inside the Settings class.

AlgorithmAES.Decrypt() derives the AES key by computing MD5(UTF-8(mutex)) — producing a 16-byte digest — then building a 32-byte key with two Array.Copy calls:

  
Array.Copy(array2, 0, array, 0,  16);  // digest → positions 0–15
Array.Copy(array2, 0, array, 15, 16);  // digest → positions 15–30

The second copy starts at position 15, overwriting array[15] with digest[0]. The resulting 32-byte key is:

digest[0..14] | digest[0] | digest[1..15]

Position 15 holds digest[0], not digest[15]. This one-byte overlap is deliberate — it makes the key non-standard while keeping derivation simple and reproducible from the mutex alone. Anyone replicating the config extractor must implement this exact overlap or produce a wrong key. The key is used for AES-256 in ECB mode, so there is no IV and each Base64 setting decrypts on its own.

To extract the configuration statically, I reimplemented the key derivation and decryption in Python. The extractor is published here. It finds the mutex by itself, so it also works on builds where the field names are obfuscated.

The decrypted configuration reveals the C2 at 109.248.150.234:1012, with <V7PV7PV7PV7PV7P> as the AES communication key and <Xwormmm> as the stream splitter. Both are default values from the XWorm V7.1 builder, unchanged by the operator.

The C2 at 109.248.150.234 is hosted by SIA RixHost (AS203557) in Zwolle, Netherlands, a data center and web hosting provider. The IP has one prior abuse report from December 2024 flagging a webmail attack, with a current abuse confidence of 0%. No other malware families have been publicly linked to this address at the time of analysis, suggesting either a freshly provisioned or low-activity C2 node.

C2 Communication

XWorm communicates over raw TCP using a length-prefixed framing protocol. Every message on the wire follows this structure:

[ ASCII length string ][ 0x00 null byte ][ AES-128-ECB ciphertext ]

The receiver reads one byte at a time until the null terminator, parses the declared length, then reads exactly that many bytes before dispatching the payload to the command handler.

Triage sandbox confirmed repeated outbound connections to 109.248.150.234:1012 from the XWorm process — consistent with the reconnection loop firing every 3–10 seconds on failed connection attempts.

On connection, XWorm immediately sends a registration beacon — INFO — carrying the victim’s hardware ID, username, OS version, group tag, CPU, GPU, RAM, antivirus products, webcam presence, UAC level, and idle time. The operator’s panel receives a full victim profile before issuing a single command.

The heartbeat fires every 10–15 seconds — randomized to avoid fixed-interval network signatures — reporting the currently focused window title and idle time to the operator.

Command Dispatcher

All incoming traffic is handled by Read(), which decrypts each packet, splits on <Xwormmm>, and dispatches on the first token. The full command set:

Read() function — full command dispatcher

Core Capabilities

Remote Shell

RunShell passes the operator’s command string directly to a hidden cmd.exe process. Full interactive shell over the encrypted C2 channel.

Drop and Execute

RunDisk() writes a received payload to %TEMP%\<6-char random><extension> and executes it. .ps1 payloads are launched with -ExecutionPolicy Bypass automatically.

Reflective Loading

Memory() loads a received .NET assembly directly into the malware’s process memory via AppDomain.CurrentDomain.Load(byte[]) — no file ever touches disk.

Screenshot Capture

The $Cap command captures the primary screen at 16bpp, downsizes to 256×156 JPEG, GZip-compresses it, and sends it as #CAP to the C2 panel. Designed for low-bandwidth live monitoring.

Process Monitor

Monitoring() takes a comma-separated keyword list from the operator and scans all running process window titles every second. When a target keyword is detected, a bank name, crypto wallet, anything, it sends an alert to C2. Used for targeted surveillance.

HTTP Flood

TD() spawns 20 concurrent threads per round, each sending an HTTP POST with a randomized User-Agent to the target. Rounds fire every 5 seconds for the configured duration. Controlled by StartDDos / StopDDos.

Hosts File Manipulation

Hosts reads and exfiltrates the full hosts file. Shosts overwrites it with operator-supplied content — silently redirecting any domain on the victim machine.

Plugin System

XWorm supports a modular plugin architecture. Plugins are .NET assemblies pushed from C2, loaded reflectively, and cached in the registry between sessions. The plugin dispatcher supports execution, credential recovery, process injection, UAC bypass, and ransomware encryption and decryption — all gated behind the ENC/DEC state flag to prevent double-encryption.

Anti-Analysis & Evasion

XWorm prevents the host from sleeping via SetThreadExecutionState with ES_CONTINUOUS | ES_SYSTEM_REQUIRED | ES_DISPLAY_REQUIRED — keeping the machine and display awake indefinitely while it runs.

Windows Defender exclusions are added via PowerShell -ExecutionPolicy Bypass if the process has admin privileges — covering both the running executable and the install path, by path and by process name.

Persistence — Three Mechanisms

1. Scheduled Task (runs every minute):

  
processStartInfo.Arguments = "/create /f /RL HIGHEST /sc minute /mo 1 /tn \"<name>\" /tr \"<path>\"";
// If not admin, same command without /RL HIGHEST

/sc minute /mo 1 fires every minute, making persistence far more aggressive — the malware is relaunched every 60 seconds regardless of whether a new logon occurs. Admin runs additionally get /RL HIGHEST for elevated execution.

2. Registry Run Key:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\<InstallStr name> = "<InstallDir>\<InstallStr>"

3. Startup Folder Shortcut:

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\bin.lnk

After creating the shortcut, Helper.fileStream = new FileStream(lnk, FileMode.Open) opens and holds a file handle on the .lnk, keeping it locked so it cannot be deleted by security tools without first closing the handle. Uninstaller.UNS() explicitly calls Helper.fileStream.Close() before attempting deletion.

The uninstaller cleanly removes all four artifacts in sequence: the persistence copy, the registry run key, the scheduled task, and the startup shortcut — then self-deletes via a temporary batch file with a 3-second timeout.

Three independent persistence mechanisms

Conclusion

XWorm V7.1 is a capable and actively maintained remote access trojan distributed as a commodity builder on underground forums. This sample arrived through a carefully constructed phishing email impersonating the UAE Ministry of Human Resources & Emiratisation — a government authority with direct relevance to the target’s employment status. The lure required no interaction beyond opening the attachment, and the delivery chain was designed to leave nothing on disk by the time the payload was running.

The JavaScript dropper is the most technically sophisticated component of the chain. Its multi-layer encryption scheme, state machine execution gates, and filesystem interception make it resistant to both static analysis and automated sandboxing. The PowerShell loader that follows is compact and purpose-built — it decrypts, loads, and injects with no unnecessary complexity. XWorm itself is the final reward: a full-featured RAT with remote shell, keylogging, screen capture, clipboard hijacking, USB spreading, a plugin system that extends to ransomware, and three independent persistence mechanisms that make removal non-trivial.

The operator made no meaningful customization to the builder defaults — the AES key, splitter, and group tag are all factory values. That points to a low-effort deployment. The delivery tells a different story. Spoofing an internal UAE Ministry of Labour Exchange hostname in the References: header is calculated and researched — not something a careless actor does. The payload was left untouched. The lure was not.

IoCs

No.	Description	Value
1	Phishing attachment	`8f6b44db0884d056ba1ea591679fa5ce6cdebb53c4ee6e925e21400ff6d3535e`
2	JavaScript dropper	`81f93dc173ad6b2d7592447c7910f70df668b1a06f7c2fcce08188a99d38dcb3`
3	XWorm payload / `bin.exe`	`9ef39965263531f35203eea0a1924181264cf6d7f3832d939cd532d5fad77a2d`
4	Startup shortcut (`bin.lnk`)	`2175df45893a994d82868e142b7d591a4c08efa764a53d9f45ec0fc32b4e5582`
5	XWorm C2	`109.248.150.234:1012`
6	Mutex	`aGO284VKfQVe8Vup`
7	Sending server	`77.232.184.7`

YARA Rule

The rule below is the one from the original analysis. An updated set of three rules (family, campaign payload and PowerShell loader), tested on 9 payloads with no hits on System32, is in the repo: xworm.yar.

  
rule xworm_v71 : rat
{
    meta:
        description = "Detects XWorm V7.1 payload and delivery chain"
        author      = "Artful Dodger"
        date        = "2026-09"
        hash        = "9ef39965263531f35203eea0a1924181264cf6d7f3832d939cd532d5fad77a2d"

    strings:
        $x1 = "AlgorithmAES" ascii wide
        $x2 = "aGO284VKfQVe8Vup" ascii wide
        $x3 = "Xwormmm" ascii wide
        $x4 = "AC1_1.OrderWorkflow" ascii wide
        $x5 = "ProcessFulfillment" ascii wide

        $ps1 = "Read-StreamConfig" ascii
        $ps2 = "StreamHelper" ascii
        $ps3 = "SysWOW64\\WindowsPowerShell" ascii wide
        $ps4 = "(goto) 2>nul & del" ascii

        $k1 = { 2F EF CA F8 36 D3 4A A0 7E 83 12 96
                01 8F A1 75 5F CA 46 B7 AD 30 2E C8
                84 E8 6A 18 80 1E AE E7 }

    condition:
        (3 of ($x*)) or
        (3 of ($ps*)) or
        ($k1)
}

MITRE ATT&CK

References

ANY.RUN interactive analysis — XWorm payload
https://app.any.run/tasks/3c61aa71-87f8-4e16-9af0-7b1fe34fecbe/
Joe Sandbox full report
https://www.joesandbox.com/analysis/1965848/0/html
Aziz Haddadi — XWorm V3.1 Analysis (structural reference for version comparison)
https://github.com/aziz-haddadi/XWorm-V3.1-Analysis
Triage Sandbox Behavioral Analysis
https://tria.ge/260904-ptndks1bnb/behavioral2
AbuseIPDB IP Check
https://www.abuseipdb.com/check/109.248.150.234
MITRE ATT&CK
https://attack.mitre.org

Malware Analysis

This post is licensed under CC BY 4.0 by the author.

XWorm TL;DR

XWorm Infection Vector

Technical Summary

Technical Analysis

Stage 1 — JavaScript Dropper

First Look

Obfuscation & Encryption Scheme

Static Analysis

Dynamic Analysis

Stage 2 — PowerShell Loader

Stage 3 — XWorm V7.1 RAT

First Look

Configuration Extraction

C2 Communication

Command Dispatcher

Core Capabilities

Anti-Analysis & Evasion

Persistence — Three Mechanisms

Conclusion

IoCs

YARA Rule

MITRE ATT&CK

References

Trending Tags