EDR e software di sicurezza non vedono tutto: persistenza malware invisibile su Windows

Nel mondo della sicurezza, il registro di Windows è uno degli aspetti del sistema operativo Microsoft più monitorati in assoluto. Il registro è essenziale perché contiene tutte le configurazioni di sistema, delle applicazioni e degli utenti: cambiamenti sospetti possono indicare la presenza di malware, accessi non autorizzati o tentativi di manipolare il sistema. Monitorandolo si possono rilevare e prevenire problemi prima che diventino criticità gravi.

Le tecniche di persistenza (metodi utilizzati da malware o attaccanti per mantenere l’accesso a un sistema nel tempo, assicurandosi di riattivarsi automaticamente dopo riavvii, logout o aggiornamenti) che sfruttano chiavi del registro di Windows come Run, Winlogon o UserInit sono ben note da anni e rappresentano una superficie di attacco ormai fortemente presidiata dalle soluzioni EDR (Endpoint Detection and Response).

Una ricerca pubblicata da DeceptIQ dimostra però che questa copertura ha un presupposto implicito: si assume che ogni modifica al registro passi attraverso le API di Windows. Si tratta di un’assunzione falsa e pericolosa.

Come gli EDR monitorano il registro

Quando un processo scrive nel registro (ad esempio tramite le note funzioni RegSetValueEx, RegCreateKeyEx, ecc.), la richiesta attraversa il Configuration Manager del kernel Windows.

Le soluzioni di sicurezza non possono intercettare direttamente il flusso di esecuzione del kernel (hooking), poiché PatchGuard (meccanismo di protezione del kernel di Windows) impedisce modifiche non autorizzate alle strutture interne del sistema operativo. L’unico approccio utile e supportato, quindi, consiste nell’usare un’API ufficiale, CmRegisterCallbackEx, che consente a un driver di registrare una funzione di callback chiamata prima e dopo ogni operazione sul registro.

Il callback riceve il percorso completo della chiave del registro di Windows, il tipo di operazione, l’indicazione dei dati scritti, processo e thread chiamante.

Le regole EDR (Defender, Elastic, CrowdStrike, ecc.) si basano sul monitoraggio di due elementi:

• Posizioni sensibili del registro (Run, Winlogon, Shell, ecc.).
• Scritture osservabili tramite callback.

Se una chiave sospetta viene modificata, scatta il callback, l’EDR genera un evento e il software decide come comportarsi di conseguenza. Tutto funziona se e solo se avviene una scrittura a runtime del registro di sistema.

NTUSER.MAN: una funzionalità dimenticata

Il contenuto della chiave HKEY_CURRENT_USER, contenente un ampio ventaglio di informazioni relative all’account utente Windows correntemente in uso, è conservata sull’unità di memorizzazione come C:\Users\<username>\NTUSER.DAT.

Quando un utente effettua il logon, Windows legge NTUSER.DAT, lo carica in memoria e lo monta sotto HKEY_USERS\<SID>. Infine, crea l’alias HKEY_CURRENT_USER nel registro.

Come sottolineano i tecnici di DeceptIQ, il caricamento di una hive (contenitore fisico su disco dei dati del registro: HKEY_CURRENT_USER o HKEY_LOCAL_MACHINE sono solo viste in memoria di quei dati) NON è una scrittura di registro: corrisponde semplicemente a un’operazione di I/O su file.

Windows supporta anche i profili obbligatori (mandatory profiles), pensati per chioschi, postazioni condivise e ambienti bloccati. La differenza è che queste configurazioni sono gestite con hive per HKEY_CURRENT_USER conservati non sotto forma di NTUSER.DAT, ma come NTUSER.MAN.

La scoperta di DeceptIQ: il punto cieco che mette al tappeto le soluzioni EDR

DeceptIQ ha messo in evidenza un fatto semplice ma potentissimo: come abbiamo visto in precedenza, il caricamento di una hive non attiva i registry callback perché non si utilizza nessuna API del registro: il kernel sta solo caricando un file binario. Se il contenuto del registro è già “preconfezionato” dentro una hive prima del caricamento, l’EDR non ha alcuna possibilità di sapere come quelle chiavi siano arrivate lì.

Quando Windows deve caricare il profilo di un utente, controlla se esiste NTUSER.MAN. Se esiste, lo carica al posto di NTUSER.DAT: non esegue merge, non valida differenze, non registra eventi di modifica. Dal punto di vista pratico, tutto ciò che è contenuto in NTUSER.MAN diventa HKEY_CURRENT_USER per la sessione corrente.

DeceptIQ osserva che se il contenuto del registro utente può essere definito prima del logon, e se il caricamento di tale contenuto non produce eventi di modifica, allora è possibile introdurre chiavi di persistenza senza mai eseguire una scrittura di registro osservabile. Le chiavi non vengono create durante la sessione; esistono già nel momento in cui HKEY_CURRENT_USER prende forma, all’avvio del sistema.

Quando l’utente effettua il logon, il sistema operativo non ha modo di distinguere una hive “legittima” da una hive “preparata” da un attaccante. Non esiste un concetto di “chiave nuova” nel momento del caricamento, perché non c’è uno stato precedente con cui effettuare un confronto. Dal punto di vista dell’EDR, il registro è sempre stato in quella condizione.

Una debolezza che potrebbe essere sfruttata per far danni senza che l’EDR se ne accorga

Il valore della ricerca di DeceptIQ risiede nell’aver dimostrato che la sicurezza del registro, così come concepita oggi, è incompleta. Monitorare le API non equivale a monitorare lo stato del sistema nel suo complesso.

Finché le soluzioni di sicurezza (i.e. EDR) continueranno a osservare solo le operazioni e non la materializzazione iniziale delle hive, esisteranno sempre tecniche capaci di posizionarsi prima che l’osservazione abbia inizio.

C’è da dire che un profilo utente è spesso il risultato di anni di stratificazione di configurazioni e impostazioni di sistema. Generare una hive NTUSER.MAN incompleta o generica produce effetti immediatamente visibili, come errori in Esplora file, applicazioni che non partono o impostazioni che si resettano. Per questo motivo, l’approccio realistico non consiste nel creare una hive da zero, ma nel partire da quella reale dell’utente, modificarla offline e reintrodurla sotto forma di NTUSER.MAN. Ad esempio con uno strumento software come HideSwarming.