Elementi importanti dell’analisi:

• Utilizzo del linguaggio Go
• Enumerazione dei dischi della macchina infetta
• Funzione di wiping main.wipe
• Distruzione di Windows\\NTDS
• Evidenze di environment information discovery e logging
• Utilizzo di threads
• Esecuzioni di processi e comandi esterni
• Esecuzioni di comandi di modifica di permessi e accessi

Sommario

INTRODUZIONE:………………………………….. 1

ANALISI STATICA…………………………………. 2

DECOMPILING, DEBUGGING ED ANALISI DINAMICA…………………………………..24

Riferimenti:……………………………42

IOCs:…………………………….42

Regola YARA:……………………………………..42

CONCLUSIONI:………………………………….42

INTRODUZIONE:

SwiftSlicer è un nuovo wiper malware, sviluppato da gruppi di Cyber-criminali russi per attaccare targets ucraini, l’ennesimo elemento cyberthreat che va di pari passo con la crisi geopolitica attuale che intercorre tra i due Paesi. E’ evidente che queste cyber gangs non hanno più come obiettivo solo la cifratura dei dati delle vittime e la richiesta di un riscatto per la loro decrittografia ma anche, come è stato visto del resto anche con Hermetic Wiper, la distruzione completa di files e dei domini di sistema delle infrastrutture target colpite.

Matrice TTPs SwiftSlicer:

ANALISI STATICA

Nella presente analisi è stato analizzato un sample SwiftSlicer avente hash fee7c379f3a555c5c821e872ec384a91, sviluppato e compilato con Go 1.15.0, linguaggio di programmazione non molto comune in ambito di malware development.

Qui i dettagli dell’entropia delle sezioni di SwiftSlicer:

A seguire alcuni dettagli di un listato di disassembling della minaccia, ove si possono notare diverse istruzioni INT3, utilizzabili in alcuni contesti al fine di disporre anti-debugging attraverso la generazione di eccezioni d’esecuzione, ma anche istruzioni di jump, come chiamate ad istruzioni JE (Jump Equal) e JNE (Jump Not Equal) con l’aggiunta di istruzioni di “compare”, quindi di checking:

Qui alcuni dettagli della mappatura di memoria del threat:

All’interno delle sezioni .text e .data vi sono riferimenti precisi all’ID della build Go, utilizzata per compilare l’artefatto:

Nella sezione .rdata sono individuabili stringhe relative a permissions, random generations e sockets routines:

All’interno della sezione .idata vi sono invece riferimenti a chiamate di gestione di indirizzi di memoria virtuali e scrittura di files tramite la funzione WriteFile:

Mediante le stringhe estraibili dalla minaccia è possibile evidenziare la presenza di enumerazione di dischi della macchina infetta:

L’unico import individuabile è Kernel32.dll, libreria che viene impiegata al fine di disporre esecuzioni concorrenziali e gestione di threads, fra cui anche la funzione CreateWaitableTimerExW, che permette di creare un oggetto di tipo timer:

Fra le stringhe estratte è possibile notare symbols importanti, tra cui ad esempio chmod (che permette di gestire i permessi d’accesso), bitLen, delete, privileges, threadLock, timersLock e numerosi riferimenti alla libreria GoLang *os., utilizzata ad esempio per gestire l’esecuzione e il lancio di processi o librerie DLL esterne. Ciò permette a SwiftSlicer di mettere in atto esecuzioni di tipologia multistaging infection.

Vi sono diversi riferimenti alle opzioni e statistiche della CPU, proprio a causa del fatto che il threat pone attenzione ad esecuzioni multithreading e alla concorrenzialità:

Di seguito alcuni dettagli di richiami alla libreria *.runtime di GoLang, che può essere utilizzata al fine di gestire e richiamare variabili d’ambiente e permette di interagire con il runtime system di GoLang:

A seguire un dettaglio fondamentale che rappresenta come SwiftSlicer effettui environment information discovery, nel caso specifico è possibile osservare l’utilizzo della funzione GetUserProfileDirectory, che permette di ottenere informazioni della root directory dell’utenza in questione:

A seguire, evidenziate, alcune stringhe degne di nota: winCallbackKey (richiamata dalla libreria runtime) permette di ottenere informazioni e dettagli in merito ai keystrokes registrati a bordo della macchina compromessa, nonché la presenza della chiamata a funzione *exec.Cmd, la quale permette di eseguire comandi esterni:

Qui alcuni dettagli riferibili a processi zombie, che pur essendo potenzialmente terminati, possiedono PIDs e process control blocks ed un’evidenza che richiama la funzione LockFileEx, che permette di ottenere un accesso esclusivo ai files presi in considerazione dal processo sorgente:

Qui un dettaglio che permette di associare l’origine di SwiftSlicer alla Russia, in quanto tra le timezones specificate, vi è proprio quella russa:

La libreria runtime viene impiegata anche per allocare memoria nella cache all’interno della sovrastruttura d’esecuzione di GoLang:

A seguire dettagli di richiami alla libreria netpoll, utilizzabile per tasks di network polling, nello specifico è di seguito evidenziata una chiamata alla funzione runtime.pollInfo.expiredWriteDeadLine, per le operazioni di scrittura:

Qui un’evidenza inerente alla funzione runtime.isAsyncSafePoint, la quale permette di controllare se le condizioni attuali dello stack ed i registri potrebbero consentire chiamate di funzioni asincrone:

SwiftSlicer fa uso della funzione runtime.gosched_m al fine di disporre esecuzioni programmate nel momento in cui le stesse giungono al punto di richiamo in questione:

Di seguito importanti riferimenti d’esecuzione della minaccia, dove si possono osservare richiami al caricamento di librerie di sistema esterne e l’esecuzione di processi ed in particolare la funzione syscall.makeCmdLine permette di impostare attributi del comando d’esecuzione di processi all’interno dell’infection cycle:

Qui si evince l’utilizzo della libreria syscall nei contesti di files finding, creazione di processi mediante user instances ed enumerazione di chiavi di registro di sistema:

A seguire i riferimenti a FileMode, utilizzabile durante le fasi di files enumeration e wiping, nonché il controllo effettuato per verificare che un elemento specifico sia una directory. Qui, inoltre, diversi dettagli in merito alla gestione di mutexes e process waiting:

SwiftSlicer richiama la funzione exec.lookExtensions al fine di identificare files eseguibili all’interno di una directory specifica, indicata come parametro. Si notano anche richiami alla funzione os.(*Process).kill per terminare i processi:

Qui alcune stringhe fondamentali inerenti al core della minaccia presa in esame: la funzione main.wipe, che si occupa della distruzione di files ed elementi di sistema; contestualmente vi sono riferimenti a process tokens, process privileges, tra cui la funzione main.enableDisableProcessPrivilege, all’enumerazione di drives di sistema con main.drives e main.paths:

 A seguire riferimenti a executable.go, che ritorna il path dell’eseguibile che ha lanciato il processo corrente:

DECOMPILING, DEBUGGING ED ANALISI DINAMICA

Di seguito i dettagli di estrazione delle stringhe più interessanti dall’artefatto malevolo dalla sezione .rdata, già espletate in precedenza.

Qui i dettagli dei riferimenti ai comandi chmod e chown, utilizzabili al fine di gestire gli accessi e permessi a determinati files:

Di seguito evidenze a riferimenti a WriteBuffers:

Qui oggetti timers e threads:

Negli screenshots sottostanti è possibile notare riferimenti ad un oggetto Logger per il logging di esecuzioni, processi, DLLs, directories ed attributi di files:

Qui è possibile evidenziare un richiamo alla funzione FindNextFile, utilizzabile per azioni di files enumeration:

 A seguire un dettaglio che si riferisce ad oggetti di user tokens, utilizzabili per privileges management:

Di seguito un richiamo alla funzione *syscall.RawSockaddr, riferibile all’utilizzo di oggetti sockets per connection routines:

A seguire le particolarità di quella che sembrerebbe essere una configuration di GoLang e dichiarazioni di variabili e valori, ad esempio la variabile “p”, includendo anche attributi di maximum e l’estensione “.exe3125”:

A seguire un ulteriore riferimento alle performance ed indicatori della CPU e dei processi zombie:

Qui le funzioni di sockets connection, come ad esempio WSARecv, WSASend, getsockname e getpeername:

SwiftSlicer provvede a distruggere il contenuto di Windows\\NTDS, a seguire il riferimento in questione:

Qui un riferimento in merito alla funzione AddDllDirectory, utilizzabile al fine di aggiungere una directory al process DLL search path e riferimenti a funzioni di registry keys usage:

Qui sotto un riferimento a quella che sembra essere un’operazione di skipping di una directory tra quelle enumerate:

Un dettaglio curioso, quanto particolare, è un riferimento alla seguente cifra, che rappresenta un valore inerente ad operazioni algebriche di esponenziale modulare, relativo ad algoritmi di cifratura RSA:

Il riferimento della stringa seguente evidenziata, inerente a MMX support, è relativa alla compilazione GoLang:

A seguire un ulteriore riferimento alla funzione principale di infezione main.wipe:

Effettuando una sessione di malware static inspection è possibile osservare le seguenti peculiarità sospette: compilazione di timestamp corrisponde all’anno 0 Unix (31 Dicembre 1969), network discovery, file management, memory (gestione di indirizzi di memoria virtuali ed allocazione della cache di memoria), environment information gathering, keyboard logging ed elementi di encoding:

Fra le sezioni del threat è presente anche “.symtab”, utilizzabile al fine di salvare e localizzare definizioni e riferimenti dei symbols richiamati dal malware.

Tra le funzioni richiamate vi è evidenza della funzione SuspendThread, impiegata per porre in suspend status threads specifici:

Qui un riferimento alla funzione LoadLibraryA:

A seguire un dettaglio di disassembling della sezione .text, ove si può evincere un’istruzione di calling alla funzione della libreria Kernel32.dll WriteFile:

Effettuando una sessione di debugging e decompiling di SwiftSlicer vi è un’evidenza di ottenimento di informazioni del ComputerName, current threads, filepaths:

Qui si possono notare ulteriori evidenze in merito alla configuration, che include le estensioni .INF, .bat, .cmd, .com e .exe:

A seguire diversi riferimenti a resources locking e CPU information gathering:

Si noti il puntatore della variabile “p” all’attributo “status”, in tale contesto d’esecuzione vengono controllati elementi d’esecuzione, come ad esempio stacks e globals :

Dalla seguente istanza di decompilazione è possibile osservare i sopra citati cicli di files enumeration:

Durante la sessione di debugging è stato possibile osservare una sorta di injection delle seguenti esecuzioni di mutex locking e polling:

Qui possiamo notare l’indirizzo dell’entrypoint del Portable Executable:

All’interno del codice esadecimale del sample si notano riferimenti ad operazioni XOR, CmdLine ed esecuzioni mediante la libreria syscall:

A seguire altri riferimenti all’interno del codice esadecimale, comprendenti CmdLine, esecuzioni algebriche con numeri complessi e decimali in virgola mobile ed esecuzioni di processi esterni.

Negli screenshots sottostanti si evidenziano dettagli di decompiling inerenti alla funzione main.wipe. Nella sessione di decompiling in questione, in concomitanza con la call 0x00402526, si possono osservare istruzioni di loop:

All’interno di funzioni identificabili in tali contesti d’esecuzione, vi sono istruzioni nop, loop e decrementation:

Riferimenti:

[0] (immagine): Microsoft PowerPoint – Module-3-NumberTheory-RSA (jsums.edu)

IOCs:

• fee7c379f3a555c5c821e872ec384a91
• m=+Inf-Inf.bat.cmd.com.exe3125
• main.wipe
• 45474735088646411895751953125

Regola YARA:

rule SwiftSlicerRule {   

 strings:        

$swift_string = “main.wipe”

$swift_hex = { 6d 3d 2b 49 6e 66 2d 49 6e 66 2e 62 61 74 2e 63 6d 64 2e 63 6f 6d 2e 65 78 65 33 31 32 35}     

condition:        

$swift_string or $swift_hex

 }

CONCLUSIONI:

SwiftSlicer ha un obiettivo specifico: la distruzione completa di files target e domini di sistema delle infrastrutture colpite. E’ interessante notare riferimenti ad esecuzioni algebriche, parametri di configurazione che specificano tipologie di files eseguibili, nonché la presenza di riferimenti a funzioni inerenti a sockets e propagation. Fra le peculiarità della minaccia vi è anche l’evidenza di esecuzioni di hooking e funzioni di keylogging, ragion per cui è possibile ipotizzare che SwiftSlicer effettui, oltre tasks di wiping, anche environment ed information discovery e logging.

Verificando l’entropia e l’eventuale encoding status del source code e delle sezioni del Portable Executable, è stato possibile osservare come i malcoders non abbiano posto estrema attenzione ad azioni di masking ed hiding delle caratteristiche del malware. Ciò probabilmente a causa del fatto che, a differenza di minacce di tipo ransomware, nascondere ed effettuare shuffling degli attributi, in questo caso non è cruciale, dal momento che non vi sono subroutines critiche per l’infection chain che devono essere il più possibile inviolabili, come ad esempio l’utilizzo di oggetti riferibili a chiavi RSA in un contesto d’esecuzione vulnerabile.

Come descritto in precedenza, la minaccia è stata sviluppata in GoLang, questo probabilmente a causa del fatto che lo sviluppo mediante tale linguaggio di programmazione permette una gestione semplificata delle librerie esterne di terze parti, nonché un’implementazione più veloce e multiplatform.

Concludendo, questo tipo di minaccia è estremamente devastante in quanto, a differenza di un ransomware, ove l’azione malevola (la crittografia dei files) è potenzialmente reversibile, qui siamo di fronte ad un malicious code il cui unico scopo è quello di distruggere i files delle vittime.