DeadVax: la nuova catena di infezione via VHD e IPFS che porta AsyncRAT in memoria

La campagna DeadVax rappresenta uno dei casi più emblematici di tradecraft malware avanzato osservati all’inizio del 2026, perché combina formati di file fidati, infrastrutture decentralizzate e esecuzione fileless in una catena di infezione progettata per eludere i controlli tradizionali. L’analisi pubblicata il 14 gennaio 2026 da Securonix Threat Research documenta una catena multi-stage che parte da email di phishing mirate e termina con il caricamento in memoria di AsyncRAT, senza mai scrivere un eseguibile finale su disco.

DeadVax non introduce tecniche radicalmente nuove, ma orchestra in modo estremamente raffinato elementi già noti: file Virtual Hard Disk, gateway IPFS, script Windows offuscati, loader PowerShell e iniezione di shellcode in processi legittimi. Il risultato è una campagna difficile da rilevare con controlli basati su firma o su scansione statica.

Accesso iniziale: phishing aziendale e abuso di IPFS

L’accesso iniziale avviene tramite email di phishing che impersonano comunicazioni commerciali credibili, in particolare ordini di acquisto attribuiti a Progressive Components. I messaggi creano urgenza artificiale, richiedendo una risposta entro pochi giorni, e utilizzano mittenti che imitano ruoli aziendali reali come uffici acquisti o vendite.

L’elemento chiave è l’allegato. Apparentemente si tratta di un PDF, ma in realtà il link punta a un file VHD ospitato su IPFS e distribuito tramite un gateway HTTPS con certificato SSL valido. Questo dettaglio è cruciale: molti gateway email non penalizzano link con TLS corretto e reputazione neutra, e infatti i campioni analizzati ottengono punteggio zero su VirusTotal al momento della consegna.

Il VHD viene scaricato dall’utente e, con un semplice doppio clic, montato come unità locale da Windows. È qui che entra in gioco una delle tecniche più efficaci della campagna: i file all’interno del VHD non ereditano il Mark-of-the-Web, perché appaiono come contenuti locali. Di conseguenza, Windows non mostra avvisi di sicurezza quando vengono aperti.

Stage iniziali: WSF e batch offuscati

Una volta montato il VHD, l’utente visualizza un file con doppia estensione, progettato per sembrare un documento PDF ma che in realtà è uno script WSF. Questo primo stage utilizza offuscamento basato su concatenazione di stringhe, rimozione di caratteri non stampabili e decodifica Base64, seguita da una fase di XOR multiplo con chiavi dinamiche.

Lo script WSF non esegue direttamente il payload finale. Il suo compito è decrittare e scrivere su disco uno script batch in una directory temporanea. Il batch rappresenta un passaggio intermedio critico, perché introduce logiche di anti-analisi e prepara l’ambiente per il loader PowerShell.

Il batch è composto da migliaia di variabili SET, usate per mascherare il codice reale. Prima di procedere, verifica se l’utente dispone di privilegi amministrativi, controlla la presenza di ambienti virtualizzati come VMware e termina l’esecuzione se rileva condizioni tipiche di sandbox, come RAM inferiore a 3 GB. Solo in assenza di questi indicatori procede allo stage successivo.

Loader PowerShell e offuscamento multi-layer

Il batch genera e lancia un loader PowerShell fortemente offuscato. Questo loader utilizza più livelli di trasformazione, tra cui normalizzazione Unicode, Base64, XOR rolling e rotazioni di caratteri. Lo scopo è rendere inefficaci sia il logging superficiale sia le analisi automatiche.

Una volta deoffuscato in memoria, il loader invoca API Win32 tramite Add-Type, preparando le primitive necessarie per l’iniezione: OpenProcess, VirtualAllocEx, WriteProcessMemory e CreateRemoteThread. In questa fase viene selezionato un processo bersaglio fidato, come RuntimeBroker.exe, OneDrive.exe o sihost.exe, scelto per la sua presenza costante nei sistemi Windows moderni.

Il loader recupera quindi un blob cifrato da un file apparentemente innocuo in C:\ProgramData, lo decritta runtime e lo prepara come shellcode x64 privo di header PE. L’assenza di un formato eseguibile tradizionale aumenta la probabilità di elusione dei controlli EDR basati su file.

Payload finale: AsyncRAT in memoria

Il payload iniettato è AsyncRAT, distribuito esclusivamente in memoria. La shellcode, con entropia superiore a 7.7, non viene mai salvata come eseguibile autonomo. Una volta avviato, il RAT stabilisce comunicazioni cifrate con l’infrastruttura di comando e controllo, abilitando keylogging, raccolta di informazioni di sistema, esecuzione remota di comandi ed esfiltrazione dati.

L’analisi di Securonix conferma l’identità del payload attraverso hash SHA-256 coerenti con varianti note di AsyncRAT, dimostrando che DeadVax non sviluppa un RAT proprietario, ma ottimizza la delivery di un malware già collaudato.

Perché DeadVax è rilevante nel 2026

DeadVax mostra come gli attaccanti stiano spostando l’attenzione dalla creazione di nuovi malware alla perfezione delle catene di infezione. L’abuso di VHD, IPFS e script legittimi consente di aggirare controlli email, avvisi di sicurezza di Windows e rilevamenti basati su firma. La campagna evidenzia anche un cambio di paradigma difensivo. Non è sufficiente bloccare allegati eseguibili: immagini disco, script temporanei e comportamenti in memoria diventano i veri indicatori di compromissione. Per molte organizzazioni, questo richiede un ripensamento profondo delle strategie di monitoraggio endpoint.

Domande frequenti su DeadVax