RobinHood Ransomware: Bring Your Own Vulnerable Kernel Driver (PARTE 1)

Introduzione

Il ransomware RobbinHood, legato alla Cyber Gang OUTLAW SPIDER, è noto per prendere di mira i governi e i comuni diffondendosi attraverso brute force di RDP o come payload successivo di altri malware.

Per la fase di Defense Evasion, RobbinHood sfrutta il driver motherboard driver GIGABYTE chiamato GDRV.SYS vulnerabile alla CVE-201819320 per disabilitare la signature dei driver e installare il proprio driver non firmato RBNL.SYS.

In particolare, abbiamo diversi moduli che si occupano della defense evasion (l’obbiettivo finale è terminare diversi processi EDR e cancellazione dei loro file):

• STEEL.EXE : avvia robnr.exe, interagisce con rbnl.sys per sospendere i processi EDR e cancellare determinati file.
• ROBNR.EXE : si occupa di installare i due driver gdrv.sys e rbnl.sys
• GDRV.SYS : driver signed GYGABYTE vulnerabile
• RBNL.SYS : driver unsigned custom per defense evasion, si occupa di terminare i processi EDR e cancellare i loro file in utilizzo.

Dopo la fase di Defense Evasion, viene eseguito il Ransomware:

• Si occupa di cancellare i log, cancellare le Shadow Volume Copies, disabilitare Windows automatic repair e disconnette tutti i network shares
• Crea una chiave EAS per ogni file da cifrare , successivamente cifra la chiave e il file con una chiave RSA presente C: Windows Temp

Driver 101

I driver sono dei moduli caricabili nel kernel; il loro codice è eseguito in ring0 e permettono quindi ai programmi che hanno ottenuto un handle di interagire con il kernel attraverso il driver.
Se il driver non è presente sul sistema oppure è presente ma non è caricato , sono necessari i privilegi amministrativi.

Quando il driver è caricato nel sistema , l’interazione con questo dipende dalla policy del driver stesso; ad esempio alcuni driver permettono anche a processi low integrity di comunicare.

I passaggi necessari per interagire con un driver sono :

• Ottenere un handle del driver (DEVICE_OBJECT) attraverso CreateFile NtCreateFile passando il SymbolicLink.
• Utilizzare WriteFile o DeviceIoControl specificando l’handle precedentemente ottenuto,l’IOCTL , l’input buffer e l’output buffer.
• All’interno di DRIVER_OBJECT del driver è presente MajorFunction che è un insieme di function pointer, che definiscono quali particolari funzioni il driver supporta . Quando ad esempio comunichiamo attraverso DeviceIoControl specificando un IOCTL, viene eseguita la funzione IRP_MJ_DEVICE_CONTROL che esegue la funzione specifica in base all’IOCT passato

Defense Evasion via BYOVKD

La Driver Signature Enforcement è una feature di sicurezza introdotta da Microsoft che permette di installare driver che devono essere firmati sia da Microsoft che dal publisher. Nel processo vengono eseguiti anche diversi controlli (WHQL) per garantire la ( parziale ) sicurezza del driver.

La tecnica Bring Your Own Vulnerable Kernel Driver (BYOVKD) sfruttata dai malware consiste nell’effettuare il loading un driver vulnerabile signed per interagire con il kernel; richiede privilegi amministrativi in quanto deve essere effettuato il loading di un nuovo driver.

Nel tempo tantissime vulnerabilità sono state individuate che riguardano i driver; in particolare, in questo caso viene sfruttata una funzione vulnerabile che non effettua bound checking e che quindi permette in modo arbitrario di sovrascrivere parti del kernel (vulnerabilità arbitrary Ring0 memcpy). Altre vulnerabilità molto comuni trovate nel tempo ad esempio riguardano la lettura e modifica arbitraria di alcuni registri (arbitrary MSR Read/Write e arbitrary Control Register Read/Write). Per altre info qui e qui.

Nella tabella possiamo vedere alcuni degli attori che sfruttano questa tecnica:

In particolare, i passi effettuati da Robinhood sono:

• Abilita il privilegio SeLoadDriverPrivilege per il loading di Driver attraverso le API LookupPrivilegeValueA , OpenProcessToken , AdjustTokenPrivilege.
• Trova l’indirizzo di DSE: g_CiEnabled nel modulo ntoskrnl o g_CiOptions nel modulo ci.dll
• Crea un file in /temp con il driver signed vulnerabile GDRV.SYS e carica il driver.
  • Memorizza il valore precedente di g_CiEnabled o g_CiOptions.
  • Disabilita DSE impostato g_CiEnabled o g_CiOptions a 0.
  • Effettua il restore al valore precedente per non causare BSOD causato da PathGuard.
• Crea un file in / temp con il driver unsigned RBNL.sys e carica il driver.
  • Steel.exe interagisce con il driver e termina i processi da una lista txt (+150)
  • Elimina i file anche se in utilizzo inviando una IRP direttamente al NTFS.SYS storage device.

Andiamo ora ad analizzare questi punti con maggiore dettaglio.

Analisi RobinHood

Una delle prime attività che effettua RobinHood è abilitare il privilegio SeLoadDriverPrivilege che servirà successivamente al malware per caricare i due driver; ricordiamo che per queste chiamate sono necessari i privilegi amministrativi, ma siamo già in un contesto di high integrity level.

Successivamente in base alla BUILD di Windows si ottiene il puntatore alla flag DSE per poterla disabilitare successivamente con il driver vulnerabile.

Prima della Build 9200, si ottiene il puntatore a g_CiEnabled da ntoskrnl:

Approfondiamo il secondo caso, cioè l’ottenimento della flag g_CiOptions da Ci.dll; RobbinHood carica in memoria Ci.dll attraverso LoadLibraryExA con DONT_RESOLVE_DLL_REFERENCES e ottiene tutti gli indirizzi dei moduli caricati con NtQuerySystemInformation e SystemModuleInformation.
La DLL Ci.Dll esporta la funzione CiInitialize, che chiama a sua volta la funzione CipInitialize che effettua ad un certo punto un MOV contenente il puntatore a g_CiOptions:

Quindi ricapitolando, i passaggi effettuati da RHR per ottenere il valore di g_CiOptions sono:

1. Ottenere l’indirizzo di Ci.dll.
2. Ottenere l’indirizzo di CiInitialize tramite l’EAT di Ci.dll.
3. Cercare il jmp o call a CipInitialize in base alla build di Windows.
4. Cercare all’interno di CipInitialize il mov che contiene g_CiOptions.

Possiamo vedere i seguenti passaggi:

Successivamente abbiamo il corpo principale del malware, che si occupa di caricare il driver signed vulnerabile, disabilitare la flag DSE tramite questo driver con il puntatore ottenuto in precedenza e caricare il proprio driver unsigned che si occupa di terminare i processi EDR e cancellare i file.

Iniziamo analizzando il metodo ChangeCiValue; prima di tutto è necessario caricare il driver e in Windows si utilizzano le api CreateServiceW e StartServiceW per caricare e avviare il driver.

Con la prima richiesta viene salvato il valore precedente di DSE che successivamente è necessario ripristinare per PathGuard; dopo aver effettuato il salvataggio, si sovrascrive il valore di DSE con il valore passato dalla funzione, nel primo caso 0 e nella chiamata successiva per il ripristino 1 (il valore memorizzato in precedenza)

Caricando in Ghidra il driver vulnerabile gdrv.sys e cercando per lo specifico IOCTL otteniamo la funzione vulnerabile (CVE-2018-19320):

La funzione non effettua nessun controllo di bound checking e quindi permette di sovrascrivere in modo arbitrario parti del kernel (PathGuard permettendo); questo viene sfruttato da RBR per sovrascrivere il valore DSE e disabilitare il controllo di integrità dei driver.

Eccoci al termine! Nella fase successiva analizzeremo in dettaglio il driver malevolo installato che tramite IRP effettua cancellazione dei file (anche se attualmente in utilizzo) e terminazione dei processi EDR.

A presto!! 😀