OXLOADER: Malicious Google Ads Deliver…

Elastic Security Labs uncovers OXLOADER, a previously undocumented Windows loader distributed via malicious Google Ads impersonating Node.js downloads to deliver CastleStealer with near-zero detection rates thanks to multi-layered obfuscation.

Elastic Security Labs has discovered and documented OXLOADER, a previously unknown Windows malware loader distributed through malicious Google Ads that impersonate Node.js downloads. The campaign, revealed on June 19, 2026, delivers the CastleStealer infostealer with extremely low detection rates across static engines and sandboxes, thanks to an evasion engineering effort that researchers describe as deliberate and multi-layered. The abuse of a "trusted" advertising platform to distribute sophisticated malware represents the latest evolution of a threat where the campaign's low operational cost clashes with a malware R&D investment that challenges traditional defenses.

Key Takeaways

OXLOADER is a new Windows loader, previously undocumented publicly, discovered by Elastic Security Labs in an active campaign against one of their customers.
Distribution occurs via verified Google Ads impersonating Node.js, targeting queries such as "lts version of node.js," redirecting to batch scripts hosted on Storj.
The loader employs four layered obfuscation techniques (control-flow flattening, mixed Boolean-Arithmetic, opaque predicates, function chunking) and five anti-VM/sandbox checks to evade analysis.
Execution begins during the CRT initializer phase, with anomalous shellcode staging in the .reloc section — a characteristic legitimate toolchains do not produce — followed by in-memory execution via DonutLoader.

Verified Google Ads as Delivery Channel: The ВОЛОДИМИР ТЕРЕЩЕНКО Account

The campaign's social engineering leans on the trust users place in Google's sponsored results. According to Elastic research, cited by The Hacker News, the malicious ads target specific searches like "lts version of node.js" and appear under a verified advertiser account name: "ВОЛОДИМИР ТЕРЕЩЕНКО," with an apparent location in Ukraine. This detail is significant: the account verification, which confers visual legitimacy, did not prevent malicious use until its removal on May 14, 2026, according to timelines gathered by Cyber Security News. The last ad is dated April 23, 2026.

The redirect chain is articulated: from the ad, users land on node-js[.]prentiva99[.]info, then via app[.]miloyannopoulos[.]com they reach a batch script hosted on link[.]storjshare[.]io. The use of Storj, a legitimate decentralized cloud storage service, serves to evade reputation-based domain filters, as documented by Elastic. The batch script presents a fake wizard installation interface while, in the background, PowerShell silently downloads OXLOADER with the -Verb RunAs parameter to trigger a UAC prompt. This design reflects an awareness of user behavior: the familiar installation routine disarms caution, while privilege elevation is achieved through legitimate Windows patterns.

It remains unconfirmed whether the Google account is controlled directly by the threat actor, represents a purchased identity, or a front account. The dossier does not specify how the apparent Ukrainian identity was verified by Google, nor whether it corresponds to a real entity.

Four-Layered Obfuscation: When the Loader Becomes an Evasion Platform

OXLOADER is not a simple dropper. Elastic researchers describe a stratified obfuscation system that breaks automatic detection of functional boundaries in tools like IDA Pro. The four identified techniques are: control-flow flattening (CFF), which flattens the execution graph into a single dispatcher; mixed Boolean-Arithmetic (MBA), which replaces logical operations with equivalent but opaque algebraic expressions; opaque predicates, conditions that are always true or false but constructed to appear input-dependent; and function chunking, which splits functions into non-contiguous memory regions.

Decryption occurs via self-modifying stubs with rolling-XOR: the decrypted plaintext byte is added to the key for the next iteration, repeated three times across different binary regions. The first decrypted region measures 28,233 bytes. Strings are further obfuscated with a function that dynamically resolves imports via Adler-32 API hashing and decryption with a hardcoded constant 0x33FDA. This level of complexity, as noted by Elastic Security Labs' Daniel Stepanic and Jia Yu Chan, "reflects deliberate engineering choices oriented toward evading analysis."

Dynamic import resolution and self-modification also render pure static analysis ineffective: executable code emerges only in memory during execution, and the detectable footprint before runtime is drastically reduced.

Five Anti-VM Checks and the .reloc Abuse Anomaly

OXLOADER implements five anti-VM and anti-sandbox checks, documented in detail by Elastic: a call to WNetAddConnection2W with a malformed resource (*72s@1s) that verifies the value LastErrorValue=ERROR_BAD_NAME(0x43) via the TEB; verification that CPU count is ≥3; RAM ≥3GB; display refresh rate ≥20Hz via WMI Win32_VideoController; and exclusion of the CIS region with Russian language (LANGID 0x419). These last two checks support the hypothesis, cautiously formulated by researchers, of a Russian-speaking, financially motivated actor.

The most unusual staging technique is the abuse of the .reloc section. OXLOADER copies dui70.dll to a randomly named .ocx file, creates a .xtext section with RWX permissions, and copies shellcode from the binary's original .reloc section into it for execution. As Elastic documents: "the malware developer is using the .reloc section to house malicious code instead of the base relocation entries. This is a strong static-analysis red flag: legitimate toolchains do not emit code into the .reloc section." This anomaly is statically detectable, but only if you know what to look for — and most engines do not.

Execution begins during the CRT initializer phase, before any user code, by hijacking an entry in the C++ initializer table. This early positioning ensures the payload is active before many security product hooks are installed.

From OXLOADER to CastleStealer: The In-Memory Chain

The final payload, CastleStealer, executes entirely in memory via DonutLoader, an open-source tool. C2 communication is encrypted with AES. CastleStealer is a .NET infostealer already documented in previous campaigns, including the BackgroundFix campaign attributed to GrayBravo, where it was distributed via CastleLoader. In this campaign, OXLOADER serves as an independent vector, with distinct delivery mechanisms and engineering.

Elastic Security Labs identified a secondary OXLOADER variant, discovered on May 13, 2026, disguised as a Node.js installer (node-v20.7.0-x64.exe) instead of API Monitor, but with an identical mechanism. This variability in the lure suggests operational flexibility and A/B testing on user conversion rates.

The detection rate has been described by multiple sources as "low detection rates across static engines and sandbox detonations" (Elastic), "low detection rates across static engines and detonation runs" (The Hacker News), and "remarkably low detection rates" (Cyber Security News). The investment in obfuscation, according to researchers, "is paying off": OXLOADER operates in a window of invisibility before being identified and "hunted down."

What to Do Now

The nature of the threat requires a repositioning of defenses beyond static signatures. Elastic Defend detected malicious behavior with multiple behavioral rules, including "Microsoft Common Language Runtime Loaded from Suspicious Memory." This indicator — the loading of the CLR from non-standard memory — is a detection pattern applicable to other infrastructures as well.

Priority recommendations, derived from the technical documentation, are: monitor PowerShell execution with -Verb RunAs in software installation contexts; behaviorally analyze the loading of .NET runtimes from suspicious memory regions; inspect anomalous PE sections, particularly executable content in .reloc; and verify the provenance of installers even when distributed through apparently trusted channels like sponsored ads. Runtime behavioral analysis — rather than static signatures alone — emerges as the necessary discriminator against loaders of this sophistication level.

Why OXLOADER Raises the Bar for Malvertising

The OXLOADER case illustrates a concerning convergence: trusted advertising platforms, legitimate cloud services, and research-lab-grade malware engineering. The campaign's operational cost — Google Ads, verified account, free Storj hosting — is negligible compared to the development time implied by multi-layer obfuscation, self-modifying stubs, five anti-VM checks, and .reloc abuse. This cost/R&D imbalance indicates an actor investing in reusable platforms, not disposable payloads.

The lesson for enterprise defenses is that the software trust chain can no longer anchor to the apparent source: a verified Google ad, a domain mimicking the official brand, an installer with a familiar wizard UI. Every link is compromised. Detection must shift to behavior, not channel reputation.

"The code obfuscation, anti-VM measures, benign-looking code used to masquerade its binaries, and unique staging techniques reflect deliberate engineering choices to evade analysis" — Elastic Security Labs, via The Hacker News

Information verified against cited sources and current as of publication.

Sources

Sources and references