Cybercriminals Exploit Fake Financial Receipts to Deploy XWorm Malware on Windows Systems
A sophisticated multi-stage malware campaign is actively targeting businesses in Brazil and Latin America by distributing counterfeit bank receipts to deliver XWorm v5.6, a remote access trojan (RAT) capable of stealing credentials, hijacking sessions, and facilitating ransomware attacks.
Initial Infection Vector: Deceptive File Extensions
The attack begins with a file masquerading as a Bradesco bank receipt, labeled Comprovante-Bradesco…. This file employs a double-extension trick (.pdf.js) to appear as a legitimate PDF document, deceiving users into opening it. In reality, it is a Windows Script Host (WSH) dropper, inflated to approximately 1.2MB with junk data—a tactic designed to evade static analysis scanners that often skip oversized files.
Obfuscation Techniques: Unicode Junk Injection
The embedded JavaScript payload is obfuscated using Unicode junk injection, embedding malicious code within large string variables filled with emojis, homoglyphs, and non-ASCII characters. At runtime, a delimiter-based reconstruction method utilizes a simple `.replace()` function to strip away the extraneous data, reconstructing the PowerShell command responsible for fetching the next stage of the attack.
Execution Methods: Leveraging WMI for Stealth
Instead of using the more detectable `WScript.Shell.Run`, the dropper employs Windows Management Instrumentation (WMI) (`Win32_Process`) to spawn PowerShell in a hidden window (`ShowWindow = 0`). This approach minimizes visibility and includes a hardcoded `Sleep(5000)` delay to bypass sandbox heuristics.
Stage 2: Steganography and Cloudinary Abuse
The decoded PowerShell command reaches out to a hardcoded Cloudinary URL—a trusted image hosting service—to download what appears to be a standard JPEG file (`optimized_MSI_lpsd9p.jpg`). The URL is constructed at runtime using a `.Replace(‘#’,’h’)` function to evade static string detection, making the traffic blend with legitimate image downloads.
This downloaded image contains a hidden .NET assembly embedded between `BaseStart-` and `-BaseEnd` markers. The PowerShell script extracts this Base64-encoded blob and loads it directly into memory using `[Reflection.Assembly]::Load()`, ensuring that Stage 3 never touches the hard drive—a fileless execution technique that bypasses traditional antivirus scans.
Stage 3: Establishing Persistence
Before invoking the assembly, the loader decodes a reversed Base64 argument string that reveals the final XWorm payload URL: `voulerlivros[.]com[.]br/arquivo_20260116064120.txt`.
Rather than spawning a detectable `cmd.exe /c schtasks /create` command, the Stage 3 VB.NET DLL interacts directly with the Windows Task Scheduler via COM interfaces (`TaskService`, `TaskDefinition`) within the .NET framework. This method leaves no command-line artifacts, causing the scheduled task to appear in system logs without a corresponding execution command, effectively blinding defenders who rely on process-spawn monitoring.
Critically, the persistence task does not launch XWorm directly; instead, it re-executes the Stage 2 PowerShell loader on each logon, creating a modular re-infection loop.
Final Payload: XWorm v5.6 Deployment
The final payload, despite carrying a `.txt` extension, is a reversed Base64-encoded .NET executable identified as XWorm v5.6. The malware injects itself into `CasPol.exe` (Code Access Security Policy Tool), a legitimate binary located at `C:\Windows\Microsoft.NET\Framework\v4.0.30319\`, abusing this Living off the Land Binary (LOLBIN) to blend with trusted system processes.
By exploiting this legitimate binary, the malware attempts to blend in with trusted system processes. However, in sandbox environments, this anomaly is immediately flagged due to the suspicious network activity originating from a trusted utility.
Configuration and Command-and-Control Infrastructure
Static analysis reveals that the configuration is AES-ECB encrypted with a key derived from the MD5 hash of a hardcoded mutex—a cryptographically weak implementation that allows offline decryption. The decrypted configuration exposes the full command-and-control (C2) infrastructure:
– C2 Domain: jholycf100[.]ddns[.]com[.]br
– C2 IP: 152[.]249[.]17[.]145
– Port: 7000
– Mutex: V2r1vDNFXE1YLWoA
– Protocol Splitter: `
– Payload URL: voulerlivros[.]com[.]br/arquivo_20260116064120.txt
– Stego Loader URL: res[.]cloudinary[.]com/…/optimized_MSI_lpsd9p.jpg
– Install Path: C:\Users\Public\Downloads\
– File Hash (SHA-256): 7befeacf0b3480fb675d0cab7767b5b9697edc9d0e05982025a06ead0054afd5
Once XWorm establishes control via `CasPol.exe`, attackers can harvest browser sessions, steal credentials, log keystrokes, and pivot into email, SaaS, and financial platforms, turning a single employee click into a full identity-driven incident.
Implications and Recommendations
The campaign’s low-noise delivery stack inflates Mean Time to Respond (MTTR) because the initial events—image downloads, background PowerShell execution, and absence of dropped binaries—appear benign, while the real impact surfaces later. Realistic worst-case outcomes include business email compromise (BEC), fraudulent payments, and ransomware staging.
Security teams should prioritize monitoring controls based on this attack chain:
1. Delivery Stage: Alert on `.js` or double-extension files (`.pdf.js`) spawning WMI-invoked PowerShell processes.
2. Network Stage: Flag outbound traffic to image hosting services (e.g., Cloudinary) where responses contain non-standard markers like `BaseStart` within binary streams.
3. Endpoint Stage: Treat any outbound network connections originating from `CasPol.exe` as high-confidence malicious activity requiring immediate investigation.
Threat hunters can query threat intelligence platforms with parameters like `threatName:xworm AND submissionCountry:br` to surface the latest XWorm samples attributed to Brazilian infrastructure and pivot into related delivery domains.
