Un driver che Windows non può bloccare

Per anni la regola d’oro della difesa contro gli attacchi BYOVD (Bring Your Own Vulnerable Driver) è stata semplice: se un driver firmato è vulnerabile, lo si aggiunge alla Microsoft Vulnerable Driver Blocklist e lo si blocca via Windows Defender Application Control (WDAC) o HVCI. Il problema è cosa succede quando il driver “vulnerabile” non è di terze parti, ma fa parte di Windows Defender stesso, ed è necessario al suo funzionamento.

È esattamente lo scenario descritto da Check Point Research nella pubblicazione “BTR Reforged”, firmata dal ricercatore Jiří Vinopal: il driver BTR.sys (Boot Time Removal Tool), componente integrato di Defender e presente in ogni installazione Windows da Windows 7 fino a Windows 11 25H2, può essere estratto, installato manualmente ed eseguito in una finestra di avvio in cui opera con pieni privilegi kernel (Ring 0), prima che i servizi di sicurezza siano attivi.

Cos’è BTR.sys e perché esiste

BTR.sys non è un file a sé stante distribuito con l’installer: è incorporato come risorsa (BOOTTIMETOOL) dentro MpEngine.dll, il motore di scansione di Defender. Il suo scopo legittimo è rimuovere malware particolarmente persistente durante il boot, quando il filesystem è ancora scrivibile ma i processi in user-mode non sono ancora attivi: file bloccati, chiavi di registro danneggiate, artefatti lasciati da rootkit. Per fare questo ha bisogno, ed è progettato per avere, la capacità di cancellare file protetti, spostare oggetti in percorsi come System32\drivers ed eliminare o riscrivere chiavi di registro senza i normali controlli ACL.

Il punto debole individuato da Vinopal non è un bug di memoria o un buffer overflow, ma un problema architetturale di trust boundary: il protocollo di comunicazione con il driver è proprietario e non documentato, ma non è mai cambiato in modo sostanziale. Ogni pacchetto di configurazione inviato a BTR.sys è cifrato con RC4 usando una chiave a 256 byte hardcoded nel binario, rimasta identica per 18 versioni a 64 bit del driver. Una volta ricostruito il formato del protocollo, chiunque può parlare con BTR.sys come farebbe Defender stesso.

Come funziona l’attacco

Il proof-of-concept pubblico, denominato BTR_CLI, segue tre fasi:

• Estrazione: individua MpEngine.dll sul sistema e ne estrae il binario BTR.sys incorporato.
• Installazione “silenziosa”: registra il driver come servizio scrivendo direttamente nelle chiavi di registro sotto HKLM, bypassando completamente il Service Control Manager. Questo significa nessun log applicativo standard e, soprattutto, nessun Windows Event ID 7045 (“Service Installed”), l’evento su cui si basano molte regole SIEM per rilevare l’installazione di nuovi driver.
• Esecuzione nella “golden window”: durante la finestra di avvio in cui il filesystem è scrivibile ma Defender non ha ancora avviato i propri servizi di protezione, BTR.sys esegue in Ring 0 le operazioni richieste: cancellazione di file e directory bloccati (inclusi eseguibili di EDR e antivirus di terze parti), spostamento di file arbitrari in percorsi di sistema e manipolazione di chiavi di registro critiche.

Il requisito d’accesso non è banale ma nemmeno estremo: serve un account amministratore che possieda (o a cui venga assegnato, dato che BTR_CLI se ne occupa automaticamente per gli account già idonei) il privilegio SeLoadDriverPrivilege. È lo stesso privilegio necessario per caricare qualunque driver kernel, quindi in molti ambienti aziendali è più diffuso di quanto si pensi tra account di servizio e amministratori locali.

Perché non basta la blocklist

La differenza sostanziale rispetto ai classici attacchi BYOVD è che qui non si tratta di un driver di terze parti compromesso da revocare. BTR.sys è parte integrante di Defender: aggiungerlo alla Vulnerable Driver Blocklist o bloccarlo tramite WDAC significherebbe rompere una funzionalità legittima di Defender su tutte le macchine Windows. Microsoft Security Response Center, contattato da Check Point, ha confermato che la scoperta non soddisfa i criteri per una patch immediata, perché la tecnica presuppone privilegi amministrativi già ottenuti dall’attaccante — la classica linea di demarcazione “non è una vulnerabilità se serve già essere admin”. Il repository pubblico del proof-of-concept riporta inoltre l’indicazione “no patch is planned”, per quanto non si tratti di una dichiarazione ufficiale confermata pubblicamente da Microsoft.

Per un sistemista questo cambia l’approccio: non è un problema che si risolve con l’ennesimo aggiornamento, ma con il monitoraggio e con il controllo rigoroso di chi può caricare driver.

Come rilevare l’abuso in produzione

Check Point Research suggerisce alcuni indicatori concreti da integrare nelle regole di detection, in particolare su ambienti che usano Sysmon:

• Monitorare gli Alternate Data Stream (Sysmon Event ID 15) il cui nome termina con .sys:changelist, una firma tipica del comportamento di BTR.sys durante l’installazione.
• Correlare eventi di registro (Sysmon RegistryEvent, ID 12-13) relativi al gruppo di servizio “Boot Bus Extender” in assenza del corrispondente Event ID 7045: se il driver viene registrato in quel gruppo senza che il Service Control Manager risulti coinvolto, è un forte indicatore di installazione manuale.
• Osservare la creazione e cancellazione rapida del file \SystemRoot\Temp\BootClean.log da parte del processo System (PID 4): è l’artefatto lasciato dall’esecuzione del BTR durante il boot.

Queste regole non richiedono un nuovo prodotto: si possono implementare con la configurazione Sysmon esistente e instradarle verso il proprio SIEM (Sentinel, Splunk, Elastic) come regole di correlazione dedicate.

Mitigazione: il controllo primario resta l’accesso

Dato che non esiste una patch e la blocklist non è applicabile, la mitigazione più efficace, secondo i ricercatori, è restringere l’assegnazione del privilegio SeLoadDriverPrivilege tramite Group Policy, riducendolo ai soli account e gruppi che ne hanno realmente bisogno. In pratica:

• Verificare in Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Load and unload device drivers quali account e gruppi sono attualmente autorizzati.
• Rimuovere l’assegnazione implicita agli amministratori locali dove non strettamente necessaria, valutando l’uso di Privileged Access Workstation (PAW) per le operazioni che richiedono davvero il caricamento di driver.
• Applicare il principio dei privilegi minimi anche agli account di servizio, spesso dimenticati in questo tipo di audit.
• Integrare le regole Sysmon indicate sopra in un dashboard di detection dedicato, dato che la tecnica è pensata per non lasciare tracce negli event log standard.

Il caso BTR Reforged è un promemoria utile: man mano che gli attaccanti spostano l’attenzione dai driver di terze parti facilmente blocklistabili verso componenti “fidati per definizione” dei sistemi operativi, il perimetro difensivo si sposta sempre di più dal software alla gestione dei privilegi. Anche in assenza di una patch, un controllo rigoroso di chi può caricare driver e una detection basata su comportamento restano la difesa più solida disponibile oggi.

Fonte: Check Point Research, “BTR Reforged: Weaponizing Defender’s Remediation Driver as a Kernel Operation Primitive”, ripreso da 4sysops.