LausivLoader: il malware che sfida l'analisi frammentata

Un campione di malware rilevato a fine agosto 2025 attraverso una campagna di malspam dimostra una tecnica di evasione ancora poco documentata: il passaggio di dati tra stadi d'infezione tramite variabili d'ambiente ereditate, che rende ogni singolo frammento della catena inerte se analizzato isolatamente. L'analisi tecnica, pubblicata dal SANS Internet Storm Center il 17 settembre 2025, ricostruisce per la prima volta l'intero meccanismo di handoff inter-processo e la sua implicazione pratica per i team di risposta agli incidenti.

La catena d'infezione: cinque stadi, due handoff invisibili

L'infezione inizia con un allegato .r01 contenente un file JavaScript di 613 KB. Secondo il dossier del SANS ISC, il codice contiene circa 450 righe di commenti composti da parole inglesi casuali che fungono da offuscamento: rimossi i commenti, il codice effettivo si riduce a 205 KB. Lo script costruisce una directory in %TEMP% con nome generato da un numero casuale e dal timestamp corrente in base 36, poi vi scrive due file con nomi terminanti rispettivamente in 'a' e 'b'.

Il punto di interesse tecnico si colloca subito dopo. Il JavaScript imposta due variabili d'ambiente, Kv7408 e Kv562, con i percorsi completi dei due file temporanei. Queste variabili vengono ereditate da conhost.exe, che a sua volta le trasmette a PowerShell tramite il meccanismo standard di inheritance dei processi figli. La fonte cita esplicitamente: "child processes normally inherit their parent's environment". PowerShell legge quindi i percorsi dalle variabili d'ambiente, combina i contenuti dei due file, e avvia una sequenza di decodifica.

La decodifica utilizza AES-128-CBC con PKCS#7 padding, con chiave e vettore di inizializzazione hardcoded nello script. Il risultato, decompresso con GZipStream, è un eseguibile .NET a 64 bit di 315.904 byte. L'eseguibile viene caricato in memoria via reflection senza essere salvato su disco, eliminando un punto di rilevamento classico per gli EDR.

Perché l'ambiente ereditato è il punto cieco dell'analisi forense

La scelta di trasferire dati tramite variabili d'ambiente anziché tramite argomenti della riga di comando o file direttamente leggibili ha un effetto collaterale deliberato: rende l'analisi statica e per-partes impraticabile. L'analista del SANS ISC lo formula con precisione: "copying the decoded PowerShell command into an unrelated shell would not be able to recreate the original inputs, and per partes analysis of this infection chain would therefore not be practicable".

Il problema non è nel codice PowerShell in sé, che da solo appare innocuo o incomprensibile. Il problema è nella dipendenza contestuale: il comando decodificato si aspetta che l'ambiente contenga variabili specifiche impostate da un predecessore che, nei log di un SOC, può apparire come un processo wscript.exe completamente separato e apparentemente non correlato. Questa separazione temporale e spaziale tra la scrittura dei dati e il loro consumo costituisce un'ostacolo metodologico per chi analizza i log sequenzialmente o isola i singoli indicatori di compromissione.

La stessa fonte osserva che "looking only at the decoded command would leave us with an incomplete picture". La conseguenza operativa è che i sistemi di analisi automatica che estraggono e deoffuscano lo script PowerShell senza ricostruire l'albero dei processi con le variabili d'ambiente ereditate produrranno un falso negativo tecnico: il codice decodificato esiste, ma manca del suo input essenziale.

Dall'AMSI bypass alla steganografia PNG: gli stadi successivi

Dopo il caricamento in memoria, il primo eseguibile .NET stabilisce persistenza copiandosi in %LOCALAPPDATA%\Microsoft\PhotoEngine\PhotoStudio.js e creando un task scheduled denominato '\MicrosoftEdgeUpdateTaskCoreCore' con trigger al logon. Il task esegue wscript.exe con parametri //B //Nologo e il percorso dello script copiato, mascherando l'esecuzione come aggiornamento di un componente di sistema legittimo.

Un secondo loader .NET risolve le API Windows dinamicamente e modifica AmsiScanBuffer e AmsiScanString per bypassare l'Antimalware Scan Interface. Dopo l'evasione, estrae ogni quinto byte da un array embedded di 299.520 byte, riducendolo a 59.904 byte, quindi applica una decrittazione RC4. Il risultato è un downloader che contatta l'URL hxxps[:]//yapw[.]life/phpt/stego_zrgaixkku8.png.

"the loader would walk the PNG structure and look for an 'iTXt' chunk" — SANS Internet Storm Center

Il downloader analizza la struttura del file PNG e cerca il chunk iTXt con marker iniziale 'FF 89 AD 4A'. Il payload contenuto viene decriptato con XOR e decompresso con DEFLATE; l'analisi si aspetta un header 'MZ' per eseguibili nativi o un assembly .NET managed. L'esecuzione finale avviene tramite reflection per i componenti .NET o process hollowing per gli eseguibili nativi. L'URL non era più attivo al momento dell'analisi; il payload finale non è stato recuperato.

Perché è importante

Il dossier del SANS ISC non documenta misure correttive specifiche né raccomandazioni operative dettagliate. La fonte non specifica la natura esatta dei dati esposti durante l'infezione, né identifica la famiglia malware del payload finale. Il campione analizzato risale alla fine di agosto 2025; non emerge una data di rilevamento più precisa né dettagli sulla geografia o lingua della malspam, se non che impersonava un dipendente di un'azienda legittima nel settore delle fibre ottiche.

Il brief non elenca entità aziendali specifiche, CVE associati, o conferme di attività attuale dell'infrastruttura C2 oltre allo stato offline dell'URL al momento dell'analisi. Il ricercatore che ha condotto l'analisi non è nominato nella fonte.

Ciò che il dossier documenta con chiarezza è l'evoluzione tecnica: i loader stanno abbandonando l'offuscamento puramente sintattico in favore di tecniche che sfruttano comportamenti legittimi del sistema operativo — in questo caso, l'ereditarietà delle variabili d'ambiente — e formati file apparentemente innocui come il PNG con chunk standard iTXt. Questi approcci sono intrinsecamente più difficili da rilevare rispetto a eseguibili con estensione falsa o script con pattern di offuscamento riconoscibili.

La sfida per chi difende: quando il log parziale inganna

La tecnica del handoff inter-processo tramite environment variables solleva una questione metodologica per i SOC. Gli strumenti di analisi che estraggono e classificano i comandi PowerShell in isolamento, senza ricostruire lo stato dell'ambiente al momento dell'esecuzione, rischiano di classificare come benigni o incompleti campioni che in realtà sono stadi intermedi di una catena attiva. La variabile d'ambiente è invisibile nei log di rete e spesso troncata o omessa nei log di endpoint se non configurata esplicitamente per la cattura completa.

La scelta del chunk iTXt all'interno di un PNG, invece di formati più sospetti come file eseguibili con estensione doppia, indica una preferenza per la mimetizzazione all'interno di flussi di dati legittimi. I chunk iTXt sono parte dello standard PNG e possono contenere metadati testuali senza alterare la visualizzazione dell'immagine; il loro utilizzo per payload eseguibili sfrutta la scarsa attenzione che gli strumenti di sicurezza dedicano a questo tipo di contenitore.

Domande e risposte

Perché l'analisi statica dello script PowerShell fallisce in questo caso?

Perché il comando decodificato dipende da variabili d'ambiente impostate da un processo precedente (JavaScript via wscript.exe). Senza quelle variabili, che contengono i percorsi dei file temporanei da combinare e decodificare, lo script PowerShell non ha accesso ai suoi input. L'analisi statica del solo codice PowerShell produce quindi un comando incompleto o non funzionante.

Il meccanismo di ereditarietà delle variabili d'ambiente è una vulnerabilità?

No. Si tratta di un comportamento standard e documentato del sistema operativo. La fonte lo definisce esplicitamente "just an ordinary environment inheritance used to pass information between different stages of an execution chain". La novità sta nell'uso tattico di questo comportamento per scopi malevoli, non nella sua natura.

Cosa rende la steganografia PNG con chunk iTXt più difficile da rilevare?

Il chunk iTXt è una struttura legittima del formato PNG, progettata per metadati testuali internazionali. A differenza di allegati eseguibili o di macro Office, un PNG con chunk iTXt non presenta anomalie di formato né trigger di sicurezza standard. Gli strumenti di analisi devono implementare il parsing specifico della struttura PNG per individuare payload nascosti in questa locazione.

Fonti

• https://isc.sans.edu/diary/rss/33348
• https://www.virustotal.com/gui/file/408b2df6e81824fa5bdf4f0fbd185a7e6db06e2be98fbeebce416f66954b9fa9

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti