XWorm campaign shifts to fileless malware

In a recently uncovered multi-stage campaign, attackers were observed bypassing the disk and relying on in-memory techniques to deliver the XWorm remote access trojan (RAT). According to findings from Forcepoint Labs, the campaign uses encrypted shellcode that executes a .NET dropper and reflectively loads multiple DLLs into memory.

See also: Mustang Panda develops SnakeDisk USB Worm to distribute Yokai Backdoor

The initial bait was an Office .xlam that embeds an OLE stream, extracting the malicious code. “The campaign is delivered via phishing email, using a fake invoice as bait,” Forcepoint security researcher Prashant Kumarin a blog post. “The malicious document (.xlam attachment) has an embedded file ‘oleObject1.bin’, which hides embedded shellcode.”

Built to hide, move, and stay on target, the XWorm RAT was developed by exploiting legitimate Windows APIs to retrieve and execute a downloader, along with multi-layered analysis techniques, including API hashing, “unhooked” calls, strong obfuscation, and encryption. The multi-stage attack hides the RAT inside spreadsheets. The “OLE10Native” stream, extracted from the .xlam file in the infection email, hides an encrypted blob of shellcode.

Forcepoint analysts used XORSearch and scdbg to find the shellcode execution offset and emulate it, revealing API calls that downloaded a .NET executable to the victim's Application Data folder. “When analyzing .NET compiled binaries, it's a good idea to focus on classes/methods that use 'Drawing,'” Kumar noted. “The reason for this is that many .NET malware will load a bitmap or object from its resource section and reflectively load the next stage into memory.”

See also: Variant of XWorm Delivered via Windows Script File

The .NET executable then decompresses a string of bytes and uses a steganographic image resource to load a second-stage DLL into memory, which in turn reflexively inserts a third stage – the XWorm RAT itself. Each stage is loaded or executed in memory, minimizing files on disk and complicating detection efforts. The XWorm findings are part of a broader shift in cyberattack strategies, where threat actors are increasingly favoring fileless delivery methods to bypass traditional detection.

Recently, a campaign was reported that used PowerShell-based loaders to deploy the Remcos RAT entirely in memory. The attackers relied on known evasion techniques throughout the chain, including API hashing to hide intent, API calls that bypass user-mode hooks installed by security software, and multiple layers of encryption within .NET DLLs.

Forcepoint’s analysis revealed that the malware samples made API calls such as “UrlDownloadToFile” and “LoadLibraryW” to execute code directly from memory in an attempt to evade conventional scanners. Additionally, the analysis flagged the use of resource-embedded steganographic payloads, a common .NET trick to transfer bytes into a seemingly innocent binary.

Recommended controls to protect against XWorm-type campaigns include monitoring for unusual Office attachment types, inspecting processes that call UrlMon/UrlDownloadToFile followed by drivers in memory, and deploying real-time memory scanning and EDR rules that detect reflective DLL injection and “unhooked” call patterns.

See also: New CMoon worm targets Russians in data theft attacks

The blog included a list of indicators of compromise (IoCs) to set up detection. Earlier this month, researchers reported that the fileless malware was getting an open-source upgrade in the form of AsyncRAT that executed PowerShell commands to retrieve and assemble .NET payloads in memory.