Finto PDF e server di Google: così la campagna VeilDrop usa il fileless per rubare le tue password

🛡️ Executive Summary

• VeilDrop distribuisce file JavaScript mascherati da documenti per avviare una catena PowerShell interamente in memoria.
• Gli stage successivi vengono scaricati da pagine Blogspot, sfruttando l’infrastruttura trusted di Google per ridurre il rilevamento.
• Il payload finale è PureLog Stealer, capace di rubare credenziali browser, cookie, autofill, cronologia e dati di wallet crypto.

La campagna VeilDrop mostra una nuova evoluzione delle tecniche fileless usate per distribuire infostealer su sistemi Windows. Gli attaccanti combinano file JavaScript camuffati da documenti, loader PowerShell, pagine Blogspot controllate e caricamento riflessivo di assembly .NET per portare in esecuzione PureLog Stealer senza depositare payload eseguibili tradizionali su disco. L’uso di Blogspot, piattaforma appartenente all’ecosistema Google, permette di sfruttare un dominio ad alta reputazione e rende più difficile il blocco tramite liste statiche di indicatori malevoli. La catena include offuscamento XOR, generazione dinamica di URL, utility LOLBIN firmate da Microsoft e meccanismi di fallback pensati per mantenere l’esecuzione anche in ambienti con controlli applicativi. L’obiettivo finale è il furto di dati sensibili dai browser, dalle sessioni web e dai wallet di criptovalute, con una catena progettata per ridurre al minimo gli artefatti forensi.

File JavaScript mascherati avviano l’infezione

L’infezione parte da file JavaScript distribuiti tramite siti compromessi e nominati in modo da apparire come documenti legittimi, ad esempio transcript.pdf.js. Il trucco sfrutta una configurazione ancora molto diffusa in Windows, dove l’impostazione HideFileExt può nascondere le estensioni dei file conosciuti e far apparire il payload come un normale PDF. Quando l’utente fa doppio clic, il sistema avvia il file con Windows Script Host e il processo wscript.exe genera powershell.exe con parametri utili a bypassare la policy di esecuzione. Il JavaScript iniziale contiene poca logica dannosa e funziona soprattutto come launcher, riducendo la superficie di rilevamento statico. La relazione padre-figlio tra wscript.exe e powershell.exe, soprattutto quando accompagnata da parametri di bypass, rappresenta uno dei primi indicatori comportamentali della catena VeilDrop.

Blogspot diventa infrastruttura di staging trusted

Dopo l’avvio di PowerShell, la campagna recupera gli stage successivi da pagine Blogspot controllate dagli aggressori. La scelta è strategica: Blogspot gode della reputazione dell’infrastruttura Google, viene raramente bloccato in modo generalizzato dalle aziende e consente agli operatori di ospitare script offuscati senza ricorrere a domini appena registrati o facilmente sospetti. I comandi osservati impostano esplicitamente TLS 1.2, usano Invoke-RestMethod per scaricare contenuto remoto e ricorrono a Invoke-Expression per eseguirlo direttamente in memoria. L’aggiunta di ritardi tramite Start-Sleep, come pause di 17 secondi, serve a rendere meno immediata la correlazione tra apertura del file e attività malevola. Questo modello permette agli aggressori di aggiornare rapidamente gli stage ospitati online, modificare payload e logica di esecuzione senza redistribuire il launcher iniziale.

PowerShell orchestra una catena fileless modulare

Una volta ottenuto il primo stage, PowerShell assume il controllo dell’intera infezione. Il codice scaricato può aprire un documento decoy per distrarre la vittima, rimuovere tracce di esecuzioni precedenti, terminare processi selezionati e preparare nuovi URL Blogspot da cui recuperare gli step successivi. Ogni stage esegue una funzione limitata e passa il controllo al modulo successivo, costruendo una pipeline modulare difficile da ricostruire se analizzata soltanto a posteriori. La logica viene eseguita come ScriptBlock e rimane prevalentemente in memoria, limitando la presenza di file permanenti. Questa impostazione riduce l’efficacia dei controlli basati su hash e complica l’analisi forense tradizionale, perché molti artefatti esistono solo durante l’esecuzione e vengono generati dinamicamente.

Offuscamento XOR e caricamento riflessivo degli assembly .NET

Il framework VeilDrop protegge i payload tramite grandi blob offuscati e routine di decrittazione XOR personalizzate. I dati incorporati negli script appaiono privi di significato fino al momento dell’esecuzione, quando il codice applica la chiave prevista e ricostruisce il contenuto originale. Dopo la decrittazione, gli assembly .NET vengono caricati direttamente in memoria tramite Reflection.Assembly::Load(), evitando la scrittura di file PE sul disco. Il caricamento riflessivo consente di eseguire codice .NET all’interno del processo PowerShell senza passare dai percorsi più facilmente monitorabili dalle soluzioni antivirus tradizionali. La combinazione tra offuscamento XOR, generazione dinamica e reflective loading rende ogni sessione più difficile da fingerprintare e ostacola i rilevamenti basati su firme statiche.

Le utility LOLBIN garantiscono percorsi alternativi di esecuzione

Per aumentare la resilienza della campagna, VeilDrop include fallback basati su utility firmate da Microsoft, spesso definite LOLBIN perché legittime ma abusabili dagli attaccanti. Tra gli strumenti citati figurano RegSvcs, InstallUtil, MSBuild, CSC, VBC, ILAsm e AspNet_Compiler. Questi binari possono essere usati per compilare, caricare o eseguire codice in contesti che appaiono amministrativi o compatibili con attività di sviluppo. Se il metodo primario viene bloccato da controlli applicativi, gli aggressori dispongono quindi di percorsi alternativi per mantenere l’esecuzione. In ambienti dove il monitoraggio si limita a verificare la firma digitale o la reputazione del binario, l’abuso di LOLBIN può passare inosservato fino alla fase di furto dati.

PureLog Stealer punta a browser e wallet crypto

Il payload finale della catena è PureLog Stealer, malware .NET specializzato nell’esfiltrazione di informazioni. Una volta caricato in memoria, lo stealer raccoglie credenziali salvate nei browser, cookie di sessione, dati di compilazione automatica, cronologia di navigazione e informazioni relative ai wallet di criptovalute. Questi dati hanno valore immediato nei mercati criminali perché possono essere rivenduti, usati per accessi non autorizzati o impiegati in campagne successive di account takeover. La natura fileless dell’esecuzione riduce la probabilità che il payload venga intercettato dopo il caricamento, mentre l’uso di infrastrutture trusted nella fase di staging abbassa ulteriormente il rumore generato dalla catena. Per gli attaccanti, PureLog rappresenta il punto di monetizzazione della campagna: credenziali, sessioni e wallet diventano asset pronti per frodi, rivendita o movimenti laterali.

Rilevamento e mitigazione richiedono controllo comportamentale

La difesa contro VeilDrop deve concentrarsi sulle relazioni tra processi, sull’uso anomalo di PowerShell e sulle comunicazioni verso pagine Blogspot non autorizzate. La creazione di powershell.exe da parte di wscript.exe, l’uso combinato di Invoke-RestMethod e Invoke-Expression, il caricamento di assembly .NET via reflection e la presenza di routine XOR sono segnali ad alto valore. Le organizzazioni dovrebbero limitare l’esecuzione di script da percorsi non attendibili, bloccare l’avvio di file .js ricevuti da Internet quando non necessario, monitorare l’uso di utility LOLBIN in contesti non coerenti e applicare regole di controllo applicativo più rigorose su PowerShell. Anche il monitoraggio delle connessioni verso infrastrutture legittime ma non previste, come blog ospitati su Blogspot, diventa essenziale. La campagna conferma che la reputazione del dominio non basta più: il rilevamento deve guardare alla sequenza di esecuzione, alla memoria, ai processi figli e ai comportamenti che trasformano un semplice file JavaScript in un loader capace di consegnare uno stealer completamente operativo.