IMPORTANTE

IoC 08/10/2021

CERT-AgID semplifica l’accesso ai propri Indicatori di Compromissione (IoC)

Fino ad oggi per accedere agli indicatori delle campagne malevole gestiti e censiti quotidianamente dal CERT-AGID era necessario disporre di tre requisiti: Essere una Pubblica Amministrazione; Accreditarsi presso il CERT-AGID; Dotarsi di una opportuna instanza MISP o del client di interfacciamento CNTI sviluppato dallo stesso CERT-AgID. Mentre i primi due requisiti resteranno invariati in quanto […]

Il Ransomware Nefilim

10/11/2020

Nefilim ransomware

Nefilim è il terzo ransomware che il CERT-AgID ha scelto di analizzare perchè, al pari dei precedenti Maze e NetWalker, è stato definito come ransomware con capacità di esfiltrazione di dati e risulta coinvolto in un recente ed importante data leak che ha coinvolto una azienda italiana.

Le prime evidenze di Nefilim, noto anche come Nephilim, sono state osservate ad inizio del 2020 e, stando a quanto già anticipato da altri ricercatori, sono state rilevate somiglianze con il codice di un altro ransomware denominato Nemty 2.5 ma, a differenza di quest’ultimo, non presenta la componente RaaS e non risulta ancora del tutto chiaro come venga distribuito il malware. Si presume venga inoculato sfruttando vulnerabilità remote o servizi RDP pubblicamente esposti.

Anche in questo caso quindi si presume che il ransomware venga installato in uno stadio successivo alla compromissione e all’esfiltrazione dei dati presenti sulla macchina.

Nefilim

Il campione in esame è un eseguibile, scritto in C/C++, che fortunatamente non presenta codice offuscato o accorgimenti che possano tediosamente ostruire l’analisi.

Questo sample è dotato di un certificato rilasciato e, a quanto risulta dalle proprietà, anche revocato da Sectigo RSA Code Signing CA

Il flusso grafico di IDA è abbastanza comprensibile e consente di leggere il comportamento del ransomware sin dalla prima chiamata.

Come è possibile osservare, in primo luogo il ransomware si occupa di generare le chiavi di sessione invocando CryptAcquireContextA per definire un handle per il CSP (Cryptographic Service Provider). Successivamente inizializza il processo di hashing con la funzione CryptCreateHash che prende come parametro l’handle CSP appena dichiarato e definisce il tipo di algoritmo da applicare.

Il valore di ALG_ID passato è 8004 che dalla lista di algoritmi supportati corrisponde a SHA/SHA1.

Il calcolo di hash viene applicato alla seguente stringa tramite la funzione CryptHashData.

ya chubstvuu bol' gde-to v grude, i moi rani v serdce ne zalechit'

Questo hash appena calcolato rappresenta il valore di base utilizzato da CryptDeriveKey per generare una chiave di sessione.

Affidandoci sempre alla documentazione Microsoft, relativamente alla lista di algoritmi supportati, si evince che il valore 6801 corrisponde a RC4 stream encryption algorithm.

Questa chiave verrà a sua volta utilizzata per decifrare il contenuto della nota di riscatto, contenuta nel codice stesso, che verrà rilasciata all’interno di ogni cartella cifrata.

Mutex

Lo step successivo riguarda la creazione di un mutex tramite la chiamata alla funzione CreateMutexA passando come parametro lpName null; verrà quindi creato un oggetto senza nome con lpMutexAttributes null, quindi non verrà ereditato il processo figlio.

Un controllo viene effettuato per verificare se una istanza del sample è già in esecuzione: se GetLastError ritorna 0B7h è sintomo che la macchina è già compromessa.

La chiave RSA

La chiave pubblica RSA1 è anch’essa memorizzata nel codice, codificata in Base64.

Una volta decodificata la chiave pubblica viene nuovamente utilizzata la funzione CryptAcquireContextA per generare un contenitore di chiavi CSP e successivamente richiamare CryptImportKey.

Nefilim tenta di ottenere un handle per un CSP con nome “rsa session” e, qualora non vi riuscisse, ne crea uno nuovo denominato “v etom skrucheni problemi i trava“.

Nefilim utilizza l’algoritmo RSA 2048 bit per cifrare le chiavi AES 128 bit usate per la crittografia dei file. Per ogni file viene richiamata la funzione SystemFunction036 che restituisce due buffer di valori casuali a 128 bit che costituiscono, rispettivamente, la chiave e il vettore di inizializzazione (IV).

Entrambi i buffer, tramite la funzione CryptEncrypt, vengono cifrati con la chiave pubblica RSA 2048 e viene scritto il risultato alla fine del file, insieme alla stringa NEPHILIM.

Controllo sulle dimensioni del file prima della cifratura

Se il file è di dimensioni inferiori o uguali a 1.2 MB, il documento viene cifrato integralmente con AES 128 bit.

Se il file è maggiore o uguale a di 1.2 MB ma inferiore o uguale a 64 MB, vengono cifrati solo 600KB. (927C0h).

Se le dimensioni del file risultano superiori a 64 MB vengono cifrati 125 KB (1E848h) ogni 250 KB (3D090h).

Debug list

Come già visto con altri malware, ed in particolare con Maze, anche Nefilim contiene una lista di debugger da ricercare tra i processi attivi, che verifica prima di eseguire le operazioni di cifratura e di scrittura della nota di riscatto.

File e cartelle da non cifrare

Nefilim, ancora una volta al pari di Maze, verifica per ogni file e cartella individuata nel sistema se questo rientra in una lista protetta.

Il medesimo controllo viene effettuato sulle estensioni dei file e, se la tipologia di file rientra nelle estensioni protette, Nefilim salterà il processo di cifratura e proseguirà con la verifica del prossimo file.

Una volta accertato che il sample non stia lavorando sotto un controllo di un debugger, Nefilim richiama GetLogicalDrives per mappare le unità disco presenti nel sistema, senza trascurare le eventuali cartelle condivise da cui ha inizio la fase di cifratura dei file ed il successivo rilascio della nota denominata NEPHILIM-DECRYPT.txt

I file che verranno cifrati avranno estensione .NEPHILIM

Completata la cifratura dei file accessibili dal sistema, Nefilim esegue l’ultima operazione, ovvero la creazione di un file all’interno della cartella Temp denominato god.jpg che andrà a rimpiazzare lo sfondo del desktop di Windows.

Conclusioni

A differenza di altri ransomware, l’analisi di Nefilim non è complessa e, anzi, sembra quasi si tratti di un template, scopiazzato da altri ransomware, da cui iniziare uno sviluppo software più complesso.

Riguardo la chiave privata, che resta nelle mani dei criminali, si prospettano due situazioni:

  1. È sempre la stessa e quindi unica per tutte le campagne;
  2. La chiave privata cambia ad ogni campagna.

Nel primo caso basterebbe entrare in possesso dell’unica chiave che consentirebbe di liberare tutti i file cifrati nel corso delle campagne. Ulteriori analisi eseguite su sample Nefilim differenti hanno fatto emergere, come ci si aspettava, che la chiave cambia per in ogni campagna.

In definitiva Nefilim utilizza due meccanismi di cifratura: una per la nota di riscatto e l’altra, come abbiamo visto, per cifrare i file sul disco.

Nefilim quindi è focalizzato esclusivamente sul processo di cifratura dei file e non importa funzioni che possano consentire l’esfiltrazione dei dati dalla macchina compromessa.