OXLOADER: Google Ads malevoli congiano…

Elastic scopre OXLOADER, nuovo loader che sfrutta annunci Google Ads per distribuire CastleStealer con tassi di rilevamento prossimi allo zero grazie a offuscamento

Elastic Security Labs ha scoperto e documentato OXLOADER, un nuovo malware loader Windows precedentemente non noto, distribuito tramite annunci Google Ads malevoli che impersonano il download di Node.js. La campagna, rivelata il 19 giugno 2026, consegna l'infostealer CastleStealer con tassi di rilevamento estremamente bassi su engine statici e sandbox, grazie a un'ingegneria di evasione che i ricercatori giudicano deliberata e multi-layer. L'abuso di una piattaforma pubblicitaria "trusted" per distribuire malware sofisticato rappresenta l'ultima evoluzione di una minaccia in cui il basso costo operativo della campagna si scontra con un investimento in R&D malware che sfida le difese tradizionali.

Punti chiave

OXLOADER è un nuovo loader Windows, precedentemente non documentato pubblicamente, scoperto da Elastic Security Labs in una campagna attiva contro un loro cliente.
La distribuzione avviene tramite annunci Google Ads verificati che impersonano Node.js, con query target come "lts version of node.js", reindirizzando a script batch ospitati su Storj.
Il loader impiega quattro tecniche di offuscamento layered (control-flow flattening, mixed Boolean-Arithmetic, opaque predicates, function chunking) e cinque check anti-VM/sandbox per eludere l'analisi.
L'esecuzione inizia durante la fase CRT initializer, con staging shellcode anomalo nella sezione .reloc — una caratteristica che toolchain legittime non producono — seguito da in-memory execution via DonutLoader.

Google Ads verificati come canale di delivery: l'account ВОЛОДИМИР ТЕРЕЩЕНКО

L'ingegneria sociale della campagna si appoggia sulla fiducia che gli utenti ripongono nei risultati sponsorizzati di Google. Secondo la ricerca di Elastic, citata da The Hacker News, gli annunci malevoli targettizzano ricerche specifiche come "lts version of node.js" e appaiono sotto il nome di un account advertiser verificato: "ВОЛОДИМИР ТЕРЕЩЕНКО", con apparente localizzazione in Ucraina. Questo dettaglio è significativo: la verifica dell'account, che conferisce legitimazione visiva, non ha impedito l'uso malevolo fino alla rimozione avvenuta il 14 maggio 2026, secondo le timeline raccolte da Cyber Security News. L'ultimo annuncio risulta datato 23 aprile 2026.

La catena di reindirizzamento è articolata: dall'annuncio si atterra su node-js[.]prentiva99[.]info, poi tramite app[.]miloyannopoulos[.]com si raggiunge uno script batch ospitato su link[.]storjshare[.]io. L'uso di Storj, servizio di cloud storage decentralizzato legittimo, serve a evadere i filtri reputation-based sui domini, come documenta Elastic. Il batch presenta una finta interfaccia di installazione wizard mentre, in background, PowerShell scarica silenziosamente OXLOADER con il parametro -Verb RunAs per sollevare il prompt UAC. Questo design riflette una consapevolezza del comportamento utente: la routine di installazione familiare disarma la cautela, mentre l'elevazione privilegi è ottenuta tramite pattern legittimi di Windows.

Rimane non confermato se l'account Google sia controllato direttamente dal threat actor, rappresenti un'identità acquistata o un account frontale. Il dossier non specifica in che modo l'identità ucraina apparente sia stata verificata da Google, né se corrisponda a un'entità reale.

Offuscamento a quattro strati: quando il loader diventa piattaforma di evasione

OXLOADER non è un semplice dropper. I ricercatori di Elastic descrivono un sistema di offuscamento stratificato che rompe la detection automatica dei boundary funzionali in strumenti come IDA Pro. Le quattro tecniche identificate sono: control-flow flattening (CFF), che appiattisce il grafo di esecuzione in un unico dispatcher; mixed Boolean-Arithmetic (MBA), che sostituisce operazioni logiche con espressioni algebriche equivalenti ma opache; opaque predicates, condizioni sempre vere o false ma costruite per apparire dipendenti da input; e function chunking, che spezza funzioni in regioni non contigue di memoria.

La decrittazione avviene tramite stub auto-modificanti con rolling-XOR: il plaintext byte decrittato viene aggiunto alla chiave per l'iterazione successiva, ripetuto tre volte su regioni diverse del binario. La prima regione decrittata misura 28.233 byte. Le stringhe sono ulteriormente offuscate con una funzione che risolve dinamicamente gli import tramite API hashing Adler-32 e decrittazione con costante hardcoded 0x33FDA. Questo livello di complessità, come notano Daniel Stepanic e Jia Yu Chan di Elastic Security Labs, "riflette scelte di ingegneria deliberatamente orientate all'evasione dell'analisi".

La risoluzione dinamica degli import e l'auto-modificazione rendono inoltre inefficace l'analisi statica pura: il codice eseguibile emerge solo in memoria, durante l'esecuzione, e il footprint rilevabile prima del runtime si riduce drasticamente.

Anti-VM a cinque check e l'anomalia del .reloc abuse

OXLOADER implementa cinque controlli anti-VM e anti-sandbox, documentati in dettaglio da Elastic: una chiamata a WNetAddConnection2W con risorsa malformata (*72s@1s) che verifica il valore LastErrorValue=ERROR_BAD_NAME(0x43) tramite il TEB; verifica che il conteggio CPU sia ≥3; RAM ≥3GB; refresh rate display ≥20Hz via WMI Win32_VideoController; e esclusione GEOID della regione CIS con lingua russa (LANGID 0x419). Questi ultimi due check supportano l'ipotesi, formulata cautamente dai ricercatori, di un attore russofono e finanziariamente motivato.

La tecnica di staging più insolita è l'abuso della sezione .reloc. OXLOADER copia dui70.dll in un file .ocx con nome random, crea una sezione .xtext con permessi RWX, e vi copia lo shellcode dalla sezione

L'esecuzione inizia durante la fase CRT initializer, prima di qualsiasi codice utente, hijackando un entry della tabella C++ initializer. Questo posizionamento precoce garantisce che il payload sia attivo prima che molti hook di security product siano installati.

Da OXLOADER a CastleStealer: la catena in-memory

Il payload finale, CastleStealer, viene eseguito interamente in memoria tramite DonutLoader, strumento open-source. La comunicazione con il C2 è cifrata con AES. CastleStealer è un infostealer .NET già documentato in precedenti campagne, inclusa quella BackgroundFix attribuita a GrayBravo, dove era distribuito tramite CastleLoader. In questa campagna, OXLOADER funge da vettore indipendente, con meccanismo di delivery e ingegneria distinti.

Elastic Security Labs ha identificato una variante secondaria di OXLOADER, scoperta il 13 maggio 2026, mascherata da installer Node.js (node-v20.7.0-x64.exe) invece che da API Monitor, ma con meccanismo identico. Questa variabilità nel lure suggerisce flessibilità operativa e test A/B sul tasso di conversione degli utenti.

Il tasso di rilevamento è stato descritto da multiple fonti come "low detection rates across static engines and sandbox detonations" (Elastic), "low detection rates across static engines and detonation runs" (The Hacker News), e "remarkably low detection rates" (Cyber Security News). L'investimento in offuscamento, secondo i ricercatori, "sta pagando": OXLOADER opera in una finestra di invisibilità prima di essere identificato e "hunted down".

Cosa fare adesso

La natura della minaccia richiede un riposizionamento delle difese oltre la firma statica. Elastic Defend ha rilevato comportamento malevolo con regole behavioral multiple, inclusa "Microsoft Common Language Runtime Loaded from Suspicious Memory". Questo indicatore — il caricamento del CLR da memoria non standard — è un pattern di rilevamento applicabile anche ad altre infrastrutture.

Le raccomandazioni prioritarie, desumibili dalla documentazione tecnica, sono: monitorare l'esecuzione di PowerShell con -Verb RunAs in contesti di installazione software; analizzare behavioralmente il caricamento di runtime .NET da regioni di memoria sospette; ispezionare sezioni PE anomale, in particolare contenuto eseguibile in .reloc; e verificare la provenienza degli installer anche quando distribuiti tramite canali apparentemente trusted come annunci sponsorizzati. L'analisi del comportamento runtime — piuttosto che la sola firma statica — emerge come discriminante necessario contro loader di questo livello di sofisticazione.

Perché OXLOADER alza l'asticella per la malvertising

Il caso OXLOADER illustra una convergenza preoccupante: piattaforme pubblicitarie trusted, servizi cloud legittimi, e ingegneria malware da laboratorio di ricerca. Il costo operativo della campagna — Google Ads, account verificato, hosting Storj gratuito — è irrisorio rispetto al tempo di sviluppo implicato dal multi-layer offuscamento, dagli auto-modifying stub, dai cinque check anti-VM e dall'abuse della .reloc. Questo sbilanciamento costo/R&D indica un attore che investe in piattaforme riutilizzabili, non in payload usa-e-getta.

La lezione, per le difese enterprise, è che la trust chain del software non può più ancorarsi alla fonte apparente: un annuncio Google verificato, un dominio che imita il brand ufficiale, un installer con firma wizard familiare. Ogni anello è compromesso. La rilevazione deve spostarsi sul comportamento, non sulla reputazione del canale.

"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

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti