Gli analisti di malware di ANY.RUN sono felici di discutere gli algoritmi di crittografia di XLoader, noto anche come FormBook con la redazione di Matrice Digitale. Insieme decifreremo le stringhe dello stealer e dei server C2.
Xloader è uno Stealer, successore di FormBook. Tuttavia, oltre alle funzionalità di base, sono interessanti anche gli approcci insoliti alla crittografia e all’offuscamento delle strutture interne, del codice e delle stringhe utilizzate in XLoader. Diamo uno sguardo dettagliato alla crittografia di stringhe, funzioni e richiami C2.
IceXLoader ha infettato migliaia di vittime in tutto il mondo
Ecco il malware che eluce i blocchi impostati da Microsoft sulle VBA
DotRunpeX diffonde diverse famiglie di malware tramite annunci pubblicitari
Gookit all’attacco di organizzazioni sanitarie e finanziarie
Crittografia in XLoader
Innanzitutto, dovremmo ricercare 3 principali algoritmi crittografici utilizzati in XLoader. Questi sono gli algoritmi modificati: RC4, SHA1 e l’algoritmo di Xloader basato su una macchina virtuale.
L’algoritmo RC4 modificato
L’algoritmo RC4 modificato è un normale RC4 con livelli aggiuntivi di sottrazione sequenziale prima e dopo la chiamata RC4. Nel codice uno strato di sottrazioni ha questo aspetto:
| # transform 1 for i in range(len(encbuf) – 1, 0, -1): encbuf[i-1] -= encbuf[i] # transform 2 for i in range(0, len(encbuf) -1): encbuf[i] -= encbuf[i+1] |
I byte del testo cifrato vengono sottratti l’uno dall’altro in sequenza da destra a sinistra. E poi vanno da sinistra a destra. Nel codice di XLoader appare così:
Funzione che esegue la crittografia RC4
L’algoritmo SHA1 modificato
La modifica SHA1 è una SHA1 regolare, ma ogni 4 byte viene invertita:
L’algoritmo della macchina virtuale di Xloader
L’ultimo algoritmo è una macchina virtuale che genera da uno a quattro byte di testo in chiaro, a seconda del byte corrente del testo cifrato. Di solito, questo algoritmo viene utilizzato come livello di crittografia aggiuntivo, che verrà discusso in seguito. La voce della routine di decrittografia della VM è simile alla seguente:
Un esempio di trasformazioni nella routine di decrittazione di una macchina virtuale
Decrittazione delle stringhe XLoader
Successivamente, esaminiamo come funziona la crittografia delle stringhe in XLoader. Tutti gli array di byte contenenti stringhe crittografate o informazioni sulla chiave si trovano in tipi speciali di BLOB.
Un esempio di trasformazioni nella routine di decrittazione di una macchina virtuale
Decrittazione delle stringhe XLoader
Successivamente, esaminiamo come funziona la crittografia delle stringhe in XLoader. Tutti gli array di byte contenenti stringhe crittografate o informazioni sulla chiave si trovano in tipi speciali di BLOB.
Funzione di generazione della chiave per decifrare le stringhe
Qui K1_blob, K2_blob e K3_blob sono funzioni che restituiscono dati dai blocchi descritti sopra e la lunghezza della stringa è un argomento per esse.
Le funzioni VM_Decrypt, RC4_with_sub_Layer e sha1_* sono algoritmi modificati che abbiamo discusso in precedenza.
Schematicamente, l’algoritmo di generazione della chiave può essere rappresentato dal seguente diagramma.
Qui E e K sono i dati e la chiave che viene alimentata all’input della funzione RC4, rispettivamente, e K1, K2 e K3 sono i dati ottenuti dalle funzioni K1_blob, K2_blob e K3_blob.
schema di generazione delle chiavi per decifrare le stringhe
Anche le stringhe stesse vengono archiviate come blob e sono coperte da due livelli di crittografia:
VM_decrypt
RC4 che utilizza la chiave ottenuta sopra.
Allo stesso tempo, RC4 non viene utilizzato per l’intero blob in una volta.
Dopo aver rimosso il primo livello, le stesse stringhe crittografate vengono memorizzate nel formato:
lunghezza stringa crittografata – stringa crittografata
Di conseguenza, per decrittografare le stringhe, dobbiamo eseguire un ciclo di questa struttura e decrittografare in modo coerente tutte le stringhe.
Funzione per decifrare le stringhe
Di seguito è riportato un esempio dei dati crittografati dopo aver rimosso il primo livello. Le coppie lunghezza/stringa per le prime 3 stringhe crittografate sono evidenziate in rosso.
Le prime 3 stringhe crittografate
Le stesse stringhe dopo la decrittazione:
Le prime 3 righe dopo la decodifica
Insieme alle stringhe crittografate, vengono memorizzate anche le esche C2. Si trovano sempre alla fine di tutte le stringhe decifrate, iniziando e terminando con le stringhe f-start e f-end.
Decrittazione dei server C2 di XLoader
Successivamente, vediamo come funziona la crittografia C2 principale. Il C2 principale si trova altrove nel codice, quindi puoi ottenerlo separatamente dalle esche C2.
Frammento di codice che dimostra la decrittazione C2.
Per decrittografarlo, oltre che per decrittografare le stringhe, vengono utilizzate 3 chiavi. Lo schema di decrittazione C2 è mostrato di seguito:
- EC2 è il C2 crittografato
- DC2 è il C2 decifrato
L’algoritmo stesso è un’applicazione sequenziale 3 volte dell’algoritmo RC4 con 3 chiavi diverse.
Schema di decrittazione delle esche C2
Inoltre, nelle versioni più recenti delle esche XLoader C2, che di solito si trovano insieme a tutte le altre stringhe, risultano essere coperte da un ulteriore livello di crittografia e, a prima vista, non è del tutto chiaro dove avvenga esattamente la decrittazione di queste stringhe .
Poiché XLoader ha diversi punti di ingresso, ciascuno responsabile di diverse funzionalità non intersecanti, con molte funzioni che risultano essere crittografate.
Le esche C2 vengono decifrate all’interno di XLoader iniettato in Explorer.exe. E in questo caso, viene passato a netsh.exe, che contiene anche XLoader tramite iniezione APC.
Il ciclo di vita C2 in diversi moduli XLoader
Per capire come viene crittografato un esca C2, prima di tutto è necessario capire come vengono crittografate le funzioni.
In realtà è abbastanza semplice. RC4 viene utilizzato come algoritmo di crittografia. Questa volta, la chiave è hardcoded e scritta direttamente nel codice e poi xored con la gamma a 4 byte.
Successivamente, dovresti trovare i puntatori all’inizio e alla fine della funzione. Ecco come si fa: un valore univoco di 4 byte viene inserito all’inizio e alla fine di ogni funzione crittografata. XLoader cerca questi valori e ottiene i puntatori desiderati.
Frammento di codice che dimostra la decrittazione della funzione
Quindi la funzione viene decrittografata, le viene dato il controllo e allo stesso modo cerca e decrittografa la funzione successiva. Ciò accade fino a quando la funzione con la funzionalità principale non viene decifrata ed eseguita. Quindi, le funzioni dovrebbero essere decifrate in modo ricorsivo.
La chiave per decrittografare le esche C2 è composta da 2 parti e viene raccolta separatamente in due diversi punti di uscita. Un punto di uscita ottiene la chiave protetta da 20 byte e il secondo ottiene la gamma da 4 byte per decrittografare la chiave.
Esempio di configurazione del malware XLoader estratto
Applicando gli algoritmi di cui sopra possiamo estrarre la configurazione da Xloader, inclusi C2, esche C2 e stringhe. Per tua comodità, abbiamo integrato l’estrazione automatica della configurazione di Xloader nella sandbox interattiva ANY.RUN: basta eseguire l’esempio e ottenere tutti gli IOC in pochi secondi.
Configurazione del malware estratta in ANY.RUN
Esempi di campioni eseguiti con successo:
Riassumi
In questo articolo abbiamo discusso la crittografia in xLoader stealer. Si basa sia su componenti aggiuntivi di algoritmi esistenti sia su algoritmi scritti da sé.
La parte principale e complicata del processo di decrittazione è la generazione della chiave e il fatto che la funzionalità di XLoader è suddivisa in moduli che possono essere eseguiti in diversi processi. Per questo motivo, per estrarre le stringhe, dobbiamo decifrare il codice eseguibile, tra le altre cose.
Fortunatamente, ANY.RUN è già impostato per rilevare automaticamente questo malware, rendendo i relativi dettagli di configurazione a portata di clic.
Appendice
File analizzati
Campione con la nuova crittografia dei richiami C2
| Title | Description |
| Name | MT10320221808-004. pdf.exe |
| MD5 | b7127b3281dbd5f1ae76ea500db1ce6a |
| SHA1 | 6e7b8bdc554fe91eac7eef5b299158e6b2287c40 |
| SHA256 | 726fd095c55cdab5860f8252050ebd2f3c3d8eace480f8422e52b3d4773b0d1c |
Campione senza crittografia esche C2
| Title | Description |
| Name | Transfer slip.exe |
| MD5 | 1b5393505847dcd181ebbc23def363ca |
| SHA1 | 830edb007222442aa5c0883b5a2368f8da32acd1 |
| SHA256 | 27b2b539c061e496c1baa6ff071e6ce1042ae4d77d398fd954ae1a62f9ad3885 |
