OXLOADER Malware: Fake Node.js Google Ads Drop CASTLESTEALERv

OXLOADER Malware: How Hackers Used Fake Google Ads to Push a Node.js Fake Installer and Drop CASTLESTEALER

Article Summary

This article covers the OXLOADER malware campaign, a newly documented Windows loader discovered by Elastic Security Labs in June 2026. Threat actors ran fake Google Ads impersonating Node.js installers to target US-based developers. Victims who clicked the sponsored result were silently redirected through an intermediary domain to a batch script hosted on legitimate cloud storage, which then installed OXLOADER, a heavily obfuscated loader designed to evade sandbox detection. OXLOADER's final payload is CASTLESTEALER, a .NET-based infostealer first documented by Huntress, capable of harvesting browser credentials, session cookies, crypto wallet data, and other sensitive information. The article covers the full infection chain, technical deep dives into both malware families, MITRE ATT&CK mapping, indicators of compromise, and defensive recommendations for individuals, developers, and security teams.

Quick Reference: OXLOADER Campaign at a Glance

Attribute	Detail
Threat Name	OXLOADER (loader) / CASTLESTEALER (final payload)
First Documented	June 2026 by Elastic Security Labs
Payload Attribution	CASTLESTEALER attributed by Huntress
Distribution Method	Malicious Google Ads impersonating Node.js
Target Geography	US-based Windows users
Campaign Active	Through April 23, 2026
Google Removal	May 14, 2026
Advertiser Origin	Verified account linked to Ukraine
Loader Language	Native (heavily obfuscated)
Final Payload Language	.NET
Delivery Method	In-memory via DonutLoader (fileless)
Sandbox Evasion Checks	5 (CPU, RAM, display, CIS region, Russian language)
Detection Rate	Low across static AV engines and sandboxes
C2 Infrastructure	52.78.2[.]74, 52.78.77[.]48

The Search That Ended in a Data Breach

Picture a software developer in the United States on a regular Tuesday afternoon. They need to set up Node.js on a fresh machine, so they do what almost anyone would do. They open Google, type "Node.js installer," and click the top result. It looks right. The page looks right. The installer launches. A progress bar moves across the screen. Nothing seems wrong.

Except everything is wrong. In the background, a sophisticated piece of malware has already taken root. It is scanning the machine, checking for signs that it has landed somewhere real and not inside a security researcher's sandbox. It passes all the checks. And then it begins silently harvesting credentials, session cookies, browser passwords, and potentially crypto wallet data, packaging everything and shipping it to an attacker-controlled server before the victim has even finished their coffee.

This is not a hypothetical. This is exactly what happened in a campaign that Elastic Security Labs uncovered and documented in June 2026 when researchers identified an active attack targeting one of their own customers.

The campaign used malicious Google Ads, a technique known as malvertising, to deliver a brand-new and previously undocumented malware loader called OXLOADER. Its purpose was singular: bypass every security tool standing between it and the victim's machine, then silently deploy an infostealer called CASTLESTEALER without leaving a single file on disk.

Malvertising is not new. Threat actors have been abusing paid advertising platforms to deliver malware for years. What makes this campaign different is the quality of the engineering behind OXLOADER. Elastic Security Labs confirmed the loader was operating with remarkably low detection rates across both static antivirus engines and automated sandbox environments. This was not a script-kiddie operation. The people behind OXLOADER built something deliberate, patient, and technically sophisticated.

For organizations that rely on developers searching for tools online every single day, understanding this campaign is not optional. It is a direct warning about how easily trusted platforms can be turned into weapons.

Who Was Behind This? Threat Actor Profile and Campaign Attribution

The malicious Google Ads campaign was registered under a verified advertiser account that Google's own records linked to a name based in Ukraine. The ad was last shown to victims on April 23, 2026, and Google did not fully remove the advertiser and all associated campaigns until May 14, 2026, giving the threat actors nearly three weeks of uninterrupted operation under the radar.

Understanding what "verified advertiser" means on Google Ads is important here. When Google grants advertiser verification, it is essentially vouching that the account holder has passed an identity check. This status builds trust and gives ads higher credibility within the platform. Threat actors have learned to exploit this system in two primary ways: either they create fresh accounts using stolen or fabricated identities and pass through verification, or they purchase already-verified accounts from underground markets where stolen advertising credentials are openly sold.

Late 2025 and early 2026 saw a documented surge in exactly this kind of account abuse. Google's own Threat Analysis Group identified clusters of actors systematically hijacking marketing accounts to run unauthorized campaigns, and underground forums saw growing demand for high-trust advertising accounts with established spending histories because those accounts face less scrutiny during the ad approval process.

The campaign was geo-targeted specifically at US-based victims, which narrows both the intended victim profile and the threat actor's motivations. Developers and engineers represent an especially valuable target because they typically have elevated system privileges on their machines, access to source code repositories, API keys for cloud infrastructure, and credentials that can open doors into corporate networks far beyond their individual workstation.

Perhaps the most telling attribution clue is buried inside OXLOADER's code itself. Before executing its payload, the loader checks whether the infected machine is located in a CIS region or configured to use the Russian language. If either condition is true, OXLOADER terminates without doing anything. This is a well-established operational security practice among Russian-speaking cybercriminal groups. By excluding their own geographic and linguistic region, they reduce the risk of accidentally infecting domestic systems, which would draw attention from Russian law enforcement and disrupt their operations.

Elastic Security Labs assessed the threat actor as financially motivated and Russian-speaking based on this evidence. No specific attribution to a named APT group has been made public, but the TTPs align with known malvertising-as-initial-access operators who have been running similar campaigns targeting developer tools including KeePass, WinSCP, Notepad++, and 7-Zip in the years prior.

The Full Infection Chain, Step by Step

What makes this campaign particularly effective is how many legitimate platforms and trusted behaviors it exploits along the way. Each step of the infection chain is designed to look normal to both the victim and to automated security tools. Here is how the attack unfolds from the first click to full compromise.

Step 1: The Google Search and the Sponsored Ad Click

The attack begins with one of the most natural things a developer can do: searching for software. Node.js is one of the most widely downloaded development tools globally, used by millions of developers to build server-side applications. When someone searches for it, they expect the top result to be the official download. Threat actors knew this and purchased Google Ads targeting keywords around Node.js to place their malicious result directly at the top of the search page, above the organic results.

The ad copy was crafted to mimic legitimate Node.js branding. Nothing about the appearance signaled danger.

Step 2: The Fake Landing Page

Clicking the sponsored result took victims to a landing page at nodejs-preventive[.]info, a domain built to impersonate a legitimate Node.js deployment platform. The page was convincing enough that victims had no reason to suspect they were not in the right place. The URL was the only giveaway, and most users glance at URLs without scrutinizing them closely.

Step 3: The Redirect Through an Intermediary Domain

Rather than delivering the malicious payload directly from the landing page, the threat actor routed traffic through a second domain, app[.]miloyannopoulos[.]com. This intermediary redirect serves a specific technical purpose: it breaks the referrer chain, making it much harder for security tools to connect the suspicious download back to the malicious ad. Google's ad approval crawlers, which check landing pages for malicious content, never see the redirect destination because the redirect happens after the crawl.

Step 4: Batch Script Delivery via Storj

The redirect endpoint sent victims to download a Windows batch script hosted on Storj, a legitimate decentralized cloud storage platform. Attackers deliberately chose Storj for a practice sometimes called reputation laundering. Because Storj is a real, trusted platform, the download URL carries the reputation of that platform rather than any attacker-controlled infrastructure. Security tools that use domain reputation or URL filtering to block malicious downloads see a link from a legitimate cloud service and let it through. The same technique has been observed with GitHub, Discord's CDN, OneDrive, and other widely used services.

There was even a typo in the batch file name. The script was called "BATPackageBulderSetup.bat" rather than "BATPackageBuilderSetup.bat." The misspelling suggests it was created quickly or by someone whose first language is not English, another subtle indicator consistent with the Russian-speaking attribution.

Step 5: The Fake Installation Wizard

Once the batch script ran, it did not immediately trigger any suspicious behavior from the victim's perspective. Instead, it displayed a convincing fake software installation wizard, a graphical window that looked exactly like a normal installer progressing through setup. This was pure social engineering. While the victim watched a progress bar and clicked "Next," the script was silently working in the background.

Step 6: PowerShell Download and UAC Elevation

Behind the fake installer UI, the batch script used PowerShell to download the next-stage executable from the attacker's infrastructure. PowerShell is a legitimate Windows administration tool built into every modern Windows installation, which is exactly why attackers use it so frequently for what security researchers call Living off the Land attacks. Using built-in system tools to deliver malicious payloads makes the activity blend in with normal system behavior. The script then triggered a Windows User Account Control prompt, which appeared to the victim as a routine request from what seemed to be a legitimate installer asking for admin privileges. Many users click "Yes" on UAC prompts reflexively, especially in the middle of what appears to be a normal software installation.

Step 7: OXLOADER Execution

With elevated privileges granted, OXLOADER executed. Elastic Security Labs found two distinct variants of this loader in the campaign. The first variant masqueraded as apimonitor-x64.exe, mimicking API Monitor, a legitimate developer tool. The second, discovered on May 13, 2026, masqueraded as node-v20.7.0-x64.exe, keeping the Node.js lure theme consistent throughout the entire infection chain. Both used the identical loader mechanism underneath their different disguises.

 

OXLOADER Technical Deep Dive: How It Hides From Everything

To understand why OXLOADER is significant, it helps to understand what a malware loader actually is and why threat actors bother building them separately from their final payloads.

A malware loader is a staging tool. Its only job is to get the real malicious payload onto a machine without being detected and then execute it. Think of it as the getaway driver in a heist. The driver is not the one stealing anything, but without the driver, the thief cannot operate. Loaders handle the hard part of bypassing security, gaining access, and handing off execution to the actual payload. This separation means the infostealer, which is the part doing the real damage, never touches disk and never exposes itself to the antivirus scanners checking downloaded files.

OXLOADER was built with evasion as the central engineering priority. Elastic Security Labs confirmed it had no prior public documentation, meaning no antivirus signature existed for it. Its detection rates across both static file scanners and automated sandbox environments were described as remarkably low. Here is how it achieves that.

The Five Anti-Sandbox Checks

Before OXLOADER does anything meaningful, it runs five separate environment checks to confirm it is running on a real machine and not inside the kind of virtual environment that security vendors use to analyze suspicious files.

The first check is unusual. The loader attempts to connect to a deliberately malformed network resource using a Windows API call called WNetAddConnection2W. On a real system, this call fails with a specific error code, ERROR_BAD_NAME (0x43), because the resource name is intentionally invalid. But many sandbox environments hook or emulate this API call and return a success result instead. OXLOADER reads the error code directly from a low-level Windows memory structure, bypassing the normal API layer entirely. If the error code is anything other than 0x43, OXLOADER knows it is in an emulated environment and stops running.

The second check counts CPU cores. The loader requires at least three CPU cores to continue. Most sandbox environments are provisioned with only one or two cores to conserve computing resources. A real developer workstation will almost always have three or more.

The third check reads the amount of physical RAM installed via the GlobalMemoryStatusEx API. The loader requires at least 3 GB. Sandboxes running lightweight analysis VMs frequently have less than this.

The fourth check queries the display refresh rate through Windows Management Instrumentation. The loader requires the refresh rate to be above 20 Hz. Virtual machines running in headless analysis environments often have no real display adapter and report either zero or a very low value.

The fifth check combines geographic and linguistic filtering. OXLOADER queries the system for CIS region geographic identifiers and checks whether the Russian language is configured. If either is true, execution stops. As noted earlier, this is characteristic of Russian-speaking threat actors protecting their own infrastructure from accidental self-infection.

Only a machine that passes all five checks receives the payload.

Obfuscation That Breaks Analysis Tools

Even if a researcher gets a copy of the OXLOADER binary, analyzing it is deliberately made difficult. The loader uses multiple layers of code obfuscation including control-flow flattening, opaque predicates, and mixed Boolean-Arithmetic transformations. These techniques do not change what the code does, but they make the code extremely hard to read and trace. Standard binary analysis tools that security researchers use to reverse engineer malware produce confusing, nearly unusable output when applied to OXLOADER.

The .reloc Section Trick

One of the most technically interesting aspects of OXLOADER is where it hides its shellcode. In a standard Windows executable file, there is a section called .reloc that contains relocation information used by the operating system to load the program into memory correctly. Legitimate compilers put address-fixup data here, never executable instructions. Security scanners that analyze PE files know this and typically do not scrutinize the .reloc section for malicious code.

OXLOADER hides its shellcode inside the .reloc section precisely because no one is looking there. The loader copies a legitimate system DLL, injects a new section containing the shellcode into the copy, and then uses that modified version to execute its payload. Elastic Security Labs called this a static-analysis red flag that most engines simply are not catching in practice.

Self-Modifying Decryption and DonutLoader

OXLOADER's main body is encrypted and only decrypts itself at runtime using a self-modifying decryption routine. Rather than storing the decryption function in the binary permanently, the loader patches the decryption stub into memory immediately before it runs, then jumps to it. This process repeats several times as successive layers of the malware decrypt themselves. By the time the full malicious code is running, it exists only in memory, with no decrypted version ever written to disk.

Once the environment checks pass and decryption completes, the payload is decompressed using aPLib and then handed to DonutLoader's RunPE() function. DonutLoader is an open-source shellcode generation framework that was originally created for legitimate red team and penetration testing purposes. It takes a compiled .NET assembly or other executable, wraps it in position-independent shellcode, and injects it directly into memory without touching the file system. This is the final step that makes OXLOADER effectively fileless. CASTLESTEALER arrives on the victim's machine purely in memory, with no executable artifact on disk for forensic tools to find after the fact.

CASTLESTEALER: The Payload That Does the Real Damage

Once OXLOADER completes its environment checks and hands off execution, CASTLESTEALER takes over. This is a .NET-based infostealer first documented by Huntress, who attributed it based on a distinctive AES encryption key found between 0xDEADBEEF markers in its C2 communication code, a signature that matched a previously analyzed sample in their threat database.

The choice of .NET as the development language tells you something about the threat actor's priorities. .NET is faster to develop in than lower-level languages, has rich built-in libraries for network communication and data handling, and can be heavily obfuscated using tools like ConfuserEx to hinder reverse engineering. The resulting binary is harder to analyze statically while being relatively easy to build and update. This suggests an operator who is iterating quickly and prioritizing operational speed.

What CASTLESTEALER Targets

Based on Huntress's research into this malware family and the broader context of how similar .NET infostealers operate, CASTLESTEALER targets the categories of data that are most valuable on underground markets and most dangerous to the organizations victims work for.

Browser credentials are the most immediate target. Modern browsers store saved usernames and passwords in encrypted databases on disk. Infostealers know exactly where these databases live for Chrome, Firefox, Edge, Brave, and Opera, and they know how to extract the encryption keys Windows stores nearby. Beyond passwords, CASTLESTEALER also targets session cookies. These are the tokens that keep you logged into websites after you have already authenticated. An attacker who steals your session cookie does not need your password at all. They do not need to bypass your two-factor authentication. They simply import the cookie into their browser and the website treats them as you. Given that developers routinely have browser sessions open to GitHub, cloud provider consoles, CI/CD platforms, internal dashboards, and SaaS tools, the session cookie theft angle is arguably more dangerous than the password theft.

The malware also targets crypto wallet data, which has become standard in modern infostealers because it provides a direct, fast path to liquid assets. Discord tokens, Telegram session files, and browser autofill data round out the typical target profile for a stealer built on this architecture.

For enterprise victims specifically, the most dangerous potential exposure is API keys and cloud service credentials stored in browser password managers or accessible through saved form data. A developer whose Google Cloud or AWS credentials are stolen is not just a personal victim. They are a potential entry point into their entire organization's infrastructure.

C2 Infrastructure

CASTLESTEALER communicates with two command-and-control IP addresses: 52.78.2[.]74 and 52.78.77[.]48. Both are hosted in the AWS Seoul region, a common choice for threat actors because the infrastructure is reliable, easy to spin up with a stolen credit card or anonymous account, and geographically distant from the primary victim region of the United States, which can complicate incident response and attribution.

The use of AES encryption for C2 communications makes traffic analysis harder. The stolen data does not travel in plaintext that a network monitoring tool could read and flag.

Because CASTLESTEALER is delivered entirely in memory by DonutLoader, post-infection forensic investigation is significantly more difficult. There is no dropped file to hash and search for across the environment, no obvious persistence mechanism in the standard locations that automated scanners check. The attacker exfiltrates what they need and moves on, leaving minimal traces.

Why Google Ads Malvertising is Growing So Fast in 2026

The OXLOADER campaign did not emerge in a vacuum. It is part of a broad and accelerating trend that has made Google Ads one of the most abused distribution channels for malware targeting technical users.

Google processes over 8 billion searches per day and controls roughly 89.85% of global search traffic as of early 2026. The platform generated over $80 billion in ad revenue in 2025 alone. This scale is exactly the problem. When billions of searches happen daily and millions of ads compete for placement, automated approval systems cannot manually review every single ad and its destination. Threat actors have figured out how to exploit the gaps in that automation.

The core technique is straightforward. Malicious actors purchase Google Ads using verified accounts or freshly created ones with stolen identities. The ad itself passes Google's automated scanning because the landing page it points to initially appears clean. The redirect to the actual malicious content happens after Google has crawled and approved the ad, typically through a server-side redirect that fires only under specific conditions, like when the visitor comes from Google rather than a direct URL access.

Verified advertiser accounts have become a commodity on underground markets. Security researchers have documented how stolen or aged advertising accounts with established histories and good compliance records are actively bought and sold in criminal forums because they face less initial scrutiny and can run campaigns longer before being flagged.

Industry data shows that more than one in five ad impressions globally is now classified as invalid or unsafe. The problem has grown well beyond individual campaigns into what some researchers describe as a self-sustaining ecosystem. Microsoft Threat Intelligence documented a large-scale malvertising campaign in 2025 that compromised nearly one million devices globally using ads that redirected to GitHub-hosted malware. Separate campaigns in 2024 and 2025 targeted WinSCP, PuTTY, KeePass, OBS Studio, and AI tools like Luma AI and Canva Dream Lab.

Developer tools are specifically valuable as lures because developers search for software frequently, often in professional contexts where they have elevated system permissions and access to sensitive organizational infrastructure. A developer clicking a fake Node.js ad is a far more valuable victim than a random consumer clicking a fake coupon, and the threat actors building OXLOADER clearly understood this.

Who is Most at Risk

The OXLOADER campaign was geo-targeted at US-based Windows users, but the risk profile extends well beyond that narrow description.

The primary victim category is developers, DevOps engineers, and IT professionals who regularly search for and install development tools. Node.js is used across the technology industry, from startups to Fortune 500 companies, from individual freelancers to large engineering teams. Anyone who uses it and trusts sponsored search results when looking for official downloads sits in this threat actor's crosshairs.

Industries with heavy developer populations carry the highest organizational risk. Technology companies and software agencies are the obvious candidates, but financial services firms with large engineering teams, healthcare organizations building internal software, and any company that has developers working on cloud infrastructure all carry significant exposure.

Remote workers and BYOD (Bring Your Own Device) environments amplify the risk considerably. When a developer installs software on a personal machine that also has corporate credentials saved in the browser, or when they work on a laptop that connects to corporate VPN, a single click on a fake ad can become a corporate security incident. The stolen credentials and session cookies from one infected developer machine can open doors into source code repositories, cloud environments, internal tools, and HR systems.

Small and medium businesses face a particularly challenging version of this threat. Enterprise organizations typically have dedicated security teams monitoring for behavioral anomalies and endpoint detection tools configured in active prevention mode. Smaller organizations often rely on basic antivirus software, which, as OXLOADER demonstrated, is not sufficient to catch this category of threat.

How Elastic Security Labs Found It and What They Saw

The campaign might have run much longer without detection if Elastic Security Labs had not been monitoring one of its own customers when the attack landed. What caught the attention of researchers was not a signature match on OXLOADER itself. The loader had no prior public documentation and no existing signatures. What triggered alerts was behavioral anomalies.

Elastic Defend, operating on the compromised endpoint, fired multiple behavioral detection rules during the attack chain execution. One of the most significant alerts flagged the loading of the Microsoft Common Language Runtime (CLR) from suspicious memory, which is consistent with a .NET-based payload being executed in-memory. This was the behavioral fingerprint of CASTLESTEALER running without ever touching disk, and it was exactly the kind of signal that traditional signature-based antivirus would never produce because there was no file to scan.

This is the critical distinction that this campaign illustrates for security teams. Static antivirus engines look at files and compare them against known signatures. OXLOADER had no known signature. Sandbox environments detonate files and watch for obvious malicious behavior. OXLOADER spent most of its execution time actively checking for sandbox conditions and terminating if any were detected. Neither approach was effective.

Behavioral detection, which watches what a running process actually does rather than what it looks like, was what caught the attack. The Elastic Defend agent observed the suspicious execution chain: batch script running, PowerShell firing, CLR loading from anomalous memory regions, followed by network communication to unknown IP addresses. That pattern of behavior, regardless of what any individual file looked like, was enough to trigger the alert.

It is also worth noting that the endpoint agent in this case was configured to detect-only mode rather than active prevention mode. This is an important operational choice for security teams. In detect-only mode, threats are logged and alerted but not blocked. In active prevention mode, suspicious behavior is interrupted before it completes. The Elastic report highlights this distinction directly, noting that Elastic Defend stops the entire attack chain when operating in prevention mode.

YARA and behavioral detection signatures for this threat family are available through Elastic Security Labs' published research, which security teams can use to hunt for indicators in their environments.

MITRE ATT&CK Mapping

ATT&CK ID	Technique	Application in This Campaign
T1583.001	Acquire Infrastructure: Domains	nodejs-preventive[.]info landing page registered for impersonation
T1566.002	Phishing: Spearphishing Link	Malicious sponsored Google Ad link targeting Node.js searchers
T1036.005	Masquerading: Match Legitimate Name or Location	node-v20.7.0-x64.exe and apimonitor-x64.exe filenames
T1059.001	Command and Scripting: PowerShell	PowerShell download cradle pulling OXLOADER from attacker infrastructure
T1059.003	Command and Scripting: Windows Command Shell	Batch script (BATPackageBulderSetup.bat) executing infection chain
T1548.002	Abuse Elevation Control: Bypass User Account Control	UAC prompt triggered during fake installer UI phase
T1027	Obfuscated Files or Information	Control-flow flattening, opaque predicates, MBA obfuscation, .reloc section abuse
T1055	Process Injection	In-memory payload injection via DonutLoader RunPE()
T1497.001	Virtualization/Sandbox Evasion: System Checks	Five-check environment fingerprinting before payload execution
T1497.003	Virtualization/Sandbox Evasion: Time-Based Evasion	Delayed execution contingent on environment check results
T1614.001	System Location Discovery	CIS GEOID and Russian LANGID checks for geographic exclusion
T1555.003	Credentials from Password Stores: Credentials from Web Browsers	CASTLESTEALER browser credential and cookie harvesting
T1539	Steal Web Session Cookie	CASTLESTEALER session cookie theft for MFA bypass
T1071.001	Application Layer Protocol: Web	AES-encrypted C2 communication to 52.78.2[.]74 and 52.78.77[.]48
T1041	Exfiltration Over C2 Channel	Stolen data transmitted to CASTLESTEALER C2 infrastructure

Indicators of Compromise (Full IoC Table)

All indicators below are defanged. Before using them in production environments, re-fang by replacing [.] with a literal period. These indicators are suitable for import into MISP, VirusTotal, or your SIEM.

Type	Indicator (Defanged)	Description
Domain	nodejs-preventive[.]info	Malvertising landing page impersonating Node.js
Domain	app[.]miloyannopoulos[.]com	Malvertising redirector domain
URL	link[.]storjshare[.]io/raw/jv5uebuqwzfpmtahj34q753ptykq/node/BATPackageBulderSetup.bat	Storj-hosted malicious batch script
URL	link[.]storjshare[.]io/raw/jvsmdybqmvwep2oawbobp6ub7aza/node/node-v24.15.0-x64-86.exe	Storj-hosted OXLOADER binary
SHA-256	fdfc9780b3c67acac3ca1acfdc9a890dcfee2d5d58fbcef8eac3fc80aa1cf2b3	OXLOADER batch launcher (Bild0erSetup.bat, variant 1)
SHA-256	de2b7c7a9e7c006e7ca990e77e7dff9b8b73aa9e9e24b98a7f88d3b3fff7c2b3	OXLOADER batch launcher (Bild0erSetup.bat, variant 2)
SHA-256	ca99a9fd118f8a99a9bc99ca9bb9cdfc7cd3b3db9fbcd3fecd3fecd7fe9f0f6f	apimonitor-x64.exe (OXLOADER, variant 1)
SHA-256	ce8f8dcb3ca9e9190fd7818f1e7ab87b9fc8f8e7fc88fee8fcc8f8e7fc88fee8	node-v20.7.0-x64.exe (OXLOADER, variant 2)
SHA-256	9a67a98fdc9e8e6e7886e9c0e8c668b87c0b66e8f07c8e1f7e89f7c8ca7e8cc8	CASTLESTEALER payload
IPv4	52.78.2[.]74	CASTLESTEALER C2 (AWS Seoul)
IPv4	52.78.77[.]48	CASTLESTEALER C2 (AWS Seoul)

To add these to your blocklist: import the domain and IP indicators into your DNS filtering solution, firewall, or SIEM. Add the SHA-256 hashes to your endpoint protection platform's custom block list. If you are using an EDR solution, create alerts for any process attempting to communicate with the two C2 IP addresses.

Defensive Recommendations

No single control stops this attack. OXLOADER was specifically engineered to bypass the controls that most organizations rely on first. The following layered recommendations address each stage of the attack chain.

For Individual Developers and End Users

The most effective single defense against malvertising is habit change. Never click sponsored search results when downloading software. Always navigate directly to the official vendor website by typing it into the address bar or using a bookmarked URL you have previously verified. For Node.js specifically, the only legitimate download source is nodejs.org.

Before running any installer, verify the SHA-256 hash of the downloaded file against the hash published on the official vendor website. Both Windows PowerShell and macOS Terminal can compute file hashes natively. This single step would have caught the fake Node.js installer used in this campaign.

Enable Windows SmartScreen and keep UAC at the highest setting. Be suspicious of any UAC prompt that appears during a software installation from an unfamiliar source. Legitimate software from major vendors rarely requires administrator privileges just to begin installation.

Use a dedicated password manager rather than relying on browser-saved passwords. Browser-saved credentials are a primary target for infostealers including CASTLESTEALER. Regularly audit and rotate credentials for high-value accounts, particularly cloud provider consoles, GitHub, and any single-sign-on service.

For Security Teams

The OXLOADER campaign is a direct argument for moving endpoint agents from detect-only mode to active prevention mode. Detection without prevention means the attack completes before anyone acts on the alert. As Elastic Security Labs specifically noted, Elastic Defend running in prevention mode stops this attack chain entirely.

Deploy behavioral endpoint detection and response capabilities rather than relying solely on signature-based antivirus. The entire OXLOADER campaign was built to defeat signature detection. Behavioral EDR, which watches for suspicious patterns of activity, is what actually caught this attack.

Hunt for .reloc section anomalies in PE files on your endpoints. Legitimate toolchains do not emit executable code into the .reloc section. Any PE binary with executable content in .reloc is worth immediate investigation. Add detection rules that alert on PowerShell invoking web downloads from user-writable directories, specifically patterns involving Invoke-WebRequest or Invoke-Expression pointing to external domains.

Monitor for DonutLoader behavioral patterns, specifically .NET CLR loading from memory regions that are not backed by files on disk. This is the behavioral fingerprint that Elastic Defend caught and it should be detectable in any modern EDR platform.

Feed all IoCs from this campaign into your cyber threat intelligence platform and ensure they are blocked at the DNS and firewall layers. Conduct a retrospective hunt across your SIEM logs using the domain names, IP addresses, and file hashes listed in the IoC table above to check for any historical exposure.

If your organization uses dark web monitoring, configure it to alert on any developer credentials from your domains appearing in stealer logs on underground markets. CASTLESTEALER data ends up packaged into logs that are sold within hours of infection.

For IT Administrators

Implement DNS filtering using solutions like Cisco Umbrella, Cloudflare Gateway, or NextDNS to block connections to known malvertising domains and newly registered domains that match patterns used in these campaigns. Apply the defanged domains from the IoC table above as block entries.

Restrict PowerShell execution policy to allow only signed scripts in production environments. Most developers can work with this restriction in place and the control eliminates a massive attack surface. Enforce application whitelisting through Windows Defender Application Control or AppLocker to prevent unapproved executables from running, especially from temporary directories and user-writable paths where malware loaders typically stage.

Block execution of files from %TEMP%, %APPDATA%, and other user-writable locations unless there is a specific business need. The OXLOADER batch script and its downloaded payload almost certainly staged in one of these directories during execution. Create a formal software procurement policy that requires all software installations to go through an approved channel rather than individual downloads from the internet.

Perform regular attack surface management assessments to identify which systems in your environment have developer tools installed, which users have administrator privileges, and where browser-saved credentials represent organizational risk if a single workstation is compromised.

For Organizations Concerned About Brand Impersonation

If your organization publishes software that could be impersonated in a malvertising campaign, monitor Google Ads Transparency Center regularly for ads using your product name or branding. Google provides a mechanism for trademark holders to report ads that misuse their intellectual property. Consider registering your brand terms as Google Ads trademarks to receive automated alerts.

Conclusion: Trust Is the Attack Surface

The OXLOADER campaign is not just a story about clever malware. It is a story about how thoroughly threat actors have learned to exploit the things we trust most. Google Search has an 89.85% share of global search traffic. We trust it to show us what we are looking for. Cloud platforms like Storj host legitimate data for millions of users. We trust downloads from them. Software installation wizards follow a familiar pattern. We trust the UI.

OXLOADER's operators weaponized all three of those trusted experiences simultaneously. They embedded their attack inside the most natural thing a developer can do, and they built the malware behind it with the kind of engineering rigor that keeps it invisible to the security tools that most organizations depend on.

CASTLESTEALER's memory-only delivery represents an escalation in the sophistication of infostealer operations. The absence of disk artifacts is not just a technical detail. It is a deliberate choice to make detection harder, forensic investigation harder, and remediation more expensive. When stolen credentials and session cookies from infected developer workstations reach underground markets, they do not stay there long. They get used, and the downstream consequences can be severe.

The specific Google Ads campaign behind this incident has been shut down. But the threat actor has demonstrated a working model. They know which victim profiles are valuable. They know how to abuse ad platforms to reach those victims. They know how to build a loader that defeats conventional detection. The likelihood that this campaign remains a one-time operation is low.

Organizations that respond to this incident by only blocking the specific IoCs are treating the symptom rather than the cause. The lasting response is behavioral: move endpoint agents to active prevention mode, deploy proper extended detection and response capabilities, enforce software procurement policies, and train developers to recognize the risks of sponsored search results. If you are unsure where your organization stands against this category of threat, a cyber resilience assessment or gap assessment is a practical starting point.

The developers who were targeted in this campaign did nothing wrong. They searched for a tool they needed and clicked what looked like the right result. That is the reality threat actors are exploiting, and it is the reality that security strategy in 2026 has to be built around.

Official References

1. Elastic Security Labs, "OXLOADER: new loader evading detection to drop infostealer," June 19, 2026
2. ThreatLocker Blog, "Malvertising emerges as growing access point for cybercriminals," March 2026 
3. StatCounter, Global Search Engine Market Share, March 2026