In a newly disclosed multi-stage threat campaign, attackers were seen skipping disk and leaning on in-memory tricks to deliver the XWorm remote access trojan (RAT).
According to Forcepoint Labs’ findings, the campaign uses an encrypted shellcode that executes a .NET dropper and reflectively loads multiple in-memory DLLs. The initial lure was an Office .xlam attachment that embeds a native object linking and embedding (OLE) stream, unpacking the malicious code.
“The campaign is delivered by phishing email, using a fake invoice as a lure,” Forcepoint security researcher Prashant Kumar said in a blog post. “The malicious document (.xlam attachment) has an embedded ‘oleObject1.bin’ file, which hides embedded shellcode.”
Built to hide, move, and persist on the target, the XWorm RAT was deployed abusing legitimate Windows APIs to fetch and execute a downloader, along with layered anti-analysis techniques, including API hashing, “unhooked” calls, heavy obfuscation, and encryption.
Multi-stage attack hides RAT within spreadsheets
The “OLE10Native” stream, extracted from the .xlam archive in the infection email, conceals an encrypted shellcode blob. Forcepoint analysts used XORSearch and scdbg to find the shellcode’s execution offset and emulate it, revealing API calls that downloaded a .NET executable to the victim’s Application Data folder.
“While analysing the .NET compiled binaries, it is good to focus on the classes/methods that use ‘Drawing,’” Kumar pointed out. “The reason for this is that a lot of .NET malware will load a bitmap or object from its resource section and reflectively load the next stage into memory.”
That .NET executable then unpacks a byte array and uses a steganography image resource to load a second-stage DLL into memory, which in turn reflectively injects a third-stage module–the XWorm RAT itself. Each stage is loaded or executed in memory, minimizing on-disk artifacts and complicating detection efforts.
The XWorm findings fit into a broader shift in cyberattack strategies, where threat actors are increasingly favoring fileless delivery methods to bypass traditional detection. Recently, a campaign was reported using PowerShell-based loaders to deploy Remcos RAT entirely in memory.
Dodging sandboxes and scanners
The attackers relied on well-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 encryption layers inside .NET DLLs.
“The DLL file uses several encryption techniques for analysis to be difficult, such as RSACryptor, Virtualization, Fake.cctor, and many more,” Kumar noted.
Forcepoint analysis revealed that malware samples made API calls like “UrlDownloadToFile” and “LoadLibraryW” to execute code directly from memory in an attempt to beat conventional scanners. Additionally, the analysis flagged use of resource-embedded steganographic payloads, a common .NET trick to smuggle bytes into a benign-looking binary.
Recommended controls for protecting against XWorm-like campaigns include monitoring for unusual Office attachment types (especially .xlam with OLE native streams), inspecting processes that invoke UrlMon/UrlDownloadToFile followed by in-memory leads, and deploying runtime memory-scanning and EDR rules that detect reflective DLL injection and “unhooked” invocation patterns. The blog included a list of indicators of compromise (IoCs) to set detection for. Earlier this month, researchers reported fileless malware picking up an open-source upgrade in the form of AsyncRAT that ran PowerShell commands to fetch and assemble .NET payloads in memory.
No Responses