Unraveling OXLOADER: A Sophisticated Windows Loader
A newly identified Windows loader, designated OXLOADER, has surfaced, showcasing a strikingly advanced method of evading detection. This malware employs intricate obfuscation techniques combined with unconventional staging methods, effectively bypassing static detection mechanisms and complicating sandbox analysis processes. At the end of its sinister agenda, OXLOADER facilitates the delivery of a troublesome infostealer known as CASTLESTEALER through malvertising tactics.
Recent reports indicate that this malicious endeavor has relied on deceptive Google Ads that masquerade as legitimate applications, specifically Node.js and API Monitor. Victims clicking on these ads are rerouted through various intermediary domains, leading them to batch scripts hosted on Storj, which ultimately download and execute OXLOADER. The execution process is further complicated by User Account Control (UAC) elevation prompts, designed to mislead users.
The analysis reveals alarmingly low detection rates for OXLOADER across many static engines and sandbox detonations. These low rates are compounded by the exclusion of specific CIS regions and the primary usage of the Russian language, indicating that the campaign is likely being executed by a financially motivated group of Russian-speaking cybercriminals.
From a technical standpoint, OXLOADER is meticulously crafted to undermine typical signature and automated analyses. The execution process begins at the CRT initializer phase. Here, the malware hijacks a C++ initializer entry to execute a RegisterClipboardFormatW call, seamlessly blending its malicious logic into the startup of a seemingly benign program. This initial step leads the loader into the first decryption stub without raising suspicion.
OXLOADER utilizes a series of transforming, self-modifying decryption stubs in conjunction with a rolling-XOR routine. This routine dynamically updates the XOR keys by adding the most recently decrypted byte, effectively recycling this approach across various regions to unpack extensive code segments while the program is running. Such techniques frustrate traditional analysis tools and enrich the malware’s stealth capabilities.
Adapting defense mechanisms to further thwart attempts at static and automated analysis, OXLOADER is equipped with multiple nested control-flow flattening techniques, opaque predicates, and mixed Boolean-arithmetic (MBA) methods. These strategies prevent function-boundary recovery in tools like IDA Pro, compelling analysts to resort to manual reconstruction, which is time-consuming and intricate.
Indirect jumps calculated through MBA expressions allow OXLOADER to stitch together functions from non-adjacent code regions, introducing further complexity that undermines the accuracy of static analyses. Elastic Security Labs has extensively studied OXLOADER and noted that its import and string resolution processes are dynamic and heavily obfuscated. Imports are resolved in real-time through an arithmetic-XOR routine combined with the Adler-32 API hashing algorithm, a dual approach that results in exceedingly low detection rates on platforms like VirusTotal.
The loader does not stop at simply evading detection; it employs various environmental checks to deter sandboxing and virtual machine analysis. For instance, OXLOADER invokes WNetAddConnection2W with crafted parameters, deliberately expecting certain error codes. Once these checks are performed, it filters out common analysis setups based on CPU count, physical memory limits, and display refresh rates—criteria that are designed to exclude many emulated environments.
Furthermore, OXLOADER’s use of the PE (.reloc) section stands out as a noteworthy innovation. The malware duplicates a legitimate system DLL, specifically dui70.dll, and then renames it to a random .ocx file. After creating a new readable-executable writable (RWX) section, it embeds its shellcode from the original .reloc segment into this newly established RWX area, raising significant concerns about its legitimacy; such actions are generally uncommon in standard toolchain processing.
The subsequent payload delivered by OXLOADER includes shellcode generated from DonutLoader, which decrypts and executes a .NET infostealer known as CASTLESTEALER entirely in memory. This final payload shares command-and-control (C2) encryption markers and keys with previously documented samples, hinting at an organized and sophisticated operational structure.
Operational traces reveal that the threat actors behind this campaign utilized verified Google Ads identities (with registered names linked to Ukraine) and took advantage of Storj for hosting purposes, a ploy designed to obscure their activities and evade scrutiny. Google removed the offending ads and their associated advertiser profile in mid-May 2026.
Elastic Defend has successfully thwarted the full operational chain observed in various incidents through advanced behavioral prevention rules. Security professionals are encouraged to prioritize telemetry surrounding CRT initializer hooks, peculiar .reloc contents, RWX sections created in copied DLLs, as well as runtime MBA/CFF patterns. By monitoring malvertising channels and implementing behavior-first prevention tactics, they can significantly restrict OXLOADER’s operational window while ongoing research continues to uncover further insights into this evolving threat landscape.