OXLOADER Drops CastleStealer via Poisoned Google Ads, Researchers Say

A previously undocumented loader, tracked as OXLOADER, is delivering the CastleStealer infostealer through malicious Google Ads, according to researchers at Elastic Security Labs.

The entry point is familiar. Victims searching for legitimate software hit a sponsored ad, follow it to an attacker-controlled landing page, and run a signed-looking installer that drops OXLOADER. The loader then fetches CastleStealer as the second-stage payload.

Elastic attributes the activity, with moderate confidence, to a Russian-speaking actor working for profit. The attribution rests on language artifacts in the tooling and operational tradecraft consistent with established stealer-distribution crews (not a hard fingerprint, so treat it as a working hypothesis).

OXLOADER itself appears purpose-built for the malvertising-to-stealer pipeline. It handles staging, basic anti-analysis, and payload retrieval. It is not, on current evidence, being sold broadly as a commodity loader — the deployments so far map cleanly to a single CastleStealer operation.

CastleStealer is the business end. Like its peers in the post-RedLine, post-Raccoon market, it scrapes browser credentials, session cookies, crypto wallet data, and assorted application secrets, then exfiltrates the lot to operator infrastructure. Stolen cookies in particular continue to be the gift that keeps giving for follow-on intrusions, because they sidestep MFA on already-authenticated sessions.

Why this matters operationally:

• Search-ad abuse remains a high-yield initial access vector, and Google's ad-review controls have not closed it. Defenders relying on user training to spot "the bad link" are losing that fight against sponsored results that outrank the real vendor.
• A fresh loader family means existing EDR signatures and YARA rules may miss the staging step entirely. Detection has to lean on behavior: unsigned or oddly-signed installers spawning from browser download paths, unusual outbound TLS to staging hosts, and child processes touching browser credential stores.

For defenders, the near-term mitigations are unglamorous but effective. Block or sinkhole the indicators Elastic has published. Force enterprise browsers through a managed allowlist for software downloads. Strip ad results at the DNS or proxy layer where feasible. And rotate any session cookies tied to high-value SaaS after suspected stealer activity — password resets alone will not evict an attacker holding a valid token.

No CVE attaches to this one. There is nothing to patch. The vulnerability, as ever in the malvertising lane, is the ad ecosystem itself and the trust users place in the first result on the page.

Elastic's writeup includes hashes, network indicators, and the loader's configuration structure for hunters who want to build detections now.