Elementi importanti dell’analisi:

• Attack vector con vulnerabilità Fortinet VPN
• Auto-encryption del ransomware stesso per effettuare bypassing
• Cambio dinamico e consecutivo delle estensioni dei files criptati
• UPX packing
• Algoritmi OpenSSL, AES OCB, ChaCha20_Poly1305
• Scheduled tasks
• Esecuzioni di restart management
• Enumerazioni shares di rete
• Utilizzo del file C:\ProgramData\ntuser.dat per la chiave pubblica dell’auto-encryption
• Crittografia dei files in “buffers”

Introduzione

Cactus Ransomware è una nuova minaccia, identificata per la prima volta nel Marzo 2023, con alcune caratteristiche particolari. Viene distribuita nelle infrastrutture compromesse utilizzando principalmente come attack vector alcune vulnerabilità di Fortinet VPN che permettono un accesso non autorizzato. La caratteristica principale di questo ransomware è l’auto-encryption, ovvero la cifratura del medesimo avviene contestualmente alla fase di deployment e questo comporta il fatto che il threat non possa essere rilevato facilmente da EDR, XDR e antimalware. Durante il processo di encryption dei files target vengono modificate in modo dinamico le estensioni utilizzate, passando da .cts0 a .cts1. Durante la fase di esecuzione il malware controlla, similmente a ciò che avviene in un accesso concorrenziale, se un file è accessibile in un determinato momento o meno.

Il sample possiede il portale di data leak hxxps[://]cactusbloguuodvqjmnzlwetjlpj6aggc6iocwhuupb47laukux7ckid[.]onion, il quale contiene i dettagli delle varie vittime e dei dati ad esse relativi.

I canali di comunicazione dei malcoders risultano essere principalmente l’indirizzo e-mail cactus[@]mexicomail[.]com e la TOX Chat avente URL hxxps[://]tox[.]chat[/):]7367B422CD7498D5F2AAF33F58F67A332F8520CF0279A5FBB4611E0121AE421AE1D49ACEABB254686              

Analisi statica ed assessment

Il sample sottoposto ad analisi ha come hash 78c16de9fc07f1d0375a093903f86583a4e32037a7da8aa2f90ecb15c4862c17, esso è in stato di packed con il packer UPX.

Di seguito i dettagli delle sezioni del file, ove si evincono le caratteristiche delle sezioni relative al packer UPX e .rsrc.

All’interno della sezione Overlay, che contiene dati “appended” all’immagine del Portable Executable, vi sono riferimenti a funzioni di encryption come, ad esempio, ocb_decrypt e la sezione .rdata.

Sempre all’interno dell’Overlay data vi sono dettagli inerenti a quello che sembrerebbe essere un attributo booleano di controllo in merito ad un contesto di leaking.

Relativamente agli imports, possiamo evidenziare la libreria ADVAPI32.dll (per eseguire la funzione di event log appending ReportEventW), RstrtMgr.dll (per eseguire la funzione RmGetList per ottenere una lista delle applicazioni e dei servizi che utilizzano le risorse registrate all’interno della sessione di Restart Manager), WS2_32.dll e WSOCK32.dll (al fine di gestire connessioni tramite sockets).

Il coefficiente d’entropia più alto, dovuto alla fase di UPX packing, si attesta a 7.94368.

Il manifest del PE possiede un attributo di requestedExecutionLevel come “asInvoker”, ovvero viene eseguito con i medesimi permessi del token del parent process.

Dalle stringhe estraibili dall’eseguibile si notano riferimenti a CBC encryption routines e CBC decryption routines relativi all’algoritmo AES.

Di seguito i dettagli di alcuni oggetti di public key storage, per esempio EVP_PKEY_set1_encoded_public_key:

La funzione EVP_PKEY_verify_recover_init può essere utilizzata al fine di verificare la signature associata all’algoritmo per la chiave pubblica.

A seguire un dettaglio relativo all’ algoritmo chacha20_poly1305, viene evidenziato qui sotto l’oggetto cipher. L’algoritmo in questione è un mix tra ChaCha20 e Poly1305 e prevede un processo preliminare di authentication.

Nello screenshot sottostante sono invece evidenziate funzioni di loading della chiave privata associata a OpenSSL:

Qui di seguito la fase di unpacking UPX:

Dalle stringhe estratte vi sono dettagli inerenti a processi di authentication (lsass.exe e winlogon.exe), services.exe, la cartella ProgramData.

Cactus Ransomware effettua il bypassing della protection di Windows Defender, utilizza TOR Browser per il contatto con i malcoders, il file ntuser.dat (salvato nella cartella C:\ProgramData) viene utilizzato con lo scopo di archiviare la chiave per la crittografia del file eseguibile. Esso non rappresenta il file ntuser.dat originale di Windows ma piuttosto un file denominato in tal modo con tutta probabilità per effettuare evasion e confondere la natura del file stesso. Inoltre, lo script batch rn.bat viene con tutta probabilità utilizzato per la fase di rinomina di files. Il file di log C:\ProgramData\update.log viene utilizzato per tracciamento dell’infezione ransomware, mentre il threat minaccia anche la pubblicazione dei dati della vittima in caso di mancato pagamento del riscatto.

Cactus Ransomware crea uno scheduled task per la persistenza malevola denominato “Updates Check Task”

Qui un dettaglio di hashing digest MD5 e SHA1:

Si notino le funzioni IsFileFree (che viene utilizzata al fine di controllare se un determinato file si può criptare), canWriteDirectory (per controllare se una determinata cartella permette eventi di scrittura), killFileProcesses (con lo scopo di terminare i processi che occupano le risorse di un determinato file), weCanKillProcess (utilizzabile al fine di controllare se un determinato processo può essere terminato).

Analisi dinamica e disassembling

Contestualmente ad esecuzioni ChaCha20, all’interno della label loc_14010E1BE, vi sono numerose operazioni movaps, movdqa e movdqu inerenti a registri xmm

Vi sono riferimenti agli attributi N e 9 relativi ai registri xmm2, xmm9, xmm0 e xmm11.

A seguire un dettaglio inerente a caratteri presenti con attributi newline all’interno della sezione di exception management .xdata:

Cactus Ransomware effettua modifiche in merito al file di configurazione desktop.ini, per quanto riguarda il file di tracciamento update.log vengono anche aggiunti attributi di newline:

L’indirizzo e-mail cactus[@]mexicomail[.]com è l’indirizzo di contatto dei malcoders:

Qui una stringa di introduzione del file di readme del ransomware:

All’interno della funzione cryptFullFile è stata richiamata la funzione EVP_EncryptUpdate e funzioni di istream e ostream per la gestione degli attributi dei files presi in considerazione durante la fase di encryption:

Inizialmente viene “appesa” l’estensione “.cts0” ai files criptati:

Successivamente viene sostituita con l’estensione “.cts1”:

Vi è l’utilizzo della wildcard “*” per la gestione di filesystem enumeration:

Qui la funzione di enumerazione dei dischi della macchina compromessa:

A seguire i dettagli della funzione killFileProcesses che include la gestione del RestartManager per “liberare” le risorse dei files da criptare dai processi che li stanno (eventualmente) utilizzando.

Di seguito un riferimento che sembrerebbe essere associato all’accesso a network shares, nonché un accesso concorrenziale ai files da criptare, prendendo in considerazione gli attributi degli stessi ed attraverso una conferma booleana:

Qui il check dei longpaths da parte di Cactus Ransomware prendendo in considerazione gli UNC (Uniform Naming Convention) paths:

Lo script rn.bat viene molto probabilmente utilizzato in fase di rinomina dei files presi in considerazione durante l’infection kill chain:

La funzione extractDirPath ottiene i filenames dato un path specifico:

Cactus Ransomware possiede un attributo globale, il quale sembrerebbe far riferimento ad una blacklist di estensioni, difatti denominata extBlackList:

La funzione hexEncode prende come parametro in input la variabile var_178, utilizzata in un’istruzione lea con il registro rbp, per caricare l’indirizzo di memoria in questione:

La funzione makeNtUserFile risulta essere fondamentale al fine di salvare la stringa di crittografia del ransomware stesso in fase di post-infection-deployment:

Qui la wildcard “*”, utilizzata in fase di files enumeration loop per ottenere i files da sottoporre al processo di crittografia:

I files presi in considerazione vengono salvati in una variabile di filesArray, nel caso in cui vi siano errori di accesso agli stessi, viene prodotta una stringa di errore:

Qui un dettaglio di logging di infezione di un disco:

L’operazione di lettura del file C:\ProgramData\ntuser.dat risulta fondamentale per la decriptazione del ransomware stesso:

Qui, difatti, il riferimento all’ID di encryption del sample:

Second malware assessment

Tale sample di Cactus Ransomware è stato compilato il 24 Marzo 2023:

Gli indicatori sospetti del sample sono perlopiù relativi a TLS callbacks, estensioni euristicamente associabili ad infezioni Ransomware, il numero di symbols attributes, funzioni di encryption, network enumeration, compression routines, files management, reckoning ed environment discovery, Base64 encoding, Desktop configuration management, services management, password references e keyboard keys management.

L’entropia della sezione .text è 6.692:

Le librerie importate individuate come sospette risultano essere rstrtmgr.dll, ws2_32.dll e wsock32.dll:

Tra le funzioni da attenzionare vi sono ad esempio FindFirstFileW, GetCurrentProcessId, GetLogicalDriveStringsW, GetVolumeInformationW, MoveFileExW, RemoveDirectoryW, TerminateProcess, CryptAcquireContextW, CryptGenRandom, CryptReleaseContext, RegisterEventSourceW, RmRegisterResources, accept, bind, closesocket.

Di seguito un dettaglio riferibile all’attributo della chiave privata con il tipo di dati impostato a %d, ovvero intero decimale, vi sono inoltre attributi riferibili a stringhe relative ad indirizzi IP ed indirizzi e-mails.

L’entrypoint RVA (Relative Virtual Address) del sample preso in considerazione è 000013F0:

Qui i dettagli di alcune sezioni relative al processo di PE packing:

La funzione send di socket connections possiede come Import by Name raw 00522E1A:

All’interno del disassemblato della sezione .text è possibile evidenziare un’istruzione di call all’indirizzo 0x1403FAA00:

Vi sono poi riferimenti ad istruzioni di mov all’interno del registro RBP con diversi offsets:

L’OptionalHeader possiede come dimensioni 240, le sezioni del PE sono ben 14.

Le dimensioni dell’immagine completa risultano essere 67B000, mentre le dimensioni degli headers si attestano a 600:

Qui vi sono gli indirizzi relativi alle directories di export, import, resources, exceptions (sezione .xdata), security, debug.

La sezione di maggior dimensione risulta essere .text, contenente codice eseguibile:

Negli screenshots sottostanti vi sono evidenze fondamentali in merito ad alcune funzioni d’esecuzione malevola già citate inerenti al contesto di encryption, event log management, restart management, sockets connections management.

A seguire un riferimento a parametri ed indirizzi di eccezioni all’indirizzo 530180:

Qui un riferimento al comando di compilazione mingw:

Assembly dumping

Effettuando un dumping delle istruzioni assembly low level possiamo notare che nella funzione isFileFree vi è un oggetto di tryFileOpen.

All’indirizzo 0x140002ab7 viene eseguita un’istruzione di lea per caricare il memory address relativo al file ntuser.dat nel registro rax.

La funzione SearchFiles utilizza un ciclo di enumeration controllando il fullpath mediante la funzione checkingfullpath.

All’interno del registro rax viene caricato l’indirizzo di memoria relativo a cryptKey con un offset di 0x10.

Viene anche controllato nel caso in cui un file od una cartella esiste mediante la funzione std::filesystem::exists.

A seguire il caricamento del contenuto del readme di Cactus Ransomware all’indirizzo 0x140002a42:

Contestualmente alla cifratura dei files ottenuti dopo l’enumerazione dei medesimi viene definito un buffer di array dei files stessi criptati:

I dischi enumerati sulla macchina compromessa vengono salvati in un array:

Qui un dettaglio del caricamento della chiave RSA pubblica in formato PEM:

Qui la funzione di decrittografia AES, la quale tra gli attributi in input possiede EVP_CIPHER_CTX, ciphertext, ciphertext_len, key, iv e plaintext:

All’interno della funzione EVP_DecryptInit_ex viene salvato l’indirizzo di memoria dell’oggetto openssl_3.1.0_crypto_evp_evp_enc.c nel registro r13 all’indirizzo 0x14001b184.

Le strutture EVP_CIPHER_CTX_gettable_params e EVP_CIPHER_CTX_rand_key contengono rispettivamente gli attributi e parametri dell’oggetto di encryption ottenibili e la chiave pubblica generata randomicamente:

Contestualmente all’ottenimento della lunghezza della chiave del cipher viene eseguita un’istruzione di XOR del registro edx e successivamente una call ad una funzione di randomizzazione dei bytes della chiave privata ed una consequenziale istruzione XOR. In questo modo il valore del registro eax viene azzerato.

Qui i dettagli di un attributo booleano usato per controllare se un determinato processo può essere terminato o meno e le variabili di session key:

Qui i dettagli del codice esadecimale del sample analizzato, ove si evincono riferimenti a chars e strings management:

Sessione di debugging

A seguire alcuni dettagli della sessione di debugging effettuata, ove si notano riferimenti al file TXT di readme di Cactus Ransomware, l’ID univoco dell’infezione ransomware, un riferimento a TOX chat per il contatto con i malcoders:

Nel caso in cui vengano presi in considerazione files e folders da non cifrare essi vengono “saltati” dal processo di encryption.

Qui i dettagli di alcune stringhe individuabili in un contesto di debugging, soprattutto in merito al file ntuser.dat, scheduled tasks, la cartella C:\ProgramData e la stringa di crittografia del ransomware stesso.

Il file C:\ProgramData\ntuser.dat contiene una stringa randomica che fa riferimento alla stringa di encryption del ransomware sample:

Qui i dettagli ASCII ed esadecimali dei processi presi in considerazione dall’infection kill chain e il richiamo della funzione di AES_init_key:

Qui possiamo notare encryption attributes di OpenSSL e ChaCha20Poly1305:

Si notino i dettagli in merito all’encryption routine Blake2 e l’inserimento della chiave privata con i tipi di dati %s (string) e %C (caratteri).

Il sample è riconosciuto come malevolo dalle fonti OSINT ed identificato come trojan.cactus/genericfca:

Qui un dettaglio di un key finding attempt mediante la stringa randomica inserita nel file C:\ProgramData\ntuser.dat: 

Effettuando una decodifica dall’esadecimale della stringa in questione è possibile identificare il dominio di Freedom of Information Act ed il dominio justice[.]gov. Tuttavia, con i pattern successivi essa dovrebbe contenere la sottostringa utilizzata come chiave pubblica per la cifratura del ransomware.

IOCs:

• 78c16de9fc07f1d0375a093903f86583a4e32037a7da8aa2f90ecb15c4862c17
• cb570234349507a204c558fc8c4ecf713e2c0ac3
• e28db6a65da2ebcf304873c9a5ed086d
• Updates Check Task scheduled task
• CaCtUs.ReAdMe.txt
• cactus[@]mexicomail[.]com
• TOX Chat ID: 7367B422CD7498D5F2AAF33F58F67A332F8520CF0279A5FBB4611E0121AE421AE1D49ACEABB254686
• cactus787835[@]proton[.]me 
• cactusbloguuodvqjmnzlwetjlpj6aggc6iocwhuupb47laukux7ckid[.]onion 
• sonarmsng5vzwqezlvtu2iiwwdn3dxkhotftikhowpfjuzg7p3ca5eid[.]onion 

Regola YARA:

rule CactusRule

{

    strings:

        $cactusStr = “CaCtUs.ReAdMe.txt”

        $cactusHex = { 43 61 43 74 55 73 2e 52 65 41 64 4d 65 2e 74 78 74 }

    condition:

        $cactusStr or $cactusHex

}

CONCLUSIONI:

Cactus Ransomware possiede numerose caratteristiche che, almeno potenzialmente, potrebbero cambiare lo scenario delle nuove infezioni ransomware. I nuovi threats assumerebbero nuove caratteristiche fondamentali di auto-encryption ed il cambio consecutivo di più estensioni dei files criptati, questo per rendere più difficoltosa l’identificazione dei files stessi, sottoposti al processo di cifratura. È inoltre presente una peculiarità relativa all’utilizzo del file C:\ProgramData\ntuser.dat al fine di archiviare la stringa utilizzata come chiave pubblica per la crittografia del malware sample stesso. Il file ntuser.dat rappresenta un elemento utilizzato ad-hoc per la self-encryption del ransomware appositamente con tale filename con lo scopo probabilmente di confondere ed effettuare evasion. Per comprendere la natura ed il funzionamento di Cactus Ransomware possiamo citare due particolarità importanti: esso utilizza il packer UPX, il quale è largamente conosciuto e semplice da “unpackare”. Inoltre, i files sottoposti al processo di encryption, vengono divisi in porzioni salvate in microbuffers, probabilmente per velocizzare la gestione dei data streams criptati.