OXLOADER is a newly discovered Windows malware loader that abuses the PE reloc section and anti VM checks to silently deploy the CASTLESTEALER infostealer through malicious Google Ads impersonating Node.js.

Have you ever thought that you just want to download the latest version of Node.js and click on a sponsored result on Google and behind this small gesture and there is a whole invisible war raging inside your machine without you even making a sound.

This is what Elastic Security Labs has now exposed when they discovered a completely new malware family named OXLOADER. This is not an ordinary loader but an engineering masterpiece that has so many layers hidden within itself that even automated tools fail to understand it.

OXLOADER Malware Loader Technical Analysis Explained

The whole sequence starts with a simple Google search. When a user searches for lts version of node.js they see a sponsored ad that leads directly to a fake landing page called node js prentiva99 info. This page looks exactly like the real Node.js platform.

The threat actor ran this ad campaign specifically for US-based victims, and the ad was last shown on April 23, 2026. The advertisers registered name is Volodymyr Tereshchenk from Ukraine but it is not clear whether this is the real operator or just a front account. Google permanently removed this advertiser and all of its campaigns from the system on May 14, 2026.

After clicking the user is redirected to the app miloyannopoulos.com which further leads to a Storj-based link from where a batch script BATPackageBuilderSetup.bat is downloaded. Storj is a legitimate link sharing service and the attacker used it only to evade domain reputation filtering. This batch script displays a fake installation wizard and also downloads an executable via PowerShell which is then run with the RunAs verb to trigger the UAC elevation prompt.

OXLOADER disguises itself as a tool similar to API Monitor which is popular from the site named rohitab.com. It starts its work in the CRT initializer phase itself, i.e. even before any user code is executed. The malware developer has hijacked an entry of the C Plus Plus initializer table which calls RegisterClipboardFormatW and then jumps directly to the first decryption stub.

This loader uses a self-modifying technique where a 28233 byte region is decrypted with a single byte XOR key and the key is automatically updated after every byte. This process is repeated three times on different regions.

To avoid static analysis OXLOADER uses four types of obfuscation layers including control flow flattening, mixed Boolean arithmetic opaque predicates, and function chunking. All of these together prevent even powerful tools like IDA Pro from understanding function boundaries. The malware also decrypts its strings at runtime and then dynamically resolves its required Windows APIs using the Adler 32 hashing algorithm.

The most interesting part is where OXLOADER tests its machine to see if it is actually a sandbox or virtual machine. The first check attempts to connect to a fake network resource via the WNetAddConnection2W function and only accepts a specific error code of ERROR_BAD_NAME. The second check verifies that the machine has at least three CPUs.

The third check verifies that the machine has at least three GB of RAM via GlobalMemoryStatusEx. The fourth check checks the displays refresh rate via WMI and if it is less than twenty Hz the malware automatically stops its execution because headless virtual machines often display zero or one Hz.

The last two checks are based on geographic region and language where the malware automatically stops running on GEOIDs of CIS region and systems with Russian language. This pattern tells researchers that a financially motivated Russian speaking threat actor is behind this malware.

When all the checks are passed, OXLOADER makes a copy of Windows own DirectUI Engine DLL dui70.dll and saves it with a random name with ocx extension like PFHemkxVk.ocx. This extension is the reason for giving this malware family its name.

Then the loader creates a new section in this file named xtext and gives it RWX permissions. The original malicious shellcode is then extracted from the reloc section and copied into this new section. The original purpose of the reloc section is to store base relocation entries and so the presence of code there is a major red flag.

This shellcode is created using an open source tool called DonutLoader which converts dotnet assemblies into position-independent shellcode. The configuration is then decrypted using the Chaskey LTS cipher and finally the original payload and the CASTLESTEALER infostealer is loaded into the machine memory as previously reported by Huntress.

CASTLESTEALER Detection Indicators and Mitigation Steps

Researchers have also discovered that a second variant of OXLOADER exists that disguises itself as a Node.js installer. This variant uses the same method, only the masquerading name is different. The redirector endpoint randomly returns two possible links which one containing a batch script and the other a direct executable named node v24.15.0 x64 x86.exe. This shows that the attacker is designing its infrastructure with enough flexibility that if one lure is captured and the other can continue working immediately.

From a detection perspective Elastic Defend successfully stopped this entire attack chain when the policy was in detect-only mode. The most important behavioral signals for cybersecurity teams include alerts such as suspicious memory loading of the Microsoft Common Language Runtime, Suspicious Thread Context Manipulation, VirtualAlloc API calls from an unsigned DLL and Module Stomping from a Copied Library.

All of these patterns are triggered because OXLOADER injects its code inside legitimate-looking DLL files. Elastic has also created specific rules for this family name Windows Trojan OxLoader and Windows Trojan CastleStealer which security teams can add to their detection pipeline.

The most important IOCs for network defenders include domains like node js prentiva99 info and app miloyannopoulos.com which should be added to the block list. IP addresses like 89.124.95.161 and 89.124.115.82 are being used for CASTLESTEALER command and control and they also need to be added to the monitoring lists.

The first and the simplest mitigation step is that users should always avoid downloading software through sponsored Google ads be it Node.js or any other popular developer tool. The safest way is to always type the URL of the official website yourself or download from a verified source.

Organizations should pay special attention to their PowerShell execution logs and immediately flag unusual processes running with the RunAs verb as this is a common sign of UAC bypass attempts. Batch scripts being downloaded from temporary directories or link sharing services like Storj is also a strong warning sign and can be blocked in endpoint policies.

Instead of relying solely on signature-based antivirus software security teams should deploy modern EDR solutions with behavioral detection that can also detect in-memory activities. Regularly auditing the size and content of the reloc section within PE files is another advanced but highly effective method, as legitimate compilers never insert executable code into this section.

Ultimately it is crucial that organizations alert their employees to the threat of malvertising as the actual success of this attack was due to a normal user trusting a seemingly normal search result. This entire story reminds us that today most dangerous attacks do not originate from some dark web forum but often from Google own search results. And unless we look with suspicion at even the smallest clicks of our daily lives this threat always finds its way.