Cos'è RootkitRevealer: come funziona, come utilizzarlo e segnali di presenza di rootkit

Informatec Digital » Sicurezza » Cos'è RootkitRevealer: come funziona, come utilizzarlo e segnali di presenza di rootkit

RootkitRevealer è una di quelle utility leggendarie che ogni professionista Windows dovrebbe conoscere; è stata creata dal team di Sysinternals con Mark Russinovich alla guida e, sebbene sia nata anni fa, rimane un punto di riferimento per capire come rilevare le discrepanze causate dai rootkit tra ciò che il sistema mostra e ciò che è effettivamente presente sul disco.

A differenza di altri scanner, non cerca firme o schemi: confronta una visione di alto livello delle API di Windows con una lettura grezza e di basso livello del disco e del Registro di sistema. Questa idea apparentemente semplice rivela quando un malware tenta di nascondere file, chiavi o valori manipolando le chiamate di sistema.

Che cos'è RootkitRevealer e su quali sistemi funziona?

Si tratta di uno strumento avanzato per il rilevamento di rootkit sia in modalità utente che kernel . Originariamente sviluppato per Windows XP e Windows Server 2003 (32 bit), è comunemente disponibile gratuitamente, in lingua inglese e ha una dimensione di circa 231 KiB; molte inserzioni indicavano anche la sua compatibilità con Windows NT/2000/XP/Vista dell'epoca.

Nel tempo, la sua versione puramente a riga di comando è stata eliminata perché alcuni autori di malware hanno iniziato a monitorare il nome dell'eseguibile; per evitare ciò, il programma viene avviato come servizio da una copia di se stesso con un nome casuale, rendendo più difficile il rilevamento tramite nome e complicando la fornitura di un'interfaccia a console al 100%.

Cos'è un rootkit? Concetti chiave

Il termine rootkit si riferisce a tecniche e meccanismi che consentono ai malware (virus, trojan, spyware, ecc.) di nascondersi all'utente e agli strumenti di sicurezza . Si distinguono diverse famiglie: persistenti (che resistono ai riavvii), residenti in memoria (che scompaiono al riavvio), in modalità utente e in modalità kernel, tra le altre varianti moderne.

Un rootkit in modalità utente può intercettare funzioni come FindFirstFile/FindNextFile, o gli enumeratori nativi del sistema, per filtrare le voci che rivelerebbero i file, i processi o le chiavi di registro modificati . Ciò impedisce a Esplora risorse, al prompt dei comandi o agli editor del Registro di sistema di visualizzare ciò che effettivamente esiste.

I rootkit in modalità kernel si spingono oltre: oltre a intercettare le API native, possono manipolare direttamente le strutture del kernel, ad esempio rimuovendo il proprio processo dall'elenco dei processi attivi in ​​modo che non appaia in Gestione attività o Process Explorer anche se è in esecuzione.

Esistono bootloader ibridi (in parte basati sull'utente e in parte sul kernel), firmware (BIOS/UEFI e altri componenti), boot o bootkit (MBR/UEFI), virtuali (che posizionano il sistema operativo all'interno di una macchina virtuale) e basati sulla memoria (non persistenti). Questi ultimi possono essere particolarmente difficili da individuare, mentre il firmware e i bootloader persistono anche dopo una reinstallazione pulita del sistema operativo.

Come funziona RootkitRevealer

RKR mette a confronto due istantanee: la visione di alto livello dell'API di Windows e la lettura grezza e di basso livello dei file (hive) del volume e del registro di sistema. Se un rootkit manomette le chiamate di alto livello per nascondere qualcosa, questa alterazione viene rivelata perché ciò che è presente sul disco e nel registro di sistema non corrisponde a quanto indicato dall'API, generando discrepanze diagnosticabili.

In teoria, un rootkit potrebbe anche tentare di nascondersi da RootkitRevealer intercettando le sue letture grezze e riscrivendo i dati al volo. Per riuscirci, avrebbe bisogno di una conoscenza approfondita dei formati NTFS, FAT e del Registro di sistema, e della capacità di modificare le strutture senza causare incongruenze o effetti collaterali evidenti: un'impresa tecnica estremamente complessa che è stata raramente osservata. Ciononostante, non esiste un "rilevatore universale" infallibile: persino l'avvio da un ambiente esterno (ad esempio, utilizzando le migliori distribuzioni Linux ) potrebbe essere compromesso da artefatti particolarmente sofisticati e persistenti . In pratica, l'approccio più robusto consiste nel combinare l'analisi online con la verifica offline in ambienti affidabili.

Requisiti, buone pratiche ed esecuzione

Per eseguire questa scansione, l'account deve disporre dei privilegi "Esegui backup di file e directory", "Carica driver" e "Manutenzione volumi" (questi privilegi sono concessi per impostazione predefinita agli amministratori in Windows XP e versioni successive). Per ridurre al minimo i falsi positivi, si consiglia di eseguire la scansione con il sistema a riposo e senza applicazioni aperte.

Nell'esecuzione manuale, è sufficiente premere il pulsante di scansione. Durante il processo, il programma fornirà aggiornamenti sullo stato di avanzamento ed elencherà eventuali anomalie. Sono disponibili due opzioni rilevanti: "Nascondi i file di metadati NTFS" (attivata per impostazione predefinita, per evitare di visualizzare i metadati standard nascosti da NTFS) e "Registro di scansione" (attivata per impostazione predefinita; deselezionandola si salterà la scansione del Registro di sistema di Windows ).

Per l'automazione, supporta parametri che consentono di avviare, accedere e uscire senza intervento: rootkitrevealer outputfile]. L'opzione -a inizia e termina automaticamente; -c restituire il risultato in formato CSV; -m visualizza i metadati NTFS; e -r disabilita la scansione del registro. Il file di output deve essere in un volume locale accessibile.

L'esecuzione remota è possibile con PsExec. Ad esempio: psexec \\remote -c rootkitrevealer.exe -a c:\windows\system32\rootkit.log. Con -c, i progressi non vengono visualizzati e le discrepanze vengono stampate in CSV, rendendo più semplice l'importazione in database o script.

Interpretazione dei risultati e discrepanze tipiche

Le discrepanze del tipo "Nascosto dall'API di Windows" sono le più comuni quando un rootkit nasconde delle voci. Se non hai abilitato la visualizzazione dei metadati NTFS, noterai delle differenze perché NTFS nasconde i suoi file interni, come $MFT o $Secure , dall'API . Anche alcuni programmi antivirus memorizzano i dati in flussi alternativi e li nascondono, causando errori simili.

Questi sono alcuni dei metadati standard definiti in NTFS (Windows Server 2003): $AttrDef, $BadClus, $BadClus:$Bad, $BitMap, $Boot, $LogFile, $Mft, $MftMirr, $Secure, $UpCase, $Volume, $Extend, $Extend\$Reparse, $Extend\$ObjId, $Extend\$UsnJrnl, $Extend\$UsnJrnl:$Max, $Extend\$Quota.

RKR correla tre fonti nel file system: l'API di Windows, la Master File Table (MFT) e gli indici delle directory su disco. Possono comparire combinazioni come "Visibile nell'API ma non nell'indice o nella MFT", "Visibile nella MFT ma non nell'API", ecc., soprattutto se un file viene creato o eliminato durante l'analisi e produce un intervallo di incoerenza temporanea.

Esempio di creazione durante la scansione: C:\newfile.txt, di 8 byte di dimensione, con il messaggio "Visibile nell'API, ma non nell'indice o MFT". Questi casi non indicano necessariamente rootkit, ma cambiamenti simultanei durante l'esame.

Se viene visualizzato il messaggio "Accesso negato", qualcosa non va: RootkitRevealer utilizza meccanismi per accedere a qualsiasi file, directory o chiave, quindi questo messaggio non dovrebbe comparire in condizioni di normale funzionamento.

Nel Registro di sistema sono presenti diverse discrepanze di interesse: "La lunghezza dell'API di Windows non è coerente con i dati grezzi" (possibile tentativo di nascondere il contenuto effettivo), "Tipo non corrispondente" (ad esempio, viene pubblicizzato REG_SZ ma dovrebbe essere REG_BINARY), "Il nome della chiave contiene valori NULL incorporati" (una tecnica nota che sfrutta la differenza tra stringhe terminate da NULL e stringhe con conteggi). Per quest'ultimo caso, l'utilità RegDelNull di Sysinternals aiuta a ripulire le chiavi con valori NULL incorporati.

Si può verificare una "mancata corrispondenza dei dati" se un valore cambia durante la scansione (ad esempio, tempi di attività di SQL Server come HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\RECOVERYMANAGER\MSSQLServer\uptime_time_utc). Devi convalidare che il valore appartenga a componenti legittimi che aggiornano i dati in tempo reale.

Un caso esemplificativo è stato il rootkit HackerDefender: i suoi servizi e driver erano invisibili alle API di Windows, ma erano presenti nella lettura grezza dell'hive del Registro di sistema; lo stesso valeva per i suoi file, che l'analisi diretta del file system ha rilevato sul disco.

Errori e problemi comuni con rootkitrevealer.exe in ambienti forensi

Alcuni kit forensi (ad esempio, WinTaylor) elencano gli errori tipici relativi a rootkitrevealer.exe , come: "non è un'applicazione Win32 valida", "non trovato", "errore dell'applicazione" o "problema di avvio". Questi messaggi si verificano solitamente durante l'installazione, l'avvio o l'arresto del sistema, oppure a causa di conflitti con altre applicazioni residenti.

Le cause più frequenti includono file danneggiati o mancanti, voci di registro non valide, infezioni da malware, disinstallazioni incomplete o conflitti con altri software. L'origine potrebbe essere una voce di registro danneggiata, la cancellazione accidentale da parte di un altro programma, un download non riuscito o una precedente infezione che ha alterato il file binario.

Come curiosità di inventario, alcuni elenchi documentano l'eseguibile con dimensioni approssimative di 334.720 byte e hash come SHA‑1 e MD5 (ad esempio SHA‑1 d39e8a3fe92adc7d7fbc5293edf8a7b965484a59, MD5 ee738fe9bcdd605821002cec8c7206db) e CRC32 98b1af0b; si riferiscono anche al versione 2.1 nella sua app contenitore e la categoria “Forensic Toolkit/Sistema operativo”.

Metodi di rilevamento e risposta ai rootkit

Rilevare un rootkit non è sempre un'operazione banale. Oltre a strumenti specifici, per identificare i moduli sospetti si combinano tecniche come l'analisi delle firme di minacce note, il confronto a freddo delle strutture, la ricerca di hook e alterazioni nella memoria e l'analisi dei dump di memoria dopo i crash . È inoltre comune affidarsi a sistemi di prevenzione delle intrusioni (IPS) per proteggere la rete e ridurre i vettori di infezione.

Tra le utilità specializzate si annoverano GMER (per rilevare processi nascosti e modifiche al kernel), Kaspersky TDSSKiller (specialmente per rilevare bootkit e rootkit del kernel), Malwarebytes Anti-Rootkit, Microsoft Defender Offline (per la scansione prima dell'avvio di Windows) e RogueKiller. L'esecuzione di questi programmi da un'unità USB avviabile attendibile o in modalità provvisoria riduce la superficie di attacco.

Per le minacce all'avvio o al firmware, è consigliabile utilizzare supporti di ripristino come Kaspersky Rescue Disk, ripristinare l'MBR con bootrec /fixmbr ove appropriato e nei casi più gravi, aggiornare/aggiornare il BIOS/UEFI a una versione pulita del produttore per eliminare persistenza di basso livello.

Il monitoraggio con Sysinternals è prezioso: Process Monitor (ProcMon) per l'attività di processi e file, Autoruns per verificare cosa viene caricato all'avvio e RootkitRevealer per individuare discrepanze di alto e basso livello. Le piattaforme SIEM come Wazuh e la telemetria negli ambienti aziendali possono rilevare comportamenti di rete inattesi o cambiamenti di integrità.

Se viene confermata l'infezione, la procedura corretta è la seguente: disconnettere il computer dalla rete, eseguire una scansione da un ambiente esterno, valutare l'integrità del firmware/boot e, in assenza di garanzie, eseguire il backup dei dati, pulire completamente il disco (con strumenti come DBAN) e reinstallare il sistema operativo da un supporto verificato, abilitando infine misure di sicurezza come Secure Boot e TPM.

Prevenzione: protezione ragionevole contro i rootkit

La prevenzione è fondamentale. Mantieni il tuo sistema aggiornato, applica le patch ai software di terze parti, evita i file eseguibili provenienti da fonti dubbie e non utilizzare crack o keygen: sono uno dei vettori preferiti per la diffusione di dropper e loader di rootkit .

Disabilita l'avvio automatico delle unità USB, esegui la scansione delle unità esterne prima di aprirle e, negli ambienti aziendali, limita o blocca le porte e applica i firewall ove necessario. Lavora con account utente non privilegiati, applica il principio del minimo privilegio e richiedi le credenziali di amministratore per le modifiche critiche, riducendo la probabilità di escalation silenziose.

Su hardware compatibile, abilita Secure Boot e TPM da UEFI per proteggere la catena di avvio e la sigillatura della chiave. Esegui regolarmente backup offline o immutabili e utilizza snapshot/punti di ripristino per ridurre i tempi di recupero in caso di problemi.

Come vengono installati i rootkit: dropper, loader e vettori

In genere, gli aggressori distribuiscono i rootkit come minacce combinate: un "dropper" che consegna il pacchetto e un "loader" che sfrutta le vulnerabilità (come i buffer overflow) per installare il malware in posizioni non consentite. Queste minacce si mascherano da email di phishing , falsi programmi di installazione o aggiornamenti fraudolenti.

I vettori classici includono il dirottamento di client di messaggistica per diffondere link dannosi, l'installazione di trojan su software presenti nei portali di download, l'utilizzo di altri malware come vettori e l'incorporamento in documenti con contenuti multimediali (ad esempio, alcuni PDF) che, una volta aperti, attivano automaticamente il dropper.

Segnali di attacco e indizi di rilevamento

L'obiettivo di un rootkit è quello di rimanere inosservato. Ciononostante, potresti notare modifiche alla configurazione senza intervento dell'utente, interruzioni di rete insolite dovute a traffico nascosto, processi sconosciuti, servizi che non possono essere chiusi e strumenti di sicurezza disabilitati senza alcuna spiegazione.

Un altro indizio è rappresentato dalle informazioni contrastanti fornite dalle utility che elencano file, processi o chiavi di registro utilizzando percorsi diversi (API rispetto alla lettura diretta). È qui che approcci come RootkitRevealer si rivelano particolarmente utili: lo stesso oggetto che "è" presente sul disco ma "non lo è" secondo l'API indica una manipolazione.

Principali tipi di rootkit

Modalità utente: queste operano a livello di processo e di libreria. Sono più stabili e relativamente più facili da rilevare, sebbene possano nascondere file, processi e chiavi. Un classico esempio storico è HackerDefender.

Modalità kernel: questi virus risiedono nel kernel, esercitando un controllo completo e una grande capacità di occultamento; sono difficili da eradicare e tendono a causare instabilità se mal progettati. Esempi di questa famiglia: TDL/Alureon nella sua evoluzione.

Ibridi: combinano componenti utente e del kernel per bilanciare occultamento e stabilità, risultando popolari tra gli aggressori grazie alla loro versatilità pratica.

Firmware/Bootkit: Questi infettano il BIOS/UEFI o il settore di avvio (MBR/UEFI) per caricarsi prima del sistema operativo. Tecnologie come Secure Boot hanno reso obsoleti molti bootkit classici, ma sono emersi nuovi impianti UEFI moderni.

Virtuali e basati sulla memoria: i VMBR caricano un hypervisor al di sotto del sistema operativo e lo virtualizzano; quelli basati sulla memoria risiedono solo nella RAM e scompaiono al riavvio, risultando molto utili per operazioni effimere.

Esempi e cronologia evidenziata

I primi rootkit per SunOS furono sviluppati negli anni '90; nel 1999, Greg Hoglund descrisse NTRootkit (Windows, modalità kernel) e nel 2003 emerse HackerDefender (Windows 2000/XP, modalità utente), il che diede inizio a una "guerra" con strumenti come RootkitRevealer.

Nel 2004, il cosiddetto "Watergate greco" utilizzò un rootkit per hackerare più di 100 telefoni su una rete GSM; nel 2005 si scoprì che Sony BMG aveva incluso un rootkit antipirateria in alcuni CD, scatenando un'enorme controversia sulla sicurezza.

Dal 2008, i bootkit come TDL (TDL-1 a TDL-4) si sono evoluti; nel 2009, "Machiavelli" ha dimostrato che nemmeno macOS (allora Mac OS X) era immune; nel 2010, Stuxnet ha utilizzato componenti di rootkit per sabotare i sistemi industriali iraniani.

Nel 2012 è apparso Flame , un massiccio malware modulare ; nel 2018, LoJax è diventato il primo rootkit UEFI rilevato in circolazione; e nel 2019, Scranos ha combinato il furto di credenziali e la generazione di entrate occulte con le click farm attraverso browser compromessi in massa.

Risorse e letture consigliate

L'indagine di Mark Russinovich sul caso Sony e il suo articolo "Unearthing Rootkits" su Windows IT Pro aiutano a comprendere il fenomeno e la tecnica alla base di RKR; il libro "Rootkits: Subverting the Windows Kernel" di Greg Hoglund e Jamie Butler è il trattato più approfondito sull'argomento.

Il Phrack Archive, "The Art of Computer Virus Research and Defense" di Peter Szor, "Malware: Fighting Malicious Code" di Ed Skoudis e Lenny Zeltser, e la serie "Windows Internals" (dalla quarta edizione in poi) sono materiali essenziali per chiunque voglia approfondire l'architettura e le contromisure più efficaci.

RootkitRevealer nell'ecosistema Sysinternals

RKR coesiste con altre utility Sysinternals utili per la ricerca: AccessChk e AccessEnum (permessi effettivi), Autoruns (tutto ciò che si avvia con il sistema), Process Explorer (chi ha aperto cosa e con quale DLL), PsExec/PsTools (esecuzione e amministrazione remota), PsLogList e PsLoggedOn (eventi e sessioni), Sigcheck (firme digitali), SDelete (eliminazione sicura), ShareEnum (risorse condivise) e Sysmon (telemetria avanzata nel registro eventi).

È frequente trovare riferimenti a "Scarica la versione 1.71" nei repository storici, così come a "Esegui ora" tramite Sysinternals Live. Sebbene il progetto sia di lunga data, la sua filosofia, che confronta approcci di alto livello con approcci di basso livello, rimane fondamentale per la ricerca di rootkit.

RootkitRevealer è, prima di tutto, una lezione di ingegneria difensiva: se qualcosa sta manipolando ciò che l'API restituisce, bisogna guardare sotto e confrontarlo con ciò che effettivamente esiste sul disco e nel Registro di sistema; con buone pratiche, strumenti appropriati e verifiche offline quando necessario, è possibile scoprire cosa sta cercando di nascondersi dove pensiamo che nessuno guarderà.