BTR Reforged trasforma il driver di Defender in un’arma kernel contro EDR e antivirus

🛡️ Executive Summary

• Check Point ha reverse-engineerizzato BTR.sys, driver Microsoft firmato usato da Defender per la remediation al riavvio, trasformandolo in una primitiva kernel riutilizzabile.
• Il driver può cancellare e spostare file, modificare il registro e operare durante una finestra di boot precedente all’avvio completo dei servizi di sicurezza.
• La tecnica non sfrutta una vulnerabilità tradizionale e richiede SeLoadDriverPrivilege: Microsoft non la considera al momento meritevole di servicing immediato.

Microsoft Defender può essere utilizzato contro Microsoft Defender stesso. È il risultato della ricerca BTR Reforged di Check Point, che ha ricostruito completamente il funzionamento di BTR.sys, driver firmato Microsoft impiegato dal motore antimalware per eseguire operazioni di remediation durante il riavvio di Windows. Il componente nasce per eliminare file bloccati e modificare elementi che Defender non può correggere mentre il sistema è pienamente operativo. Una volta compreso il protocollo proprietario utilizzato per impartirgli gli ordini, però, lo stesso driver può diventare una primitiva Ring 0 capace di cancellare file, modificare il registro, aggirare Tamper Protection e neutralizzare componenti EDR prima che lo stack di sicurezza abbia completato l’avvio.

BTR.sys sembrava un driver malevolo ma apparteneva a Defender

La ricerca nasce quasi per errore. Durante un’attività di incident response, Check Point individua sotto System32\drivers un driver con nome casuale, servizio temporaneo, routine RC4, configurazione memorizzata in un Alternate Data Stream e comportamento di self-cleanup. Tutti indicatori che normalmente farebbero pensare a un loader kernel offensivo. L’analisi dimostra invece che il file è una componente legittima di Defender. Nel reverse engineering pubblicato da Check Point Research viene identificato come Boot Time Removal Tool, incorporato come risorsa PE dentro MpEngine.dll e scritto su disco soltanto quando una remediation necessita di un reboot. Defender gli assegna un nome casuale, crea un servizio Start=1, indica il gruppo Boot Bus Extender e passa la configurazione attraverso uno stream :changelist. Questo comportamento è legittimo, ma ha una caratteristica pericolosa: una volta compreso il formato della configurazione, un amministratore può impartire direttamente al driver operazioni diverse da quelle previste dal motore antimalware.

La configurazione usa RC4 e una chiave rimasta invariata per anni

BTR.sys non espone una normale interfaccia IOCTL attraverso cui ricevere comandi. Legge invece dal registro il percorso di un ADS contenente una struttura binaria cifrata RC4. Check Point ha ricostruito header globale, payload, Action ID, checksum e padding necessari perché il driver consideri valida una transazione. L’aspetto più sorprendente è la gestione della chiave: la chiave RC4 da 256 byte è hardcoded nel driver e, analizzando 18 versioni firmate Microsoft, i ricercatori hanno verificato che rimane identica.

Anche il formato della transazione resta sostanzialmente compatibile attraverso generazioni molto differenti di Windows. I test hanno coperto sistemi da Windows 7 Build 7601 fino a Windows 11 25H2, mostrando che il protocollo interno è sopravvissuto per oltre quindici anni. Questa stabilità rende BTR.sys particolarmente interessante dal punto di vista offensivo: non è necessario cercare una versione specifica vulnerabile, perché è la funzione legittima del componente a fornire le primitive.

File e registro diventano modificabili direttamente da Ring 0

Le operazioni individuate comprendono cancellazione di file e directory, spostamento di file, eliminazione di chiavi e valori del registro e creazione o modifica di valori. Il driver può eliminare file anche quando sono bloccati e può spostare un file verso destinazioni protette, permettendo teoricamente di collocare un payload dentro System32. Le operazioni sul registro sono ancora più delicate: la scrittura arbitraria consente di creare chiavi di persistenza, modificare servizi o intervenire sulle configurazioni di sicurezza.

È proprio il tipo di potere che gli attaccanti cercano normalmente attraverso tecniche BYOVD, cioè caricando un driver firmato ma vulnerabile per ottenere capacità privilegiate. Il caso BTR Reforged va oltre quanto osservato nel malvertising W-2 che utilizzava un driver Huawei per disabilitare gli EDR: qui non serve portare sul sistema un driver di terze parti vulnerabile, perché la primitiva è già contenuta in un componente Microsoft legittimo e firmato.

BTR_CLI trasforma la remediation in un motore operativo

Per dimostrare il rischio, Check Point ha realizzato BTR_CLI, strumento di ricerca capace di riprodurre l’intera catena di Defender. Il tool estrae BTR.sys direttamente da MpEngine.dll, costruisce una configurazione cifrata valida, calcola checksum e padding, crea lo stream ADS, registra temporaneamente il driver e ne avvia l’esecuzione. Può concatenare più operazioni all’interno della stessa transazione e rimuovere successivamente gli artefatti creati. La caratteristica più importante è che durante i test non è mai stato necessario portare sul sistema un driver esterno: la copia inclusa nel Defender installato localmente è risultata sufficiente in tutte le versioni provate.

Questo elimina uno dei principali punti di rilevamento delle campagne BYOVD tradizionali, dove il caricamento di un driver anomalo rappresenta spesso un indicatore immediato. L’evoluzione dei ransomware ha già mostrato quanto il kernel sia diventato centrale, come nel caso di GodDamn e del driver PoisonX usato per spegnere gli antivirus, ma BTR.sys introduce il concetto ancora più insidioso di living-off-the-land driver.

La Golden Window permette di colpire Defender prima che sia pienamente operativo

L’attacco più interessante sfrutta l’ordine di caricamento dei componenti Windows. BTR.sys non può funzionare come driver Start=0, perché durante la primissima fase di boot filesystem e oggetti necessari non sono ancora disponibili. Può però essere impostato come System Start, Start=1, all’interno del gruppo Boot Bus Extender. In questa fase NTFS è già utilizzabile, mentre una parte importante dello stack di sicurezza in user mode non è ancora partita. Check Point chiama questo intervallo Golden Window. Nei test su Windows 11 25H2, BTR.sys ha eseguito le proprie operazioni circa 34 secondi prima dell’avvio di MsMpEng.exe, il principale servizio di Defender, e diversi minuti prima del caricamento di altri componenti. Questo consente di cancellare file critici prima che il sistema antimalware possa iniziare a proteggerli pienamente. La logica ricorda il metodo utilizzato da Akira per riavviare Windows in Safe Mode e ridurre la copertura di EDR e Defender, ma in BTR Reforged è lo stesso meccanismo di remediation Microsoft a fornire la finestra privilegiata.

Tamper Protection viene aggirata dal driver che Defender considera legittimo

Il PoC dimostra anche un bypass di Tamper Protection. Una modifica delle chiavi di registro di Defender eseguita normalmente con privilegi amministrativi viene bloccata. Se la stessa richiesta viene affidata a BTR.sys, invece, l’operazione parte dal kernel attraverso un driver Microsoft firmato e riesce. Check Point ha cancellato le chiavi dei servizi WdFilter e WinDefend, impedendo il caricamento corretto delle componenti di protezione al reboot successivo. Durante l’avvio ha inoltre dimostrato la cancellazione fisica di WdFilter.sys, MsMpEng.exe e altri binari. Dopo la neutralizzazione, un driver malevolo precedentemente rilevato da Defender può essere estratto e collocato nella directory dei driver senza essere intercettato. La dinamica mostra perché la firma digitale non sia più sufficiente come indicatore di fiducia, problema già evidente nel rootkit CoolClient di Mustang Panda e nell’abuso crescente dei componenti kernel.

Non è una CVE e Microsoft non prepara un fix immediato

Il dettaglio più importante è che BTR Reforged non sfrutta una vulnerabilità tradizionale. Non esiste memory corruption, use-after-free o authentication bypass nel driver. L’attaccante utilizza funzionalità che BTR.sys è stato progettato realmente per eseguire. Serve inoltre già un livello di accesso elevato: la tecnica richiede SeLoadDriverPrivilege, quindi un aggressore deve avere ottenuto privilegi amministrativi sufficienti per caricare un driver kernel. Dopo la responsible disclosure, Microsoft Security Response Center ha comunicato a Check Point che il comportamento non soddisfa i criteri per un intervento di servicing immediato proprio perché dipende da privilegi amministrativi già compromessi. La posizione è tecnicamente comprensibile, ma il rischio operativo resta importante: ottenere Administrator e ottenere una primitiva kernel firmata Microsoft capace di disarmare l’EDR sono due risultati molto diversi. Il secondo permette di consolidare l’accesso e preparare fasi successive dell’attacco con una visibilità drasticamente ridotta.

Le blocklist dei driver vulnerabili non possono risolvere il problema

La tradizionale Microsoft Vulnerable Driver Blocklist non è sufficiente in questo scenario. BTR.sys non è un vecchio driver di terze parti vulnerabile che Microsoft può semplicemente vietare senza conseguenze: è una componente utilizzata dal proprio sistema di remediation. Bloccarla significherebbe interferire con Defender stesso. Il problema quindi passa dal riconoscimento dell’hash alla telemetria comportamentale. Check Point suggerisce di monitorare la creazione di stream .sys:changelist, caricamenti del driver provenienti da processi diversi dall’ecosistema Defender, servizi temporanei nel gruppo Boot Bus Extender e creazioni anomale di chiavi sotto HKLM\SYSTEM\CurrentControlSet\Services. Anche il file BootClean.log rappresenta un indicatore interessante: BTR.sys lo crea automaticamente e il PoC può ordinare al driver di cancellarlo durante la stessa transazione, riducendo le tracce forensi. È un cambio di paradigma già evidente quando Windows ha iniziato a bloccare driver vulnerabili causando incompatibilità con software legittimi di backup: il problema non è più soltanto stabilire se un driver sia firmato, ma comprendere chi lo sta caricando e perché.

Check Point non osserva ancora abusi reali della tecnica

Al momento della pubblicazione Check Point afferma di non avere individuato evidenze di BTR.sys utilizzato in natura secondo il metodo dimostrato da BTR Reforged. È un elemento importante, perché separa un PoC tecnicamente funzionante da una tecnica già adottata da ransomware o gruppi APT. La pubblicazione offre però agli attaccanti una mappa molto dettagliata del protocollo, e la disponibilità del tool rende inevitabile che i difensori inizino a cercarne le tracce prima che compaiano campagne reali. Il caso mostra anche quanto sia diventato fragile il confine tra security tool e offensive primitive. Defender possiede BTR.sys precisamente perché deve poter modificare file e registro quando il malware tenta di impedirglielo. Quelle stesse capacità diventano pericolose quando un attaccante con privilegi elevati può impartire al driver ordini propri. BTR Reforged non scopre quindi una semplice falla: dimostra che una funzione difensiva abbastanza potente può diventare un’arma senza essere mai stata vulnerabile.