BYOVD senza Hardware: driver kernel Windows attaccabili emulando dispositivi Plug and Play con ID falsi

Nel panorama della sicurezza informatica su Windows i driver in kernel mode rappresentano un bersaglio di grande valore. Oltre alla classica escalation di privilegi locale, i driver vulnerabili vengono spesso sfruttati in attacchi BYOVD (bring your own vulnerable driver), una tecnica post exploitation usata per aggirare o disattivare difese come EDR e componenti di sicurezza resistenti al tampering.

La difficoltà pratica è che molte vulnerabilità sembrano sfruttabili solo quando è presente l’hardware per cui il driver è stato progettato, perché certe porzioni di codice sono raggiungibili solo dopo specifiche fasi Plug and Play.

Il punto chiave è capire la raggiungibilità del codice dal user mode attraverso i device object. Se un driver crea un device object nominato subito al caricamento, spesso basta installarlo come servizio e avviarlo per poter aprire un handle e inviare richieste come DeviceIoControl. Molti driver però creano i loro device object solo quando il PnP manager invoca la routine AddDevice, evento che avviene quando viene rilevato un device node compatibile con gli hardware ID dichiarati nel file INF. Senza quel passaggio il driver può non creare alcun punto di ingresso o non inizializzare lo stato interno necessario a raggiungere il percorso vulnerabile.

Per aggirare l’assenza di hardware esiste un approccio efficace in ottica BYOVD che resta in userland con privilegi amministrativi: creare dispositivi software emulati con hardware ID falsificati. Strumenti e componenti di Windows permettono di generare un nuovo device node e poi forzare l’installazione del driver associato tramite INF. In questo modo il PnP manager richiama AddDevice e il driver può creare FDO o CDO e inserirsi in uno stack valido, rendendo spesso possibile l’apertura dell’handle grazie a IRP_MJ_CREATE gestito da un driver nello stack. Questo metodo aumenta sensibilmente il numero di driver interagibili rispetto al semplice caricamento come servizio.

Un ulteriore aspetto è che alcuni stack possono bloccare l’accesso dal user mode se i livelli superiori negano o non supportano IRP_MJ_CREATE. Manipolare lo stacking con filtri di classe o restacking su classi comuni può rendere accessibili anche driver che normalmente non lo sarebbero, ampliando la superficie di attacco e la fattibilità di exploit BYOVD senza hardware reale.