VEIL#DROP: come Blogger diventa armiere di…

Securonix scopre VEIL#DROP: catena malware multi-stadio che sfrutta Google Blogger per consegnare fileless il PureLogs Stealer, bypassando difese reputation-based

Il primo luglio 2026 il threat research team di Securonix ha reso pubblica la campagna VEIL#DROP, una delivery chain che non viola piattaforme cloud ma le abusa con precisione chirurgica. Il meccanismo non colpisce vulnerabilità zero-day: si serve di Google Blogger come stager legittimo, genera URL polimorfi al runtime e monta una scala di LOLBin Microsoft-firmati per garantire esecuzione fileless anche quando gli endpoint bloccano i percorsi diretti. Il payload finale è PureLogs Stealer, infostealer .NET che opera interamente in memory.

Punti chiave

VEIL#DROP usa l'indirizzo htlwub00klocate.blogspot[.]com per ospitare payload PowerShell, sfruttando la reputation di Google per eludere filtri network-based.
Il loader genera URL dinamici inserendo un numero casuale di slash ('/') per bypassare signature statiche, con mutazione runtime che sostituisce placeholder con stringhe casuali.
L'esecuzione fileless avviene tramite reflective .NET loading, senza artefatti su disco; il fallback cicla tra quattro LOLBin firmati Microsoft (regsvcs.exe, installutil.exe, msbuild.exe, aspnet_compiler.exe) in modalità a cascata.
Il payload finale identificato è PureLogs Stealer, consegnato in-memory dopo che il loader ha terminato wscript.exe e cancellato il file JavaScript iniziale.

La catena che inizia da un .js con doppia estensione

L'infezione prende il via da un file JavaScript con doppia estensione mascherato da documento — il report di Securonix cita transcript.pdf.js come esempio documentato. Il file si attiva tramite Windows Script Host e innesca PowerShell con execution policy bypassed. Da qui il loader contatta Blogger all'indirizzo htlwub00klocate.blogspot[.]com per recuperare il payload successivo. L'uso di infrastruttura Google non è aneddotico: è il fulcro della strategia evasiva. Le difese reputation-based, che concedono trust implicito a domini del primissimo livello come blogspot.com, diventano in questo scenario un accecatore.

"The infection chain begins with a deceptively named JavaScript file masquerading as a document (e.g., transcript.pdf.js), which executes through Windows Script Host and launches PowerShell with execution policy bypasses enabled" — Akshay Gaikwad, Shikha Sangwan, Aaron Beardslee (Securonix), via The Hacker News

Il meccanismo di delivery non si limita a un singolo URL statico. Securonix ha documentato che il malware costruisce dinamicamente la destinazione dello stager secondario, inserendo un numero variabile di caratteri '/' nella stringa URL. Questo polimorfismo strutturale, combinato con la sostituzione runtime di placeholder con stringhe casuali, rende inefficaci gli indicatori di compromissione statici e le regole di blocco URL basate su pattern fissi.

Reflective loading e il paradosso della memoria senza artefatti

Una volta recuperato il payload, VEIL#DROP non scrive su disco. L'assembly .NET viene eseguito tramite reflective code loading, una tecnica che carica il binario direttamente dalla memoria senza passare per il filesystem. Questo approccio fileless, confermato da entrambe le fonti primarie, annulla gran parte della superficie di rilevamento tradizionale: niente hash file da correlare, niente firme su disco da scannerizzare, niente artefatti di scrittura per gli strumenti forensi post-hoc.

Il payload così caricato è PureLogs Stealer, infostealer .NET noto nel panorama criminale. Secondo quanto documentato da Securonix via Infosecurity Magazine, gli operatori dietro malware di questo tipo vendono tipicamente le credenziali raccolte attraverso marketplace underground, consentendo ad altri threat actor di acquistare accesso a account e ambienti compromessi. Il dossier non specifica la natura esatta dei dati di interesse per questa specifica campagna, né la portata geografica o il numero di vittime confermate.

Il cascading LOLBin: quando l'allowlisting diventa boomerang

L'elemento più distintivo di VEIL#DROP è il modello di esecuzione a cascata tramite LOLBin. Invece di affidarsi a un singolo binario firmato Microsoft, il loader cicla attraverso quattro eseguibili alternativi: regsvcs.exe, installutil.exe, msbuild.exe, aspnet_compiler.exe. L'esecuzione segue una logica di fallback: tenta ogni metodo finché uno non ha successo. Questo meccanismo, che Securonix ha denominato "cascading model", trasforma l'approccio tradizionale Living-off-the-Land in una catena di ridondanza automatizzata.

"One of the most notable aspects of the loader is that it does not depend on any single LOLBin. Instead, execution follows a cascading model, attempting each method until one succeeds" — Securonix researchers, via The Hacker News

Le conseguenze per le architetture difensive sono concrete. Le policy di allowlisting che concedono esecuzione a binari Microsoft-firmati — pratica standard in ambienti enterprise controllati — diventano in questo scenario un vettore di esecuzione garantita. Non più un singolo LOLBin da monitorare, ma un'intera batteria di alternativa che rende il controllo perimetrale insufficiente senza layer aggiuntivi di behavioral analytics su PowerShell e runtime .NET.

Cosa fare adesso

Rivedere le policy di accesso a Blogger e piattaforme cloud di authoring pubblico dal perimeter interno: il traffico verso blogspot.com non può più essere considerato implicitamente benigno in ambienti a rischio.
Attivare monitoring comportamentale su PowerShell e CLR (.NET runtime) con focus su reflective assembly loading, bypass di execution policy e pattern di generazione URL dinamici.
Estendere le regole di detection oltre gli IoC statici: le signature URL-based sono inefficaci contro il polimorfismo strutturale di VEIL#DROP; è necessario monitorare il comportamento di generazione runtime.
Mappare l'uso legittimo di LOLBin in ambiente enterprise e implementare controlli applicativi che rilevino sequenze anomale di esecuzione concatenata, non solo singoli processi isolati.

Il confine sottile tra trust e vulnerabilità

VEIL#DROP non dimostra che le infrastrutture cloud siano insicure: dimostra che la loro stessa reputazione è diventata un asset offensivo. Quando un dominio Google riceve trust implicito dai gateway di sicurezza, l'attaccante che lo ospita ha già vinto metà della partita a monte. La sfida per i team difensivi non è più discriminare il male dal bene a livello di infrastruttura, ma ricostruire la catena di esecuzione comportamentale — un compito che le firme statiche non possono sostenere.

Il report di Securonix lascia aperti interrogativi strategici: non è confermato se la campagna sia attribuibile a un gruppo APT noto, non è chiaro se Google abbia rimosso i contenuti malevoli, e non sono stati pubblicati IoC verificabili come hash o regole YARA. Questi limiti rendono il threat hunting proattivo più urgente della semplice applicazione di patch: in assenza di indicatori stabili, la detection deve spostarsi dal perimeter alla memoria, dal file al comportamento.

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

Fonti

Fonti e riferimenti