IcedID, analisi di un caso reale

Preludio

Tutto parte da un’email di phishing contenente un allegato .zip.
La mail riporta i seguenti dati

Da:      mario.rossi@dominio_conosciuto.com
Date:    mer 29 dic 2021 alle ore 14:17
Subject: Re: Re: richiesta di quotazione
To:      destinatario@nomeazienda.com

Hello,
Important information for you. Please, see the attachment.

Password - 4y45h

Thanks
Best regards
Mario Rossi
Inviato da Mario

Il destinatario conosce Mario (per ragioni lavorative si scambiano diverse mail alla settimana) e la mail è stata effettivamente inviata dal dominio che il destinatario conosce; tuttavia la corrispondenza fra di loro è sempre stata in italiano e in toni informali. Il destinatario si insospettisce, chiama il mittente il quale conferma di non aver inviato la mail.

La mail

Dall’analisi degli header della mail questa risulta essere spedita dal solito server di posta elettronica col quale @dominio_conosciuto.com invia quindi, come buona norma, è stata mia premura contattare l’IT del corrispondente che gestisce il server informandolo dell’accaduto.

Il file allegato risulta essere effettivamente un file zip (Info.zip) il quale, una volta estratto utilizzando la password, estrae un solo file .doc (statistics.12.21.doc).

Aprendo il file si viene avvisati che questo contiene macro, le quali sono disabilitate di default. Il file si presenta così:

Img. 1 – Come si presenta il file non appena aperto

Prima di entrare nel vivo della macro ho controllato i meta dati del file dal quale ho estratto qualche altra informazione interessante

Img. 2 – Meta dati del file word

Per primissima cosa il file sembra essere stato creato due giorni prima di essere stato inviato e la data di ultimo salvataggio coincide con quella di creazione: si evince quindi che il tutto era stato già precedentemente confezionato.

Nota più interessante il numero di parole e di caratteri: il file si presenta “a prima vista” come il classico documento vuoto con solo l’immagine presente ma i meta dati confermano esserci un testo nascosto: selezionato tutto il contenuto del documento e impostato un colore font, ecco comparire i caratteri contati e non visibili

Img 3 – File doc, modificato impostando un colore al font

Ovviamente si tratta di un codice offuscato e quindi incomprensibile. Procediamo dunque con l’analisi della macro.

La macro

Img. 4 – Codice della macro

La macro è tutto sommato semplice. Volendola riassumere, alla sua esecuzione, questa esegue la sub routine chiamata “hny” la quale salva su un file .hta (i7Table.h + l’attributo “comments” del file che equivale a “ta” – vedi immagine 2) il contenuto del file word andando a sostituire la stringa “s3x” con “”.

NOTA
L'estensione del file HTA è un formato di file utilizzato nelle applicazioni html. Un file HTA viene eseguito tramite il processo mshta.exe senza essere limitato ai fattori limitanti del contesto di sicurezza del browser e quindi viene trattato come un'applicazione attendibile.

Successivamente la funzione srn1 (la quale riceve come parametro il nome del file appena generato) esegue lo script mediante la direttiva

wscript.shell application <nome_file.hta>
Img. 5

I dati offuscati vengono prelevati dai meta dati del documento, vedi immagine 6

Img. 6 – Meta dati completi

i7Table.hta

Il file creato è un HTML contenente una serie di direttive atte ad eseguire il codice codificato in base64

Img. 7 – File .hta nella sua forma originale

Decodificate le stringhe evidenziate appare un codice il quale, seguendo le direttive del codice originale, viene “capovolto”…

Img. 8 – Testo decodificato da base64

…concatenato e “ribaltato”. Al termine il codice risulta essere questo

Img. 9 – Script decodificato

In ordine lo script:

  1. esegue una chiamata all’URL indicato al punto 1
  2. salva nella directory c:\users\public\ un file chiamato asusGigabyteI7.jpg
  3. registra la DLL regsvr32 appena scaricata

Ovviamente il file scaricato ha solo come estensione JPG, in realtà è una DLL

Img. 10 – La DLL

Dettagli hash file:

MD5	11b28ecbd7ade350eee6d25b6fae707c
SHA-1	10e85bf7c61223f43d0d2fdebd4c5a35a5156539
SHA-256	8578d45fd02aceddc838ff94e21b10a29deb3e2cc92099c9b54802504c88a56a

Provando a caricare il file su virustotal.com questo viene riconosciuto come trojan, la KB di Fortinet lo codifica come W64/GenKryptik.EE28!tr, tuttavia non sono riuscito a trovare molte altre informazioni in giro per la rete.

Stessa informazione per quanto concerne il dominio dal quale la DLL è stata scaricata (metaljeffersond[.]com)

Img. 11 – Output dal sito virustotal.com

Per pura curiosità ho fatto un’azione di scraping ricorsiva su tutto l’URL e mi sono accorto che, al path “SY9GOjnEyj3uiMaOM6bIc55Lj” il server restituisce un output binario.

Img. 12 – Scraping URL

Anche questo secondo file è una DLL e, eseguendo un hash dei due file, si nota come questi siano due file diversi.

  • mal_0.dll è il file scaricato dalla macro (ex asusGigabyteI7.jpg)
  • mal_1.dll è il file scaricato dallo scraping web
Img. 13 – I file comparati
Img. 14 – Le due DLL a confronto. La seconda è più recente di qualche ora

Cercando questo secondo hash su virustotal questo non restituisce alcun risultato.

Analisi file asusGigabyteI7.jpg (mal_0.dll)

La DLL non ha header CLR, pertanto possiamo escludere tool come “ildasm” o “dotPeek” in quanto potrebbero venir in auto solo se la DLL usa estensioni di .NET.

Img. 15 – Le librerie utilizzate dalla DLL

La libreria importa dalle seguenti DLL di sistema svariate funzioni legate al funzionamento del software malevolo

  • KERNEL32 (funzioni del SO di basso livello per la gestione della memoria e delle risorse)
  • SHELL32 (funzioni dell’API di Windows Shell utilizzate durante l’apertura di pagine web e file)
  • USER32 (funzioni di gestione di Windows per la gestione dei messaggi, timer, menu e comunicazioni)
  • OLE32 (libreria che mette a disposizione gli oggetti COM)
  • GDI32 (Graphics Device Interface per l’output del dispositivo)

Qui l’elenco completo

Name					Library
GdiFlush				GDI32
GetLogicalDrives			KERNEL32
GetOEMCP				KERNEL32
GetCurrentProcess			KERNEL32
GetThreadErrorMode			KERNEL32
GetUserDefaultLangID			KERNEL32
GetUserDefaultUILanguage		KERNEL32
FlushProcessWriteBuffers		KERNEL32
GetCurrentThreadId			KERNEL32
IsSystemResumeAutomatic			KERNEL32
GetSystemDefaultLangID			KERNEL32
GetCommandLineA				KERNEL32
GetTickCount64				KERNEL32
GetLastError				KERNEL32
TlsAlloc				KERNEL32
SwitchToThread				KERNEL32
GetErrorMode				KERNEL32
UnregisterApplicationRestart		KERNEL32
SetFileApisToOEM			KERNEL32
GetTickCount				KERNEL32
GetEnvironmentStringsW			KERNEL32
IsDebuggerPresent			KERNEL32
GetCommandLineW				KERNEL32
GetSystemDefaultUILanguage		KERNEL32
GetLargePageMinimum			KERNEL32
UnregisterApplicationRecoveryCallback	KERNEL32
GetACP					KERNEL32
GetThreadUILanguage			KERNEL32
GetCurrentThread			KERNEL32
GetCurrentProcessorNumber		KERNEL32
VirtualProtect				KERNEL32
AreFileApisANSI				KERNEL32
GetThreadLocale				KERNEL32
ExitProcess				KERNEL32
WriteConsoleW				KERNEL32
CloseHandle				KERNEL32
CreateFileW				KERNEL32
SetFilePointerEx			KERNEL32
GetConsoleMode				KERNEL32
GetConsoleCP				KERNEL32
WriteFile				KERNEL32
FlushFileBuffers			KERNEL32
SetStdHandle				KERNEL32
HeapReAlloc				KERNEL32
HeapSize				KERNEL32
GetStringTypeW				KERNEL32
GetFileType				KERNEL32
GetStdHandle				KERNEL32
GetProcessHeap				KERNEL32
LCMapStringW				KERNEL32
VirtualAlloc				KERNEL32
FreeEnvironmentStringsW			KERNEL32
WideCharToMultiByte			KERNEL32
MultiByteToWideChar			KERNEL32
GetCPInfo				KERNEL32
IsValidCodePage				KERNEL32
QueryPerformanceCounter			KERNEL32
GetCurrentProcessId			KERNEL32
GetSystemTimeAsFileTime			KERNEL32
InitializeSListHead			KERNEL32
RtlCaptureContext			KERNEL32
RtlLookupFunctionEntry			KERNEL32
RtlVirtualUnwind			KERNEL32
UnhandledExceptionFilter		KERNEL32
SetUnhandledExceptionFilter		KERNEL32
GetStartupInfoW				KERNEL32
IsProcessorFeaturePresent		KERNEL32
GetModuleHandleW			KERNEL32
RtlUnwindEx				KERNEL32
InterlockedFlushSList			KERNEL32
SetLastError				KERNEL32
EnterCriticalSection			KERNEL32
LeaveCriticalSection			KERNEL32
DeleteCriticalSection			KERNEL32
InitializeCriticalSectionAndSpinCount	KERNEL32
TlsGetValue				KERNEL32
TlsSetValue				KERNEL32
TlsFree					KERNEL32
FreeLibrary				KERNEL32
GetProcAddress				KERNEL32
LoadLibraryExW				KERNEL32
EncodePointer				KERNEL32
RaiseException				KERNEL32
RtlPcToFileHeader			KERNEL32
TerminateProcess			KERNEL32
GetModuleHandleExW			KERNEL32
GetModuleFileNameW			KERNEL32
HeapAlloc				KERNEL32
HeapFree				KERNEL32
FindClose				KERNEL32
FindFirstFileExW			KERNEL32
FindNextFileW				KERNEL32
InitNetworkAddressControl		SHELL32
CreateMenu				USER32
GetProcessWindowStation			USER32
SetProcessDPIAware			USER32
GetFocus				USER32
CloseClipboard				USER32
EmptyClipboard				USER32
IsProcessDPIAware			USER32
GetDialogBaseUnits			USER32
GetMessageExtraInfo			USER32
GetClipboardViewer			USER32
GetOpenClipboardWindow			USER32
GetCursor				USER32
GetShellWindow				USER32
GetActiveWindow				USER32
AnyPopup				USER32
InSendMessage				USER32
GetCapture				USER32
GetMenuCheckMarkDimensions		USER32
CountClipboardFormats			USER32
GetForegroundWindow			USER32
GetMessageTime				USER32
IsWow64Message				USER32
DestroyCaret				USER32
GetClipboardSequenceNumber		USER32
GetDesktopWindow			USER32
CoUninitialize				ole32
CoFreeUnusedLibraries			ole32
OleUninitialize				ole32

Il manifesto dell’applicazione si presenta così: dalla versione asm si può presumere essere stato scritto in C++

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

L’estrazione delle stringhe ASCII, oltre a riportare in chiaro tutte le funzioni alle librerie sopra elencate e il manifest, mostra una stringa che si ripete svariate volte

Img. 16

Non mi soffermo troppo su queste stringhe in quanto UVWATAUAVAWH (e similari) sembra essere la stringa più popolare estratta da tutti i file del sistema operativo .exe, .dll e .sys in Windows a 64 bit. La stringa è così popolare e allo stesso tempo sospetta tanto che, se la si cerca su Google, si potranno trovare persone che teorizzano che abbia qualcosa a che fare con i BSOD o che addirittura faccia parte di un linguaggio segreto interno di ZeroAccess.
Lasciamo stare questa strada legata alla “fanta informatica”: per chi fosse interessato lascio qui un link che ne parla.

Sandbox – analisi di sistema e processo

Il passo successivo è stato quello di creare una sandbox (Windows 10 x64) ed eseguire la registrazione della DLL.
Per prima cosa, a sistema operativo “pulito”, ho estratto tutte le voci dal registro di sistema. Successivamente ho registrato la DLL e ri-estratto il contenuto di tutto il registro per verificarne le modifiche apportate.

La prima cosa che si nota è la differenza di dimensione: il registro si presenta di dimensioni ridotte rispetto alla versione originale (~10MB in meno). Il processo in debug legge 128 chiavi di registro quasi tutte atte ad enumerare i certificati installati a sistema.

Provando a processare la DLL sul sito Analyze Intezer, troviamo poche corrispondenze con altri e ben noti loader.

Lato file system nessun file è stato creato o modificato al momento della registrazione (vedremo dopo perché).

Sandbox – analisi traffico di rete

Appena la DLL viene registrata il processo regsvr32 tenta una chiamata all’IP 45.41.204.139 alla porta 80/HTTP

Img 17 – Traffico subito dopo la registrazione

Andando a sniffare il traffico di rete si evidenzia la chiamata verso l’host vopnoz.com

Img. 18 – HTTP request

…e la relativa risposta

Img. 19 – HTTP response

La chiamata non va a buon fine (il server restituisce un errore 404) sebbene l’host sia – al momento della scrittura di questo articolo – ancora online.

Provando a ricercare l’indirizzo su virustotal.com questo risulta essere già stato segnalato dai primi di Dicembre 2021 come C2 per distribuire una nuova variante del malware noto come IcedID, qui una panoramica per capire meglio di cosa si tratta (italiano).

A differenza del più noto BazarLoader, questa non include alcun user-agent nella request. Quest’ultima tecnica è un modo per aggirare le soluzioni di sicurezza durante il download del file dannoso. L’utilizzo di questa tecnica potrebbe far sembrare le comunicazioni legittime rendendo di fatto il processo di ricerca più complesso da individuare.

Considerazione personale

Arrivati a questo punto – (s)fortunatamente – possiamo dire che non ci sono ulteriori elementi per poter continuare questa analisi, riassumendo in punti la logica di attacco è stata:

  1. ricezione della mail con allegato malevolo
  2. esecuzione della macro MS Word
  3. dump su disco ed esecuzione del file .hta generato, quindi:
    1. download dall’host metaljefferson.com il file DLL asusGigabyteI7.jpg
    2. registrazione della DLL
      1. esecuzione fallita della GET verso l’host vopnoz.com

Analisi file mal_1.dll

Nessuna differenza riscontrata da quanto riportato fin’ora.

Come difendersi?

Non cadere nella trappola del social engineering è sempre l’ABC e la prima linea di difesa. Anche se l’e-mail proviene da qualcuno che conosci o il thread sembra familiare. Se non ti aspettavi l’e-mail specifica, se è arrivata in un momento strano o se contiene altre funzionalità sospette, non fare clic su alcun collegamento o file ad essa allegato.

Un file protetto da password dovrebbe destare sospetti, sempre. Gli hacker sono consapevoli che i file protetti da password sono più complessi da scansionare per le soluzioni di sicurezza e quindi li usano frequentemente per inviare contenuti dannosi. Nel caso in cui ricevi un file di questo tipo (potrebbe essere un ZIP, PDF o qualsiasi altro tipo di file) sii sospettoso e controlla attentamente prima di fare clic su di esso. Poniti sempre le domande: è probabile che il mittente ti invii questo tipo di file? Ha senso che questo file sia protetto da password? Ti aspettavi questa email?

La maggior parte delle soluzioni di protezione e-mail attualmente sul mercato si basano su reputazione o modelli e tendono a “fidarsi” di mittenti affidabili piuttosto che eseguire una scansione approfondita di tutte le e-mail che arrivano da loro. Ecco come queste soluzioni evitano scansioni “non necessarie” di quelle che vengono percepite come e-mail a basso rischio. Come già sappiamo, questa tecnica di solito sfrutta i thread di posta elettronica esistenti che sono considerati sicuri. Pertanto, molte soluzioni di sicurezza e-mail non eseguiranno nemmeno la scansione di queste e-mail dannose. Nel caso qui descritto, l’e-mail proviene da una fonte attendibile e quindi avrebbe facilmente aggirato le soluzioni di sicurezza che si basano sulla reputazione. Per proteggersi da questi attacchi (o altri) che utilizzano tecniche simili, implementare una soluzione avanzata di protezione dalle minacce che esegue la scansione di tutte le e-mail prima di entrare nell’organizzazione, inclusi tutti i collegamenti e gli allegati.

Si consiglia di bloccare il più possibile l’uso di mshta.exe in tutta l’organizzazione poiché questo è il componente che consente al trojan di eseguire il file “dumpato” dalla macro iniziale. Fortunatamente, nella maggior parte dei casi, mshta.exe non ha un uso sostanziale nel lavoro quotidiano, quindi è meglio averlo neutralizzato.

EOF

2 commenti su “IcedID, analisi di un caso reale”

Lascia un commento