Prefazione
In questa analisi esaminerò nel dettaglio tutti i passaggi di un’infezione reale che ho gestito per conto di un cliente.
L’attacco ha avuto origine da un’email di phishing inviata da un mittente noto, che faceva riferimento a conversazioni precedenti per conferire credibilità al messaggio. L’email conteneva un link a un file ospitato su MediaFire, un servizio di file sharing in cloud.
Dopo aver cliccato sul link, l’antivirus del firewall perimetrale ha bloccato il download e mi ha notificato l’accaduto. Scongiurato il pericolo e avvisato l’utente, ho deciso di approfondire l’analisi. Ho quindi scaricato il file in un ambiente sicuro, scoprendo che si trattava di un archivio .lzh, un formato di compressione piuttosto obsoleto ma ancora supportato da Windows.
Poiché il formato LZH è poco utilizzato, alcuni filtri anti-spam o soluzioni di sicurezza potrebbero non identificarlo immediatamente come una minaccia, consentendo così il passaggio dell’allegato attraverso i controlli. Anche se in questo caso il pericolo è stato evitato, la scelta di un formato così datato da parte dell’attaccante ha destato il mio interesse.
Primo stage: il primo droppler
Il codice utilizza una tecnica di offuscamento che prevede l’inserimento di una sequenza specifica di caratteri Unicode all’interno di stringhe cruciali. Questi caratteri non hanno un significato funzionale e vengono inseriti per “confondere” chi cerca di leggere il codice manualmente.
Rimuovendo la sequenza di caratteri di offuscamento (mediante split e join), la stringa diventa “MSXML2.XMLHTTP”, ossia l’oggetto ActiveX utilizzato per le richieste HTTP (un vettore d’attacco ormai obsoleto, ma ancora presente).
Il codice utilizza lo stesso meccanismo di offuscamento per costruire l’URL da cui scaricare ulteriori istruzioni o payload, nel dettaglio la direttiva replace elimina tutti i caratteri che creano il “rumore di fondo”.
La ricostruzione pertanto risulta relativamente semplice una volta capito come procedere
cioè: https://paste.ee/d/rFiHqF7I
Secondo stage: il secondo droppler
Seguendo l’url di uscita il sistema scarica un file JavaScript di circa 1,2MB il quale presenta una serie di istruzioni “spazzatura”, cioè non di interesse per l’analisi ma atte unicamente a creare confusione a chi le vuole analizzare.
Le espressioni come ([]["pigopolies"]+[]) si basano su:
[]["pigopolies"]→ Un tentativo di accedere a una proprietà inesistente di un array vuoto ([]). Questo restituisceundefined.([]["pigopolies"]+[])→ Concatenandoundefinedcon un array (+[]forza la conversione in stringa), otteniamo"undefined".([]["pigopolies"]+[])[0]→ Il primo carattere di"undefined"è"u".
Questo schema si ripete per ciascuna proprietà inesistente, producendo la stringa "undefined" e prendendo successivamente il carattere in posizione crescente.
Di seguito una scomposizione più chiara:
jsCopiaModifica([]["pigopolies"]+[])[0] → "u"
([]["piscidine"]+[])[1] → "n"
([]["aonyx"]+[])[2] → "d"
([]["avengeresses"]+[])[3]→ "e"
([]["Calhoun"]+[])[4] → "f"
([]["bending"]+[])[5] → "i"
([]["reprising"]+[])[6] → "n"
([]["piscidineMap"]+[])[7]→ "e"
([]["homoiomerous"]+[])[8]→ "d"
([]["slice"]+[])[9] → " "
Concatenando questi caratteri, otteniamo: "undefined ". Spazzatura.
Passaggi più interessanti sono invece contenuti nella funzione chiamata “narcotization“
La variabile “guimbard“
e il set di istruzioni sottostante
Partendo da quest’ultimo set di istruzioni lo script concatena all’interno della variabile “atokal” una serie di caratteri Unicode e, mediante la funzione “narcotization” traduce (usando la stessa tecnica già analizzata in precedenza) la stringa in un comando powershell
il quale viene successivamente eseguito dalle istruzioni successive
L’esecuzione del comando Powershell consiste nel prendere la variabile guimbard (precedentemente mostrata) e sostiture la stringa “taluqdars” con il carattere “A” e successivamente decodificandolo da base64, portando di fatto il valore della variabile da così
a così
Terzo Stage: il trojan
Il terzo stage si apre quindi con la parametrizzazione vista poc’anzi: le righe 1 e 2 del listato portano la variabile psychographics al valore “0/B2xvooTx/d/ee.etsap//:sptth” che rovescitato risulta essere https://paste.ee/d/xToovx2B/0 (stesso dominio del precedente droppler ma diverso path).
La riga 3 continere un URL in chiaro di un’immagine jpg.
Andandola a scaricare questa è effettivamente un’immagine di dimensioni ragguardevoli e senza particolari meta dati in essa contenuti
Tornando allo script Powershell, le righe successive eseguono il download dell’immagine (righe 4 e 5) e, mediante la funzione “[System.Text.Encoding]::UTF8.GetString()” converte l’array di byte letti in una stringa in formato UTF-8.
La stringa in UTF-8 viene processata andando a cercare i valori <<BASE64_START>> e <<BASE64_STOP>> in essa contenuta. I byte contenuti tra questi due placeholder vengono quindi deoffuscati mediante la funzione “FromBase64String” (riga 15) e – alla riga 16 – tramite la direttiva System.Reflection.Assembly (funzione utilizzata per caricare un assembly .NET in memoria) eseguito il codice.
NOTA: questo metodo permette di eseguire codice contenuto in una DLL senza bisogno di scrivere file su disco.
L’ultima riga invoca la chiamata all’URL precedentemente visto nella riga 1 e 2.
Recap
Di seguito un recap generale per capire l’iter fino ad ora.
Stage 4a: la DLL
Nell’immagine sottostante il file “new_image.jpg” e “new_image_stage3.out”, quest’ultimo è la quota parte di codice base64 contenuta nel file originale.
La conversione del file base64 produce, come ci si aspettava, una DLL eseguibile
- MD5: ed62b50320398fde6393e47e51987e5f
- SHA-1: 897bbd0777e5d58e641cb94aea6a0b41d297cdf7
- SHA-256: e5daa86418ac444d590a2c693cd7749d87134c47d8e0dbac30c69f23a8e8131f
Stage 4b: il payload
Seguendo il link processato all’ultimo stadio (https://paste.ee/d/xToovx2B/0) questo restituisce un file base64 che, tradotto, si rivela un chunk di dati binari.
- MD5 d2724aae0943020c4432ef5c86522175
- SHA-1: 4f8b5395a5a0e4f96799b7465a533845554ebb17
- SHA-256: 77bf7e045a2882a1bb197ef2a3e40d2907021d722e55bfa79ed3177d5bf6f6cd
Stage cinque: informazioni e metadati
L’analisi statica è una tecnica che si concentra sull’esame del codice binario di un software malevolo senza eseguirlo. Questo processo permette ai ricercatori di disassemblare e analizzare il codice per identificare le sue funzionalità, le tecniche di offuscamento utilizzate, le potenziali vulnerabilità che sfrutta e gli indicatori di compromissione (IOC) associati. Attraverso l’analisi statica, è possibile ottenere informazioni cruciali sul comportamento del malware, sulla sua struttura e sulle sue capacità, facilitando la comprensione della minaccia e lo sviluppo di contromisure efficaci, come firme antivirus e sistemi di rilevamento delle intrusioni.
| Informazioni | Metadati |
 |  |
Qui finisce la prima parte dell’articolo, abbiamo quindi visto tutte le fasi dell’infezione e dissezionato ogni singolo passaggio per capirne il suo funzionamento.
Nel prossimo articolo cercherò di analizzare la DLL, con ogni probabilità si tratterà di un’ulteriore stage intermedio per creare persistenza all’interno del sistema mediante il Task Scheduler.
EOF