Sintesi

È stata recentemente osservata una campagna malspam proveniente da un indirizzo mittente contraffatto che simula una mailing list legittima di un’organizzazione italiana. Le e-mail indirizzavano a domini typosquat riconducibili a una nota società europea, con l’obiettivo di rendere la comunicazione verosimile e indurre l’utente ad aprire allegati dannosi.

Descrizione e potenziali impatti

È stata recentemente osservata una campagna malspam proveniente da un indirizzo mittente contraffatto che simula una mailing list legittima di un’organizzazione italiana operante nel settore marittimo. Nel corpo del testo, il contenuto faceva leva su tecniche di typosquatting , impiegando nomi di dominio riconducibili a una nota società europea operante nel settore energetico, attiva anche in ambito offshore, nel tentativo di aumentare la credibilità della comunicazione.

Nel dettaglio, veniva proposto un link che rimandava a una risorsa accessibile tramite protocollo WebDAV [1], dalla quale risultava possibile prelevare un documento Word. Il file conteneva una macro malevola che, qualora attivata, procedeva al download e all’esecuzione di uno script VBS [2], dando inizio alla catena di infezione.

Le fasi successive prevedono il download di ulteriori payload da siti WordPress obsoleti e vulnerabili, sfruttati dagli attaccanti per ospitare contenuti malevoli e facilitare la catena d’infezione.

Primo step

Il primo file VBS della catena di infezione contiene del codice offuscato che, una volta decodificato (Figura 1), rivela uno script powershell che preleva e apre un file PDF; successivamente attende la chiusura di quest’ultimo prima di procedere al download e all’esecuzione di un secondo file VBS.

Secondo step

Il secondo file VBS presenta un livello di offuscamento più elevato, con numerose righe di testo generate casualmente e commenti inseriti per confondere un eventuale analista. Dopo una breve pulizia, il codice assume la forma mostrata in Figura 2.

A seguito della decodifica, si ottiene un secondo script powershell offuscato (Figura 3).

Attraverso opportune sostituzioni e un processo di reingegnerizzazione del codice, è possibile individuare le componenti principali del codice: una funzione di deoffuscamento e una per l’esecuzione di comandi (Figura 4).

Nel dettaglio, il codice tenta ripetutamente di scaricare da due risorse remote una seconda porzione del payload malevolo, codificata in Base64 : dopo la decodifica, ne estrae gli ultimi 27.493 byte, che vengono caricati ed eseguiti direttamente in memoria.

Terzo step

La porzione del nuovo payload, anch’essa offuscata, dopo le fasi di decodifica e le opportune sostituzioni, si presenta come segue (Figura 5).

Lo script si articola in tre fasi principali. Nella prima fase raccoglie informazioni sull’ambiente, verifica l’architettura del sistema e costruisce il percorso corretto per eseguire il comando powershell finale.

Nella seconda fase tenta ripetutamente di ottenere un oggetto COM valido di tipo ShellWindows[3] , che rappresenta un’istanza di Windows Explorer; in caso di esito negativo, avvia explorer.exe e riprova finché l’oggetto richiesto non risulta disponibile. Questo gli permette di usare il metodo ShellExecute per rilanciare sé stesso in un contesto più “legittimo”, meno soggetto a blocchi o monitoraggi diretti.

Infine, nella terza fase, lo script recupera i primi 461.932 byte scartati dal payload prelevato tramite lo step 2, nasconde la finestra della console, alloca memoria eseguibile quindi inietta il suddetto payload recuperato suddividendolo in 2 blocchi distinti: i primi 6.641 byte rappresentano la porzione iniziale del codice di una shellcode [4], eseguita tramite la funzione CallWindowProcA [5] evitando così di lasciare tracce su disco, mentre la parte restante, passata come argomento, contiene dati e funzioni di supporto.

A questo punto dello studio del codice, considerate le iterate tecniche di offuscamento osservate, unite al meccanismo di caricamento e iniezione di una shellcode in memoria, è stato possibile dedurre che il campione in analisi fosse una variante del noto malware GuLoader .

In base a tale deduzione, si è quindi proseguito lo studio per identificare con precisione quale fosse il malware finale eseguito dal loader.

Primo stage

La prima shellcode è composta da poche centinaia di byte di codice effettivo ed il suo compito principale è eseguire la seconda shellcode ricevuta come parametro. Per farlo, copia una porzione del secondo shellcode in un’altra area di memoria, quindi utilizza una syscall indiretta per eludere i meccanismi di rilevamento e modificare i permessi della memoria per renderla eseguibile. Infine, decripta un blocco di codice e vi trasferisce l’esecuzione, avviando così il secondo stage.

Secondo stage

La seconda shellcode è più avanzata e progettata per rendere l’analisi estremamente difficile. Utilizza tecniche che alterano dinamicamente il flusso di esecuzione, interrompendo la linearità del codice. Inoltre, verifica che le API necessarie all’esecuzione non siano state modificate da strumenti di sicurezza. Infine, il payload effettua anche controlli approfonditi di anti-debugging e anti-virtualizzazione, rilevando la presenza di driver sospetti, processi di debug attivi, breakpoint hardware e altre tecniche di analisi.

Il superamento di tutte queste verifiche permette il passaggio all’ultimo stage.

Terzo stage

Lo scopo principale del terzo stage è scaricare ed eseguire il malware finale. In questa fase, il malware accede a uno o più URL remoti (Figura 6) per recuperare un file BIN cifrato, che viene poi decifrato in memoria.

Inoltre, la chiave necessaria alla decifratura, incorporata nel codice in forma offuscata, viene anch’essa decifrata a runtime. Completate queste operazioni, il payload viene caricato ed eseguito direttamente in memoria.

Il malware finale

L’intera catena di esecuzione (Figura 7), si conclude con l’esecuzione dell’ infostealer Rhadamantys .

 Una volta avviato, Rhadamanthys impiega avanzate tecniche di evasione e iniezione di codice per mantenere il controllo del sistema compromesso. Una delle strategie adottate è il process hollowing , tecnica che consente al malware di svuotare la memoria di un processo legittimo in esecuzione — nel caso in analisi OpenWith.exe , un componente legittimo di Windows associato alla gestione delle associazioni file — sostituendola con il proprio codice malevolo. Questo consente al payload di essere eseguito all’interno di un processo apparentemente innocuo, eludendo eventuali controlli di sicurezza.

Successivamente, l’infostealer utilizza OOBE-Maintenance.exe , altro processo di sistema legittimo coinvolto nella configurazione iniziale di Windows (Out-Of-Box Experience), come contenitore per attività di raccolta informazioni.

Tra queste figurano:

• il furto di credenziali;
• la cattura di screenshot;
• la mappatura del sistema;
• il furto di criptovalute.

Nel dettaglio, è stato rilevato l’utilizzo del modulo KeePassHax , impiegato per accedere direttamente alla memoria del processo KeePass.exe e intercettare credenziali visualizzate nella GUI. Questa tecnica non richiede l’accesso al database .kdbx ma sfrutta l’estrazione dei dati temporaneamente in chiaro, una volta che l’utente ha sbloccato il contenuto del vault.

Tali operazioni vengono eseguite in maniera completamente silente, senza interazione visibile per l’utente e con una bassa probabilità di essere rilevate da soluzioni antivirus tradizionali.

Criticità e superficie di esposizione

Il caso trattato rimarca i rischi legati all’esposizione di servizi applicativi direttamente sulla rete Internet senza garantire un’adeguata protezione tramite misure di sicurezza e aggiornamenti costanti. Sistemi accessibili pubblicamente, ove non correttamente configurati o mantenuti, costituiscono un vettore privilegiato per gli attaccanti, che possono sfruttare vulnerabilità note, configurazioni errate o di default, per ottenere un punto di accesso nella rete dell’organizzazione.

Questi scenari sono stati ampiamente trattati nell’ambito del bollettino BL01/250626/CSIRT-ITA , che metteva in evidenza come la presenza di tali elementi incrementi la superficie di esposizione e il rischio di compromissione.

Questa campagna ha visto lo sfruttamento di diverse istanze WordPress 4.7.x, per la distribuzione dei payload intermedi e del malware finale. Le vulnerabilità presenti in tali istanze hanno facilitato l’accesso non autorizzato, permettendo agli attaccanti di caricare e eseguire codice malevolo, compromettendo così la sicurezza dei sistemi coinvolti e ampliando la portata dell’infezione.

Tra le vulnerabilità analizzate, la prima riguarda un’errata implementazione delle API REST di WordPress, specificamente nel file class-wp-rest-users-controller.php , presente nel percorso wp-includes/rest-api/endpoints . Questa falla consente a un attaccante non autenticato di interagire impropriamente con le API, eludendo i controlli di autorizzazione e ottenendo la possibilità di modificare contenuti o accedere a dati sensibili, mettendo a rischio l’integrità e la sicurezza del sito compromesso.

Altri servizi WordPress risultavano configurati per rispondere tramite protocollo HTTP non cifrato, restituendo codici di stato compresi tra 200 e 299 . Il mancato utilizzo di HTTPS rende il traffico vulnerabile a intercettazioni da parte di attori malevoli capaci di eseguire attacchi di tipo Man-in-the-Middle , esponendo potenzialmente informazioni sensibili come credenziali di accesso e dati personali, ponendo in serio rischio la riservatezza delle comunicazioni.

A rendere il quadro ancora più delicato contribuisce l’esposizione pubblica di endpoint critici vulnerabili (come wp-login.php e xmlrpc.php) , accessibili direttamente da Internet (Figura 8 e 9).

In assenza di adeguate contromisure, questi endpoint facilitano attacchi di tipo brute‑force, enumerazioni di utenti e lo sfruttamento di vulnerabilità note, rendendo le istanze WordPress 4.7.x estremamente suscettibili a compromissioni in mancanza di aggiornamenti e configurazioni di sicurezza adeguate.

Azioni di Mitigazione

Gli utenti e le organizzazioni possono far fronte a questa tipologia di attacchi attivando le seguenti misure preventive:

• fornire periodiche sessioni di formazione finalizzate a riconoscere il phishing, diffidando in particolare dalle comunicazioni non attese che invitano ad aprire allegati e/o link sospetti;
• non accedere a collegamenti internet o a relativi contenuti esterni se non si è certi dell’affidabilità della risorsa;
• evitare di prelevare ed eseguire file (lnk, exe, bat, js, vbs, ecc.) pdf o documenti contenenti macro se non si è certi della loro liceità;
• mantenere un processo di patch management automatizzato per il CMS (e relativi plugin/temi), assicurando l’applicazione tempestiva di tutte le patch di sicurezza non appena vengono rilasciate;
• limitare l’esposizione diretta di endpoint critici (wp-login.php, xmlrpc.php) tramite firewall applicativo (WAF), regole di accesso basate su IP e CAPTCHA.

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.

Infine, si raccomanda di valutare la verifica e l’implementazione – sui propri apparati di sicurezza – degli Indicatori di Compromissione (IoC) ^[6] forniti in allegato.

[1] WebDAV (Web Distributed Authoring and Versioning) è un’estensione del protocollo HTTP che consente la gestione collaborativa di file su server web remoti.

[2] Un file VBS (con estensione .vbs) è uno script scritto in VBScript (Visual Basic Scripting Edition), un linguaggio di scripting sviluppato da Microsoft. Questi script vengono eseguiti principalmente su sistemi Windows tramite il motore Windows Script Host (WSH).

[3] Un oggetto COM (Component Object Model) valido di tipo ShellWindows rappresenta una collezione di tutte le finestre attive di Esplora risorse (Explorer) e Internet Explorer sul sistema. Questo oggetto, accessibile tramite automazione COM, consente di enumerare e interagire con le istanze delle finestre aperte, recuperando ad esempio il percorso di directory visualizzate o manipolando il contenuto delle finestre in modo programmatico.

[4] Una shellcode è una sequenza di istruzioni in linguaggio macchina progettata per essere eseguita come parte di un exploit

[5] CallWindowProcA consente l’esecuzione di codice arbitrario passando il relativo indirizzo come se fosse una funzione WindowProc per la gestione dei messaggi di Windows. In questo modo l’esecuzione avviene senza creare nuovi thread (es. CreateThread, NtCreateThreadEx), eludendo i controlli di sicurezza che monitorano tali operazioni e sfruttando una API legittima per aumentare la furtività dell’attività in memoria.

[6] Per definizione, non tutti gli indicatori di compromissione sono malevoli. Questo CSIRT non ha alcuna responsabilità per l’attuazione di eventuali azioni proattive (es. inserimento degli IoC in blocklist) relative agli indicatori forniti. Le informazioni contenute in questo documento rappresentano la migliore comprensione della minaccia al momento del rilascio.