RATKing: nuova campagna con trojan ad accesso remoto
Alla fine di maggio, abbiamo scoperto una campagna per distribuire malware Remote Access Trojan (RAT), programmi che consentono agli aggressori di controllare da remoto un sistema infetto.
Il gruppo da noi esaminato si distingueva per il fatto di non aver selezionato alcuna specifica famiglia di RATTI per l'infezione. Durante gli attacchi della campagna sono stati rilevati diversi trojan (tutti ampiamente disponibili). Con questa caratteristica, il gruppo ci ha ricordato il re dei topi, un animale mitico composto da roditori con code intrecciate.
L'originale è tratto dalla monografia di K. N. Rossikov “Topi e roditori simili a topi, i più importanti dal punto di vista economico” (1908)
In onore di questa creatura, abbiamo chiamato il gruppo che stiamo considerando RATKing. In questo post entreremo nei dettagli su come gli aggressori hanno effettuato l'attacco, quali strumenti hanno utilizzato e condivideremo anche le nostre opinioni sull'attribuzione per questa campagna.
Avanzamento dell'attacco
Tutti gli attacchi in questa campagna sono avvenuti secondo il seguente algoritmo:
L'utente ha ricevuto un'e-mail di phishing con un collegamento a Google Drive.
Utilizzando il collegamento, la vittima ha scaricato uno script VBS dannoso che specificava una libreria DLL per caricare il payload finale nel registro di Windows e ha avviato PowerShell per eseguirlo.
La libreria DLL ha inserito l'ultimo payload, di fatto uno dei RAT utilizzati dagli aggressori, nel processo di sistema e ha registrato uno script VBS nell'esecuzione automatica per inserirsi nella macchina infetta.
Il payload finale veniva eseguito in un processo di sistema e dava all'aggressore la possibilità di controllare il computer infetto.
Schematicamente può essere rappresentato così:
Successivamente, ci concentreremo sulle prime tre fasi, poiché siamo interessati al meccanismo di distribuzione del malware. Non descriveremo in dettaglio il meccanismo di funzionamento del malware stesso. Sono ampiamente disponibili - venduti su forum specializzati o addirittura distribuiti come progetti open source - e quindi non sono esclusivi del gruppo RATKing.
Analisi delle fasi di attacco
Fase 1. E-mail di phishing
L'attacco è iniziato con la ricezione di una lettera dannosa da parte della vittima (gli aggressori hanno utilizzato diversi modelli con testo; lo screenshot seguente mostra un esempio). Il messaggio conteneva un collegamento a un archivio legittimo drive.google.com, che presumibilmente portava a una pagina di download del documento PDF.
Esempio di email di phishing
Tuttavia, in realtà non è stato caricato un documento PDF, ma uno script VBS.
Quando hai fatto clic sul collegamento dall'e-mail nello screenshot sopra, viene visualizzato un file denominato Cargo Flight Details.vbs. In questo caso gli aggressori non hanno nemmeno provato a mascherare il file come un documento legittimo.
Allo stesso tempo, nell'ambito di questa campagna, abbiamo scoperto uno script denominato Cargo Trip Detail.pdf.vbs. Potrebbe già passare per un PDF legittimo perché Windows nasconde le estensioni dei file per impostazione predefinita. È vero, in questo caso i sospetti potrebbero ancora essere suscitati dalla sua icona, che corrispondeva allo script VBS.
A questo punto, la vittima potrebbe riconoscere l'inganno: basta dare un'occhiata più da vicino ai file scaricati per un secondo. Tuttavia, in tali campagne di phishing, gli aggressori spesso si affidano a un utente distratto o frettoloso.
Fase 2. Operazione dello script VBS
Lo script VBS, che l'utente potrebbe aprire inavvertitamente, ha registrato una libreria DLL nel registro di Windows. Lo script era offuscato: le righe in esso contenute erano scritte come byte separati da un carattere arbitrario.
Esempio di script offuscato
L'algoritmo di deoffuscamento è abbastanza semplice: ogni terzo carattere è stato escluso dalla stringa offuscata, dopodiché il risultato è stato decodificato da base16 nella stringa originale. Ad esempio, dal valore 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (evidenziato nello screenshot sopra) la linea risultante era WScript.Shell.
Per deoffuscare le stringhe, abbiamo utilizzato la funzione Python:
def decode_str(data_enc):
return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)]))
Di seguito, alle righe 9–10, evidenziamo il valore la cui deoffuscamento ha prodotto un file DLL. È stato lui a essere lanciato nella fase successiva utilizzando PowerShell.
Stringa con DLL offuscata
Ogni funzione nello script VBS è stata eseguita mentre le stringhe venivano deoffuscate.
Dopo aver eseguito lo script, è stata chiamata la funzione wscript.sleep — è stato utilizzato per eseguire l'esecuzione differita.
Successivamente, lo script ha funzionato con il registro di Windows. Per questo ha utilizzato la tecnologia WMI. Con il suo aiuto, è stata creata una chiave univoca e il corpo del file eseguibile è stato scritto nel suo parametro. È stato possibile accedere al registro tramite WMI utilizzando il seguente comando:
Una voce effettuata nel registro da uno script VBS
Fase 3. Funzionamento della libreria DLL
Nella terza fase, la DLL dannosa caricava il payload finale, lo iniettava nel processo di sistema e assicurava che lo script VBS si avviasse automaticamente quando l'utente effettuava l'accesso.
Esegui tramite PowerShell
La DLL è stata eseguita utilizzando il seguente comando in PowerShell:
ricevuto i dati del valore del registro con il nome rnd_value_name — questi dati erano un file DLL scritto sulla piattaforma .Net;
caricato il modulo .Net risultante nella memoria del processo powershell.exe utilizzando la funzione [System.Threading.Thread]::GetDomain().Load()(descrizione dettagliata della funzione Load() disponibile sul sito Web Microsoft);
ha svolto la funzione GUyyvmzVhebFCw]::EhwwK() - con esso è iniziata l'esecuzione della libreria DLL - con parametri vbsScriptPath, xorKey, vbsScriptName... Parametro xorKey memorizzato la chiave per decrittografare il payload finale e i parametri vbsScriptPath и vbsScriptName sono stati trasferiti per registrare uno script VBS nell'esecuzione automatica.
Descrizione della libreria DLL
In forma decompilata, il bootloader appariva così:
Loader in forma decompilata (è sottolineata in rosso la funzione con cui è iniziata l'esecuzione della libreria DLL)
Il bootloader è protetto dal protettore .Net Reactor. L'utilità de4dot fa un ottimo lavoro nel rimuovere questa protezione.
Questo caricatore:
ha iniettato il payload nel processo di sistema (in questo esempio it svchost.exe);
Ho aggiunto uno script VBS all'esecuzione automatica.
Iniezione del carico utile
Diamo un'occhiata alla funzione chiamata dallo script PowerShell.
Funzione chiamata dallo script PowerShell
Questa funzione ha eseguito le seguenti azioni:
decrittografato due set di dati (array и array2 nello screenshot). Originariamente erano compressi utilizzando gzip e crittografati con l'algoritmo XOR con la chiave xorKey;
dati copiati nelle aree di memoria allocate. Dati da array - all'area di memoria indicata intPtr (payload pointer nello screenshot); dati da array2 - all'area di memoria indicata intPtr2 (shellcode pointer nello screenshot);
chiamata la funzione CallWindowProcA(descrizione Questa funzione è disponibile sul sito Web di Microsoft) con i seguenti parametri (i nomi dei parametri sono elencati di seguito, nello screenshot sono nello stesso ordine, ma con valori funzionanti):
lpPrevWndFunc - puntatore ai dati da array2;
hWnd — puntatore a una stringa contenente il percorso del file eseguibile svchost.exe;
Msg - puntatore ai dati da array;
wParam, lParam — parametri del messaggio (in questo caso questi parametri non sono stati utilizzati e avevano valori pari a 0);
creato un file %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.urlDove <name> - questi sono i primi 4 caratteri del parametro vbsScriptName (nello screenshot, il frammento di codice con questa azione inizia con il comando File.Copy). In questo modo, il malware aggiungeva un file URL all'elenco dei file di esecuzione automatica quando l'utente effettuava l'accesso e si attaccava così al computer infetto. Il file URL conteneva un collegamento allo script:
Per capire come è stata effettuata l'iniezione, abbiamo decrittografato gli array di dati array и array2. Per fare ciò abbiamo utilizzato la seguente funzione Python:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
Di conseguenza, abbiamo scoperto che:
array era un file PE: questo è il payload finale;
array2 era lo shellcode richiesto per effettuare l'iniezione.
Shellcode da un array array2 passato come valore di funzione lpPrevWndFunc in una funzione CallWindowProcA. lpPrevWndFunc — funzione di callback, il suo prototipo è simile a questo:
Quindi quando esegui la funzione CallWindowProcA con parametri hWnd, Msg, wParam, lParam viene eseguito lo shellcode dall'array array2 con argomenti hWnd и Msg. hWnd è un puntatore a una stringa contenente il percorso del file eseguibile svchost.exeE Msg — puntatore al carico utile finale.
Lo shellcode ha ricevuto gli indirizzi delle funzioni da kernel32.dll и ntdll32.dll in base ai valori hash dei loro nomi e hanno iniettato il payload finale nella memoria del processo svchost.exeutilizzando la tecnica Process Hollowing (puoi saperne di più in questo Articolo). Quando si inserisce lo shellcode:
creato un processo svchost.exe in uno stato sospeso utilizzando la funzione CreateProcessW;
quindi ha nascosto la visualizzazione della sezione nello spazio degli indirizzi del processo svchost.exe utilizzando la funzione NtUnmapViewOfSection. Pertanto, il programma ha liberato la memoria del processo originale svchost.exeper allocare poi memoria per il payload a questo indirizzo;
memoria allocata per il payload nello spazio degli indirizzi del processo svchost.exe utilizzando la funzione VirtualAllocEx;
Inizio del processo di iniezione
ha scritto il contenuto del payload nello spazio degli indirizzi del processo svchost.exe utilizzando la funzione WriteProcessMemory (come nello screenshot qui sotto);
ripreso il processo svchost.exe utilizzando la funzione ResumeThread.
Completamento del processo di iniezione
Malware scaricabile
In seguito alle azioni descritte, sul sistema infetto è stato installato uno dei numerosi malware di classe RAT. La tabella seguente elenca il malware utilizzato nell'attacco, che possiamo tranquillamente attribuire a un gruppo di aggressori, poiché i campioni hanno avuto accesso allo stesso server di comando e controllo.
Esempi di malware distribuito con lo stesso server di controllo
Due cose sono degne di nota qui.
Innanzitutto il fatto stesso che gli aggressori hanno utilizzato contemporaneamente diverse famiglie di RAT. Questo comportamento non è tipico dei cyber-gruppi noti, che spesso utilizzano all'incirca lo stesso set di strumenti a loro familiari.
In secondo luogo, RATKing ha utilizzato malware che viene venduto a basso prezzo su forum specializzati o che è addirittura un progetto open source.
Alla fine dell'articolo viene fornito un elenco più completo dei malware utilizzati nella campagna, con un avvertimento importante.
Informazioni sul gruppo
Non possiamo attribuire la campagna dannosa descritta ad alcun aggressore noto. Per ora riteniamo che questi attacchi siano stati compiuti da un gruppo fondamentalmente nuovo. Come abbiamo scritto all'inizio, lo abbiamo chiamato RATKing.
Per creare lo script VBS, il gruppo probabilmente ha utilizzato uno strumento simile all'utility Crittografia VBS dallo sviluppatore NYAN-x-CAT. Ciò è dimostrato dalla somiglianza dello script creato da questo programma con lo script degli aggressori. Nello specifico entrambi:
eseguire l'esecuzione ritardata utilizzando la funzione Sleep;
utilizzare WMI;
registrare il corpo del file eseguibile come parametro della chiave di registro;
eseguire questo file utilizzando PowerShell nel proprio spazio di indirizzi.
Per chiarezza, confronta il comando PowerShell per eseguire un file dal registro, che viene utilizzato da uno script creato utilizzando VBS-Crypter:
Tieni presente che gli aggressori hanno utilizzato un'altra utility di NYAN-x-CAT come uno dei payload: CalceRAT.
Gli indirizzi dei server C&C indicano un'altra caratteristica distintiva di RATKing: il gruppo predilige i servizi DNS dinamici (vedi elenco C&C nella tabella IoC).
CIO
La tabella seguente fornisce un elenco completo degli script VBS che molto probabilmente possono essere attribuiti alla campagna descritta. Tutti questi script sono simili ed eseguono approssimativamente la stessa sequenza di azioni. Tutti inseriscono malware di classe RAT in un processo Windows affidabile. Tutti hanno indirizzi C&C registrati utilizzando i servizi DNS dinamici.
Tuttavia, non possiamo affermare che tutti questi script siano stati distribuiti dagli stessi aggressori, ad eccezione di campioni con gli stessi indirizzi C&C (ad esempio kimjoy007.dyndns.org).