Nei giorni precedenti è stata veicolata in italia una campagna malware in cui è stato utilizzato il malware AdWind come loader di altre componenti malevoli utili a compromette maggiormente le macchine per le successi azioni criminose.

AdWind è un malware scritto in Java, composto da un insieme di funzionalità core e da ulteriori plugin aggiuntivi che gli permettono di fungere sia da RAT che da infostealer.

Sebbene l’utilizzo di Java possa far ipotizzare che il malware sia in grado di infettare parecchi sistemi operativi, nella pratica si evince che il codice di AdWind è pensato per lavorare esclusivamente con sistemi operativi Microsoft Windows e che non riuscirebbe ad essere del tutto efficace su altri sistemi.

Il core di AdWind è piuttosto limitato ed è in grado di eseguire solo pochi comandi base, utilizzati per il download di payload aggiuntivi.

Grazie ad una serie di errate configurazioni e di errori commessi dagli autori è stato possibile recuperare un certo numero di informazioni che hanno permesso in parte di ricostruire il modus operandi dei criminali dietro ad AdWind e che vogliamo riportarvi come interessante caso di studio in materia.

Adescamento delle vittime

Trattandosi di una campagna non mirata a bersagli specifici (se non per la loro nazionalità italiana), le vittime sono adescate tramite un’e-mail generica il cui corpo fa riferimento ad un fantomatico rimborso:

Il tema dei pagamenti, insieme a quello delle spedizioni, è (comprensibilmente) un tema che funziona sempre bene nelle campagne. A volte anche troppo, come dimostra la risposta inviata da una delle vittime:

Come si vede, è necessario, da parte di chi fa cybersecurity awarness, porre particolare enfasi nell’istruire gli utenti a controllare attentamente quelle e-mail che fanno riferimento a rimborsi.

La promessa di soldi (magari realmente attesi) è una leva emotiva molto forte ma che può essere controllata se si diffonde e si innalza la consapevolezza di questo tipo di minaccia.

Il contenuto dell’email, probabilmente utilizzata in passato in un invio leggittimo, non presenta errori grammaticali e suggerisce all’utente di aprire con urgenza l’allegato contenente un “Rimborso Spese Conferma Urgente“.

L’allegato è un file PDF. Questi file raramente sono pericolosi (quando lo sono è per via di una minaccia di tipo 0-day e quindi un attacco decisamente fuori dall’ordinario e poco comune nelle campagne massive) e spesso si limitato a contenere un link ad una risorsa malevola o ad una pagina di phishing.

In questo modo, l’allegato non risulta malevolo agli anti-virus ma è comunque efficace ai fini di avvio dell’infezione.

Infatti, una volta aperto il file allegato .PDF questo presenta un’immagine volutamente sfocata e un simil-popup che invita l’utente a scaricare un aggiornamento per Adobe Reader.

Qui l’attaccante ha voluto sfruttare il marchio Adobe perchè assume che la maggior parte delle vittime utilizzi il software di Adobe per leggere i PDF.

Il pretesto dell’aggiornamento è sempre spendibile quando si vuole far scaricare un malware ed è quindi un altro tema su cui andrebbero sensibilizzati gli utenti.

Entrando nei dettagli più tecnici, l’e-mail è stata inviata da una macchina avente indirizzo IP 51.178.194.75:

Message-ID: &lt;2b1b4..................bad02@<strong>51.178.194.75
by ip<strong>75</strong>.ip-<strong>51-178-194</strong>.eu (Microsoft SMTPSVC(6.0.3790.1830)) with SMTP id BLDMVYYO
X-Mailer: Microsoft Office Outlook 12.0 (Non attendibile)

SI tratta di un server VPS ospitato dal provider francese OVH ma appartenente ad un provider di fibra italiano. Ci sono evidenze, come vedremo più avanti, per ritenere che la macchina sia un server Windows usato come gateway/proxy da parte dei clienti dell’azienda.

Prima di continuare con l’analisi della catena di infezione, vediamo alcuni accorgimenti tecnici usati per rendere la campagna più gestibile da parte dei criminali.

Il link usato nel PDF

Il link usato nel PDF utilizza un servizio di URL shortening ed in particolare il link punta a: bit[.]ly/3ChCZ1S.

Dato che un PDF non è un contesto in cui è vantaggioso risparmiare qualche decina di caratteri (come lo è ad esempio un SMS), è naturale chiedersi perchè sia usato un URL shortening.

Possiamo fornire almeno tre motivi per cui questo può essere utile:

1. Nascondere il vero URL finale. I software antivirus non necessariamente risolvono il vero URL dietro a questi short link e potrebbero quindi non rilevare la minaccia. Per questo motivo, anche se in qualche caso non è del tutto corretto, è bene includere anche lo short link tra gli indicatori di compromissione (come facciamo con il nostro flusso di IoC).
2. Permettere di avere statistiche analitiche. Nello specifico esempio, bit.ly offre un servizio di statistiche (un tempo in parte pubblicamente accessibile) sui visitatori dei link. Questo può risultare utile ai criminali: in fin dei conti una campagna malware ed una campagna di marketing condivono una buona parte di pratiche comuni.
3. Cambiare obiettivo in corso d’opera. Alcuni servizi di shortening permettono di cambiare l’URL finale (anche se solo per utenti paganti). Questo può risultare utile per evitare che la campagna si spenga a seguito delle azioni delle community di cyber security (in particolare al censimento dell’URL finale nella lista di URL malevole).

L’indirizzo di Reply-to

Come visto prima, è probabile che alcune delle vittime rispondano all’e-mail malevola.

Quando per l’invio viene usata una casella compromessa, quindi di soggetti terzi che potenzialmente la leggono quotidiamamente, è essenziale che le risposte non arrivino al mittente poiché quest’ultimo si insospettirebbe e potrebbe compromettere il buon esito della campagna, innescando uno scambio di e-mail con la vittima che porterebbero allo scoperta dell’inganno.

Un modo per impedire al mittente la ricezione delle risposte è quello di usare un indirizzo Reply-to, organizzato appositamente per situazioni simili.

Nel caso di questa campagna è stato utilizzo come Reply-to un indirizzo del provider Youpmail. Nell’email si può notare come il campo “Reply-to” sia valorizzato con un email appartenente al dominio Youpmail. Youpmail permette di creare caselle email “spazzatura” dove poter solo ricevere la posta; non è possibile inviare email e al 8° giorno i messaggi in inbox vengono cancellati.

Gli indirizzi Youpmail sono però anche facilmente accessibili da tutti ed è quindi facile, in questa campagna, avere accesso alle risposte delle vittime.

Sebbene non interessanti nel loro contenuto, queste risposte permettono di avere un campione delle vittime dal quale dedurre gli obiettivi della campagna (come vedremo in seguito).

Il primo stadio

Lo short link ha come URL finale https[:]//streamingaltadefinizion.it/aggiornamento.php?a=fdokreg0kwrge0kerg0lw40kwrg0klerb0kerr

La pagina a cui sono indirizzate le vittime continua a sfruttare il tema degli aggiornamenti Adobe Reader:

Da questa pagina è possibile scaricare il file “aggiornamento368_acr_install.zip” che contiene al suo interno un file JAR di nome “aggiornamento368_acr_install.jar”.

Questo file JAR contiene proprio il core di AdWind ed è composto da poche classi Java che sono però offuscate (gli identificatori sono stati tutti cambiati con nomi simili tra loro):

Date le ridotte dimensioni del JAR è però possibile deoffuscarlo interamente (i sorgenti decompilati e deoffuscati sono disponibili qui):

Analizzando la classe “Main.class”, anche senza deoffuscare il codice, è facile trovare funzioni di sicuro interesse, come quelle che coivolgono il C2 (che analizzeremo in seguito), la funzione in grado di scoprire l’indirizzo IP della vittima come anche la funzione usata per disabilitare Windows Defender.

Dai file deoffuscati si vedono i possibili comandi che il malware può ricevere dal C2 (presente in chiaro nei sorgenti ottenuti dal decompilatore):

• download – usato per scaricare ulteriori payload
• browse – usato per navigare su determinate URL
• kill – usato per ri-eseguire Adwind con i privilegi di amministratore

Una volta eseguito il file .JAR, il malware Adwind installa la sua persistenza mediante chiave di registro: Software\Microsoft\Windows\CurrentVersion\Run

La macchina compromessa dal malware Adwind entra quindi a far parte di una botnet, controllata dall’attaccante, e riceve i comandi dal C2 tramite una serie di API esposte da quest’ultimo:

• https://[domain_C2]/api/getIpAddress – è un comando che restituisce l’indirizzo IP della vittima
• http://www.geoplugin.net/json.gp?ip=[$IP_VITTIMA] – permette di estrarre il country code della vittima
• https://[domain_C2]/api/get_anytask?<parametri> – è una chiamata API completa, in grado di passare tutte le informazioni sulla vittima al C2 (vedi immagine sotto). Qualora siano configurati dei “task” da eseguire, quest’API risponde con “do”.

• https://[domain_C2]/api/get_tasklist?<parametri> – ritorna una lista (separata da punto e virgola) di comandi da eseguire insieme ad un eventuale parametro. I comandi sono quelli elencati sopra.

Il C2 – Command & Control

I comandi del malware contattano il C2 tramite la URL https[:]//signorcredito.it/api/.

Le informazioni Whois indicano che il dominio usato è molto vecchio, probabilmente scaduto e riacquistato.

Domain:             signorcredito.it
Status:             ok
Signed:             no
Created:            2018-11-30 00:00:31
Last Update:        2020-12-16 00:45:32
Expire Date:        2021-11-30

E’ interessante notare come sia il drop URL (streamingaltadefinizion[.]it) che il C2 (signorcredito[.]it) siano domini italiani. [streamingaltadefinizion[.]it registrati piuttosto recentemente (il 12 novembre)].

Contattando il sito del C2, lo stesso sembra mostrare una sorta di autenticazione basata su email e password:

Ma sfruttando delle errate configurazioni è comunque possibile ricavare ulteriori informazioni senza eccessivi sforzi.

Si evince quindi che vengono utilizzate tre sezioni:

Creazione di un nuovo task

Un task è un comando eseguibile dal core di AdWind. Intuitivamente, dovrebbero corrispondere ai comandi browse e download.

Il payload del comando download può essere ospitato su un sito terzo (come è il caso di questa campagna, dove è riusato streamingaltadefinizion[.].it) o sul sito stesso.

Nel primo caso viene chiamato “WebSite File Task”.

Elenco dei task

Dovrebbe trattarsi di un elenco da cui possibile ottenere i payload senza necessariamente doverli eseguire. Il core di AdWind si riserva di utilizzarli in un secondo momento.

Lista delle vittime

Ogni vittima viene comunicata dal malware al C2. Le informazioni raccolte, che abbiamo già visto deoffuscando il core di AdWin, finiscono nel DB del C2 e riguardano: il Paese di provenienza, il mac-address, il nome macchina, la data di compromissione e lo status.

L’analisi si sdoppia

A questo punto l’analisi della campagna si sdoppia. Da un lato abbiamo le comunicazioni con il C2, dall’altra possiamo analizzare i payload scaricati dal C2.

Le due strade si percorrono di pari passo poichè i payload interagiscono con il C2 ma, per semplicità di esposizione, trattiamo prima l’analisi dei payload (detti anche Task).

I task

In questo caso specifico, il C2 fornisce tre task: ct.cmp (un PE), r.jar e ss.exe. Durante l’analisi anche un altro payload è stato usato: try.exe.

ss.exe

ss.exe non risulta essere funzionante. Trattasi di un eseguibile pacchettizzato con UPX ma l’import delle API non funziona correttamente una volta che viene spacchettato.

Vedremo più avanti come gli attaccanti abbiano ritentato ad aggiungere un task con lo stesso malware ma tramite un packer diverso (try.exe appunto).

try.exe

Questo task è lo stesso di ss.exe ma che utilizza un diverso packer. Contiene Raccoon Stealer alle cui analisi si rimanda al dettaglio descritto più avanti.

r.jar

Questo è un task AdWind ma eseguito con un plugin. Il C2 usato è teddyboe34[.]dns[.]navy che al momento risolve su 51.178.194.75. Una ulteriore conferma che tale macchina sia infetta.

ct.cmp

Questo è il task più interessante. Si tratta di un semplice file eseguibile, scritto in C, che ha lo scopo di installare un’estensione malevola in Chrome.

Questo malware ottiene il percorso di Chrome dal registro di sistema e scarica da signorcredito[.]it tre file: manifest.json, main.js e background.js

I file sono salvati in una cartella temporanea nel percorso dove Chrome salva le estensioni installate. Dopo di chè Chrome viene avviato con un parametro da riga di comando per far registrare l’estensione appena scaricata.

Infine, il parametro –disable-background-timer-throttling viene aggiunto ad ogni collegamento a Chrome presente nel Desktop, Avvio veloce e Menù Avvio.

Vedremo che questo è fatto perchè l’estensione contiene due payload: uno di questi è un miner e questa opzione permette di utilizzare maggiore potenza di calcolo.

Altro fatto interessante di questo task è che presenta una data di scadenza: il 6 dicembre 2021. Dopo questa data il programma termina senza eseguire azioni malevole:

L’estensione malevola

Il manifest.json dell’estensione è mostrato di seguito:

Da questo si evince che è composto da due script:

• background.js – è uno script eseguito in background che non analizzeremo nel dettaglio ma sul quale faremo ipotesi.
• main.js – è uno script eseguito in ogni pagina.

Considerando i permessi richiesti dall’estensione, lo script main.js risulterà in grado di effettuare attacchi di tipo Man-in-the-Browser.

Entrambi gli script sono offuscati: JavaScript è un linguaggio che si presta bene alla manipolazione del codice e risulta quindi facile da offuscare pesantemente. Basti dare un’occhiata al codice di main.js:

Questo tipo di offuscazione è recentemente molto utilizzata per il codice JavaScript, per cui può essere utile descrivere brevemente come deoffuscarlo.

Se il codice viene formattato, si possono notare alcuni pattern. In particolare è possibile individuare tre funzioni:

La prima funzione (che si trova sempre ad inizio codice) mischia l’array delle stringhe. Questo array è creato dalla terza funzione e letto dalla seconda.

Se copiamo questo codice (avendo cura di mettere la prima funzione per ultima) in una console di un browser possiamo ottenere l’array delle stringhe una volta mischiato.

Ma possiamo fare ancora di più: possiamo usare il contesto del browser per deoffuscare il codice. Le stringhe infatti sono lette da funzioni del tipo questa in seguito:

Ce ne sono varie decine simili. Se le copiamo tutte nella stessa console del browser abbiamo arricchito il contesto creato prima con una serie di funzioni in grado di deoffuscare le stringhe.

Queste funzioni sono chiamate con un numero variabile (ma fisso per script) di parametri intersi in formato esadecimale come ad esempio 5 nel nostro caso:

Avendo copiato tutte le funzioni di lettura delle stringhe nella console, scrivendo _0x534ed0(0x12f, 0xa3, 0x142, 0xa9, 0x181) in quest’ultima, otteniamo la stringa deoffuscata:

A questo punto per deoffuscare tutte le stringhe non rimane che copiare il codice offuscato e assegnarlo ad una stringa JavaScript nella console del browser.

Questo può essere fatto in vari modi, incluso con l’uso dei backtick o di un elemento textarea creato appositamente.

Successivamente, con delle regex apposite, è possibile sostituire ogni chiamata ad una funzione con n argomenti esadecimali ed il cui nome inizia per _0x con il valore ritornato dalla funzione stessa. Qualcosa del tipo:

let codice_deoffuscato = codice_offuscato.replace(/_0x([a-zA-Z0-9]+)\((-?[A-Za-z0-9x]+),\s*(-?[A-Za-z0-9x]+),\s*(-?[A-Za-z0-9x]+),\s*(-?[A-Za-z0-9x]+),\s*(-?[A-Za-z0-9x]+)\)/g, function (m, n, a, b, c, d)
{
    try 
    {
         return "'" + (window['_0x' + n])(parseInt(a), parseInt(b), parseInt(c), parseInt(d)) + "'";
    }
    catch(e)
    {
         return '_0x' + n + '(' + a + ', ' + b + ', ' + c + ', ' + d + ')';
    } 
});

Non è gestito l’escaping dell’apostrofo e dello slash in questo esempio ma un paio di replace sono sufficienti a farlo (o usando semplicemente JSON.stringify del valore ritornato dalla funzione matchata).

Questo ci dà il codice con le stringhe originali, il che è già molto utile, ma il codice è ancora offuscato.

In particolare saranno presenti degli oggetti le cui proprietà hanno nome casuali ma corrispondono sempre a:

• Stringhe – Alcune sono quelle originali dello script non offuscato, altre sono stringhe usate per statement del tipo if (‘ayhZ’ === ‘ayhZ’).
• Operatori base – comparazioni, concatenazioni, aritmetica.

Rinominando queste proprietà secondo la funzione che svolgono o la stringa che contengono (stringhe alfanumeriche corte sono prodotti dell’offuscatore e possono essere rinominate come s1, s2, …), come mostrato in seguito, si ottiene del codice più leggibile:

Dopo questo lavoro certosino, il codice è sostanzialmente in chiaro anche se scritto in uno stile meno leggibile e con statement vacui.

Rimuovendo gli statement inutili si ottiene lo script originale.

Facendo questo lavoro su main.js ci si accorge che il suo unico compito è creare un elemento <script> nella pagina visitata dove questo script punta a https[:]//signorcredito[.it]/ok.js.

Questo nuovo file contiene poche linee JS (non offuscate) per l’inserimento di un nuovo tag script che punta a conn.js sempre nel solito server.

Conn.js è il vero payload e una volta deoffuscato si presenta così:

Si tratta di uno script in grado di rendere il browser della vittima elemento di una botnet.

Notiamo anche che il C2 è spectrafac[.]top e che il file contattato è conn.php.

Questo script non dispone di particolari funzionalità se non quelle di fare ping al C2 regolarmente. Possiamo però notare che l’ID con il quale si registra contiene la parola “miner“.

Dal C2 signorcredito[.]it si ricavano sia il file conn.php, che analizzeremo tra breve (insieme ad un file denominato home_ats.js) che il file test.php. Quest’ultimo contiene le seguenti righe di codice:

Questo elemento, insieme alla stringa trovata in conn.js e al parametro –disable-background-timer-throttling ci fanno ipotizzare che background.js contenga al suo interno un miner. Non abbiamo analizzato quale sia nello specifico (probabilmente proprio deepMiner).

Ma conn.js, che, ricordiamo, viene eseguito nel contesto di ogni pagina visitata dalla vittima, potrebbe fare molto di più.

Dal C2 si ricavano infatti i file conn.php (l’endpoint lato server usato da conn.js, anche se su un altro server) e home_ats.js. Quest’ultima è un’estensione di esempio, forse realmente usata precedente in una campagna sudamericana .

Da questi file si può evincere che l’architettura è pensata per fare da banking trojan, sostituendo importo ed iban nei bonifici effettuati dalla vittima.

Nella prima immagine si può osservare la routine utile per sostituire l’IBAN mentre nella seconda viene prelevato l’IBAN salvato su una risorsa remota.

Il file conn.php mostra come lato server i criminali dispongano di una serie di conti per il trasferimento di denaro:

Tornando all’estensione, si nota come essa contatti un ulteriore C2 https[:]//spectrafac.top/panel_m. “Main.js” a sua volta scarica altri due file chiamati “ok.js” e “conn.js”. Questi file con estensione .JS sembrano essere utilizzati per effettuare Man in the Browser (MITB), banking trojan e minare cripto monete mediante lo sfruttamento della CPU.

Il dialogo con il C2 e il rilascio di Raccoon Stealer

Dopo l’analisi dell’estensione, torniamo al C2. Un file denominato conn.php dialoga con un secondo DB, quello usato dalla botnet e dai banking trojan.

Dall’analisi degli header delle e-mail di malspam, è ipotizzabile che alcune macchine siano state compromesse in una campagna precedente e riutilizzate per da vita a questa nuova campagna.

Inoltre, analisi successive hanno evidenziato che anche gli autori della campagna siano caduti in parte vittima del loro stesso malware, le password rubate infatti contengono le credenziali di un account Jabber di exploit[.]im:

Queste credenziali sono state usate per accedere ad un ulteriore servizio “cryptor[.]biz” che espone altri file malevoli di cui uno è stato rilevato nel corso dell’analisi del file “Try.exe”.

Quest’ultimo infatti rilascia un ulteriore file sulla macchina compromessa. L’informazione è visibile impostando un breakpoint su VirtualProtect come di seguito riportato.

Mettendo a confronto il file rilasciato dal task “Try.exe” e il file “Builder_original.exe”, che si possono ricavare da cryptor[.]biz, possiamo vedere come i due sample risultano essere identici.

Questo file che contiene lo stesso payload di ss.exe che ricordiamo essere riconducibile a Raccoon Stealer.

Infografica

Azioni e obiettivi

Osservando a ritroso le vittime della campagna malspam che sembra essere iniziata lo scorso12 novembre 2021, analizzando le email usate per il delivery e i domini utilizzati come C2, sembra essere totalmente italiana con target specifici come gestori di strutture ricettive, assicurazioni, banche, agenzie viaggi o, più in generale, il settore del commercio, turismo e servizi. Tra questi si ha evidenza che anche la PA nazionale risulta tra i target di questa campagna.

Indicatori di compromissione

Il CERT-AGID ha già condiviso i relativi IoC attraverso la sue piattaforme per favorirne la loro diffusione.

Al fine di rendere pubblici i dettagli di questa campagna si riportano di seguito gli indicatori rilevati:

Link: Download IoC