EDR killer BYOVD non è un concetto nuovo. Ma nel febbraio 2026 è diventato qualcosa di diverso: non più una tecnica di nicchia riservata ai gruppi APT più sofisticati, bensì lo strumento standard – quasi banale – con cui il ransomware acceca le difese endpoint prima ancora di cifrare il primo file.

Nelle prime due settimane di febbraio 2026 sono accaduti due eventi che, presi insieme, segnano un punto di non ritorno. Il primo: Huntress ha documentato un’intrusione in cui gli attaccanti hanno utilizzato un driver del tool forense EnCase – con certificato scaduto nel 2010 e successivamente revocato – per terminare 59 prodotti di sicurezza endpoint dalla modalità kernel. Il secondo: il Symantec and Carbon Black Threat Hunter Team ha rivelato che un ransomware emergente battezzato Reynolds ha integrato un driver vulnerabile direttamente nel proprio payload, fondendo evasione difensiva e cifratura in un unico binario.

La convergenza di questi due episodi racconta una storia che va ben oltre il singolo incidente. Racconta il fallimento strutturale di un modello di sicurezza endpoint su cui le organizzazioni hanno investito miliardi, e che gli attaccanti stanno imparando a spegnere con un driver firmato di vent’anni fa.

Che cos’è il BYOVD e perché funziona ancora nel 2026

La tecnica Bring Your Own Vulnerable Driver – BYOVD – è concettualmente disarmante nella sua semplicità. L’attaccante non scrive un driver malevolo, non cerca di aggirare la firma digitale, non sfrutta uno zero-day nel kernel. Porta con sé un driver perfettamente legittimo, firmato da un vendor riconosciuto, che contiene una vulnerabilità nota. Poiché il driver è firmato, Windows lo carica senza protestare. Una volta in esecuzione nello spazio kernel, l’attaccante sfrutta la falla del driver per terminare i processi di sicurezza con privilegi di sistema.

Il meccanismo tecnico si articola in passaggi precisi. Il malware deposita il driver vulnerabile su disco, tipicamente mascherandolo come componente OEM legittimo. Registra il driver come servizio kernel di Windows, garantendosi persistenza al riavvio. Una volta caricato, il driver espone un’interfaccia IOCTL (Input/Output Control) che consente ai processi in user-mode di inviare comandi con privilegi kernel. A quel punto, il malware compila un elenco dei processi di sicurezza da terminare – nell’incidente documentato da Huntress, l’elenco comprendeva 59 prodotti tra EDR e antivirus – e li uccide uno per uno, in un ciclo continuo con intervallo di un secondo che impedisce qualsiasi riavvio automatico del processo protettivo.

Il risultato è che l’attaccante opera “al buio”: nessun alert, nessuna telemetria, nessun rilevamento comportamentale. L’EDR non è stato aggirato; è stato spento.

Ciò che rende questa tecnica devastante nel 2026 non è la sua novità – il BYOVD è documentato da anni nel framework MITRE ATT&CK sotto T1068 e T1562.001 – ma la sua industrializzazione. Come ha osservato Broadcom/Symantec nel report sul ransomware Reynolds, il BYOVD è oggi di gran lunga la tecnica di evasione difensiva più utilizzata dagli operatori ransomware.

Il caso Huntress: un driver forense del 2006 che spegne 59 EDR nel 2026

All’inizio di febbraio 2026, i ricercatori di Huntress hanno risposto a un incidente che illustra perfettamente il paradosso del BYOVD. Gli attaccanti hanno ottenuto l’accesso iniziale tramite credenziali compromesse di una VPN SonicWall SSL priva di autenticazione multifattore. Fin qui, nulla di sorprendente: credenziali rubate e assenza di MFA sono il biglietto d’ingresso standard per il ransomware nel 2026.

La fase successiva è quella che merita attenzione. Gli attaccanti hanno distribuito un EDR killer personalizzato che conteneva, codificato al suo interno, il driver kernel EnPortv.sys – un componente dell’EnCase forensic suite sviluppato da Guidance Software. Questo driver era stato firmato con un certificato emesso il 15 dicembre 2006, scaduto il 31 gennaio 2010 e successivamente revocato.

Eppure Windows lo ha caricato. Come è possibile?

La risposta sta in una scelta architetturale che Microsoft ha fatto nel 2015 per garantire la retrocompatibilità. A partire da Windows 10 versione 1607, tutti i nuovi driver kernel devono essere firmati tramite il Hardware Dev Center di Microsoft. Tuttavia, per non rompere il software legacy, è stata introdotta un’eccezione: i driver firmati con certificati emessi prima del 29 luglio 2015, che si concatenano a un’autorità di certificazione cross-signed supportata, possono ancora essere caricati. Il driver EnCase rientra pienamente in questa eccezione.

C’è un secondo meccanismo che sigilla il problema. Come hanno spiegato i ricercatori di Huntress: quando il codice è firmato con un timestamp, Windows valida la firma rispetto al momento in cui è stata creata, non rispetto alla data corrente. Poiché il driver è stato timestampato quando il certificato era ancora valido, la firma rimane valida a tempo indeterminato. Il kernel, inoltre, non verifica le Certificate Revocation List al boot, per ragioni di performance.

Il risultato netto è che un driver con certificato scaduto da 16 anni e revocato continua a caricarsi ed eseguirsi nello spazio kernel di qualsiasi sistema Windows moderno.

Una volta caricato, il driver esponeva l’interfaccia IOCTL 0x223078 (KillProc). Il componente in user-mode apriva un handle verso il dispositivo del driver (\.\OemHwUpd) e inviava i PID dei processi target tramite DeviceIoControl. Il driver, operando in kernel-mode, invocava ZwOpenProcess con accesso PROCESS_TERMINATE seguito da ZwTerminateProcess. Quando il codice kernel-mode chiama le funzioni Zw*, il wrapper imposta PreviousMode a KernelMode, segnalando che i parametri provengono da una sorgente fidata: Windows salta interamente la validazione di sicurezza che applicherebbe ai chiamanti in user-mode.

L’EDR killer compilava un elenco interno di 59 processi di sicurezza associati ai principali vendor – tra cui Avast, CrowdStrike Falcon, Cortex XDR, Sophos, HitmanPro.Alert e Symantec – utilizzando hash dei nomi dei processi per l’identificazione. Il kill loop, eseguito con un intervallo di un secondo, terminava immediatamente qualsiasi processo di sicurezza che tentasse di riavviarsi.

Un dettaglio tecnico particolarmente ingegnoso: l’EDR killer non conservava il driver come byte grezzi. Utilizzava uno schema di codifica basato su un dizionario di 256 parole inglesi incorporate nel binario, dove ogni parola corrispondeva a un valore di byte specifico. Il payload codificato appariva come testo inglese innocuo, eludendo efficacemente gli strumenti di analisi statica. Una volta decodificato, il malware scriveva il driver su disco sotto un percorso che imitava un componente OEM legittimo, nascondeva il file e copiava i timestamp da un file di sistema reale per integrarsi con l’ambiente.

L’attacco è stato interrotto prima del deployment del ransomware, ma il messaggio è inequivocabile: con un driver di vent’anni fa, un attaccante può accecare l’intero stack di sicurezza endpoint.

Reynolds: quando il ransomware porta l’EDR killer nel proprio DNA

Se l’incidente documentato da Huntress rappresenta il modello classico – EDR killer come tool separato, dispiegato prima del ransomware – il caso Reynolds, analizzato dal Symantec and Carbon Black Threat Hunter Team e reso pubblico il 10 febbraio 2026, segna un’evoluzione tattica significativa.

Reynolds è una famiglia ransomware emergente che ha integrato il componente BYOVD direttamente all’interno del payload di cifratura. Il driver vulnerabile utilizzato è NSecKrnl di NsecSoft, affetto dalla vulnerabilità CVE-2025-68947, che consente la terminazione arbitraria dei processi senza verifica dei permessi adeguati. Lo stesso driver era stato precedentemente usato dal gruppo Silver Fox per distribuire il RAT ValleyRAT.

Al momento dell’esecuzione, Reynolds deposita il driver NSecKrnl.sys in una directory di sistema, lo carica nello spazio kernel e lo utilizza per terminare i processi di sicurezza di Avast, CrowdStrike Falcon, Palo Alto Networks Cortex XDR, Sophos e Symantec Endpoint Protection. Solo dopo aver reso cieche le difese, il ransomware avvia la routine di cifratura, aggiungendo l’estensione “.locked” ai file compromessi.

L’integrazione presenta vantaggi tattici evidenti. Come ha osservato Dick O’Brien, principal intelligence analyst di Symantec, rilasciare un unico file anziché due è più silenzioso e riduce le probabilità di rilevamento. Inoltre, eliminando l’intervallo temporale tra il dispiegamento dell’EDR killer e l’esecuzione del ransomware, si chiude la finestra in cui i difensori potrebbero intervenire.

Tuttavia, questa integrazione comporta anche un rischio per l’attaccante: consolidare evasione difensiva e cifratura in un’unica catena di esecuzione aumenta la densità comportamentale del binario, incrementando la probabilità di rilevamento da parte di soluzioni con monitoraggio comportamentale avanzato. Non a caso, nell’incidente analizzato da Symantec, il prodotto endpoint dell’azienda ha continuato a funzionare nonostante il tentativo di terminazione. Sophos, da parte sua, ha dichiarato a The Hacker News di disporre di protezioni di blocco contro questo specifico driver dal novembre 2025 e di safeguard proattivi contro il payload da diversi anni – un’indicazione che i vendor più maturi stanno evolvendo le difese, ma anche che la corsa tra attaccanti e difensori è continua.

Dopo l’iniziale attribuzione a Black Basta – basata sulla somiglianza delle TTP – un’analisi più approfondita ha portato Symantec a classificare Reynolds come famiglia ransomware distinta. Non è chiaro se rappresenti un rebrand o uno spin-off di Black Basta, ma l’evoluzione tattica che porta con sé è indipendente dall’attribuzione: il BYOVD integrato nel payload è una tendenza, non un caso isolato.

Lo stesso report di Broadcom ha osservato che la pratica di incorporare la componente di evasione difensiva direttamente nel payload ransomware non è del tutto inedita: era stata documentata in un attacco Ryuk nel 2020 e in un incidente legato a un ransomware meno noto chiamato Obscura alla fine di agosto 2025. Tuttavia, ciò che distingue Reynolds è la maturità dell’integrazione e il suo posizionamento in un ecosistema dove il BYOVD embedded potrebbe diventare requisito standard per attrarre affiliati nei programmi RaaS.

EDRKillShifter e la collaborazione cross-gang: il BYOVD come lingua franca del ransomware

Il fenomeno dell’EDR killer BYOVD non si esaurisce nei due episodi di febbraio 2026. Per comprenderne la portata sistemica, è necessario guardare a ciò che ESET ha documentato nel marzo 2025: la scoperta di EDRKillShifter, un tool EDR killer sviluppato e mantenuto da RansomHub come parte integrante del proprio programma Ransomware-as-a-Service.

EDRKillShifter è un software specializzato che utilizza la tecnica BYOVD per disabilitare i prodotti EDR sugli endpoint compromessi. Ciò che lo rende particolarmente significativo è la decisione di RansomHub di offrirlo direttamente ai propri affiliati – una scelta rara nel panorama RaaS, dove tipicamente gli affiliati devono procurarsi autonomamente gli strumenti per l’evasione difensiva.

La scoperta più rilevante di ESET, tuttavia, riguarda la diffusione cross-gang dello strumento. Tracciando l’uso di specifici campioni di EDRKillShifter, i ricercatori hanno identificato un singolo threat actor – denominato QuadSwitcher – che ha condotto attacchi per conto di quattro diverse operazioni ransomware: RansomHub, Play, Medusa e BianLian. Tutti gli attacchi coinvolgevano gli stessi campioni di EDRKillShifter e gli stessi server C2.

Il fatto che Play e BianLian – gang che operano tradizionalmente sotto modelli RaaS chiusi, basati sulla fiducia a lungo termine – utilizzino strumenti di un rivale come RansomHub suggerisce un livello di collaborazione senza precedenti nell’ecosistema ransomware. Come hanno teorizzato i ricercatori ESET, membri fidati di Play e BianLian stanno collaborando con rivali e riutilizzando gli strumenti ricevuti nelle proprie operazioni.

Questa dinamica trasforma l’EDR killer BYOVD da strumento tattico a infrastruttura condivisa dell’ecosistema ransomware. Non è più una capacità proprietaria di un singolo gruppo: è una commodity, un servizio, una lingua franca del cybercrime organizzato.

Perché Windows non può semplicemente “risolvere” il problema

Qualsiasi professionista della sicurezza, a questo punto, si pone la domanda ovvia: perché Microsoft non blocca semplicemente i driver con certificati scaduti o revocati?

La risposta è più complessa di quanto sembri e tocca uno dei trade-off più delicati dell’architettura Windows: la retrocompatibilità.

L’eccezione per i driver firmati prima del 29 luglio 2015 non è un bug – è una policy deliberata. Milioni di dispositivi hardware in produzione dipendono da driver legacy firmati con certificati di quel periodo. Revocare unilateralmente l’eccezione significherebbe potenzialmente causare crash di sistema, schermate blu e malfunzionamenti hardware su una scala difficile da quantificare.

Microsoft ha scelto un approccio alternativo: la Vulnerable Driver Blocklist, una lista di driver noti come vulnerabili o malevoli, implementata come policy Windows Defender Application Control (WDAC). A partire da Windows 11 versione 22H2, questa blocklist è abilitata di default su tutti i dispositivi. Viene aggiornata con ogni release principale di Windows, tipicamente una o due volte l’anno.

Il problema evidente di questo approccio è che è intrinsecamente reattivo: solo i driver già noti come weaponizzati finiscono nella lista. Ogni nuovo driver vulnerabile scoperto dagli attaccanti ha una finestra di esposizione fino al prossimo aggiornamento. In un ecosistema dove esistono centinaia di migliaia di driver firmati accumulati in decenni di sviluppo hardware, la superficie di attacco potenziale è virtualmente illimitata.

C’è poi un secondo problema, documentato nel CVE-2025-59033: la blocklist, implementata come policy WDAC, presenta un comportamento diverso a seconda che HVCI sia attivo o meno. Sui sistemi senza HVCI, alcune voci della blocklist che specificano il TBS hash del certificato insieme a qualificatori FileAttribRef (come nome del file o versione) possono non essere bloccate correttamente. Microsoft ha contestato l’assegnazione del CVE, affermando che la blocklist è progettata per funzionare con HVCI attivo e che i sistemi senza HVCI dovrebbero utilizzare App Control con policy personalizzate.

Ma questo sposta il problema anziché risolverlo: nella realtà operativa, HVCI non è attivo sulla maggioranza degli endpoint enterprise. Molte organizzazioni lo disabilitano per ragioni di compatibilità con driver legacy, impatto sulle performance o, più semplicemente, perché non ne conoscono l’esistenza o la funzione. Il risultato è una protezione che esiste sulla carta ma non nel data center.

L’inventario degli strumenti: gli EDR killer che stanno ridefinendo il playbook ransomware

Il panorama degli EDR killer BYOVD nel 2026 è variegato e in rapida espansione. Comprenderne la tassonomia è essenziale per chi deve costruire strategie difensive.

TrueSightKiller sfrutta il driver truesight.sys ed è uno degli strumenti pubblicamente disponibili più utilizzati nelle intrusioni ransomware recenti.

AuKill, documentato da Sophos, utilizza una versione obsoleta del driver impiegato dall’utility Microsoft Process Explorer per disabilitare i processi EDR prima del deployment del ransomware.

Poortry (noto anche come BurntCigar) è un driver malevolo frequentemente impiegato insieme al loader Stonestop. A differenza dei tool precedenti, Poortry è stato firmato con certificati rubati o ottenuti fraudolentemente, aggiungendo un ulteriore livello di sofisticazione.

GhostDriver e Warp AVKiller completano l’arsenale più frequentemente osservato, con quest’ultimo che sfrutta un driver anti-rootkit di Avira per disabilitare i prodotti di sicurezza.

Un caso particolarmente emblematico della diversificazione in atto riguarda il gruppo Interlock, che ha sviluppato un tool denominato “Hotta Killer” per sfruttare un zero-day in un driver anti-cheat gaming – GameDriverx64.sys, tracciato come CVE-2025-61155 – in attacchi BYOVD contro organizzazioni del settore educativo in UK e USA. L’intrusione, analizzata da FortiGuard, è particolarmente istruttiva perché illustra la convergenza di più tecniche offensive in un’unica campagna: l’accesso iniziale è avvenuto tramite tattiche di social engineering ClickFix per distribuire il payload MintLoader, seguito dal deployment del RAT NodeSnake per il movimento laterale, e infine dall’uso di Hotta Killer per disabilitare le difese prima della cifratura.

Il driver, rinominato UpdateCheckerX64.sys, veniva caricato come servizio kernel e comunicava tramite un link simbolico, esponendo un IOCTL (0x222040) con un magic flag (0xFA123456) per terminare i processi di sicurezza. Il caso Interlock è significativo perché dimostra che gli attaccanti non si limitano più ai driver di sicurezza o forensics: qualsiasi driver firmato con accesso kernel – inclusi quelli dei videogiochi – è un potenziale vettore BYOVD.

La portata del fenomeno ha spinto la Cyber Security Agency di Singapore (CSA) a pubblicare un advisory dedicato agli EDR killer, segnalando che almeno otto gruppi ransomware utilizzano attivamente strumenti di questo tipo. L’advisory ha evidenziato caratteristiche chiave condivise tra i tool: framework collaborativo tra gang, randomizzazione dei nomi dei driver, capacità di auto-scompattamento in memoria e uso di certificati rubati o scaduti.

La lista non è statica. Come ha evidenziato la ricerca di ESET su RansomHub, i ricercatori hanno osservato un aumento marcato nell’uso di EDR killer derivati da proof-of-concept pubblici, mentre il set di driver abusati rimane relativamente fisso. Cisco Talos ha analizzato sistematicamente le classi di vulnerabilità tipicamente sfruttate nei driver Windows, confermando che lo sfruttamento è migrato dal dominio degli attori avanzati a quello delle minacce commodity, in primis il ransomware. Questo significa che la barriera d’ingresso per sviluppare un EDR killer personalizzato è in caduta libera: chiunque abbia competenze di sviluppo Windows di livello intermedio può assemblarne uno partendo da codice disponibile su repository pubblici e proof-of-concept documentati.

Il paradosso dell’EDR e il debito del driver legacy

C’è un’ironia crudele nella situazione attuale. L’Endpoint Detection and Response è il prodotto di sicurezza su cui le organizzazioni investono di più, il pilastro su cui costruiscono la propria postura difensiva. I vendor EDR hanno sviluppato capacità sempre più sofisticate: rilevamento comportamentale, machine learning, analisi della memoria, threat hunting automatizzato.

Ma tutto questo sofisticato apparato tecnologico opera in user-mode. E un singolo driver vulnerabile caricato in kernel-mode ha il potere di spegnerlo completamente, bypassando ogni protezione, incluso Protected Process Light (PPL), il meccanismo che dovrebbe impedire la terminazione dei processi di sicurezza critici.

Il BYOVD come tecnica EDR killer sfrutta un debito architetturale che si è accumulato in decenni di sviluppo dell’ecosistema Windows. Ogni driver firmato legittimamente in vent’anni di storia informatica è un potenziale strumento nelle mani di un attaccante. E poiché questi driver erano progettati per scopi legittimi – forensics, gestione hardware, anti-rootkit, anti-cheat gaming – nessuno ha mai pensato di limitare le loro capacità kernel-mode in modo granulare.

Questo debito del driver legacy è strutturalmente analogo al debito tecnico nel software: una scelta ragionevole al momento della progettazione che diventa un rischio crescente con il passare del tempo. La differenza è che il debito tecnico nel software si paga con costi di manutenzione; il debito del driver legacy si paga con intrusioni ransomware riuscite.

Contromisure operative: cosa funziona davvero e cosa è un’illusione

Definito il problema nella sua dimensione reale, è necessario analizzare le contromisure con lo stesso rigore critico. Non tutte le difese proposte sono ugualmente efficaci, e alcune creano un falso senso di sicurezza.

HVCI (Hypervisor-Protected Code Integrity)

È la difesa più robusta attualmente disponibile. HVCI utilizza la virtualizzazione hardware per proteggere la memoria kernel, impedendo l’esecuzione di codice non firmato o non conforme alle policy. Quando HVCI è attivo, la Vulnerable Driver Blocklist di Microsoft viene effettivamente applicata. Huntress lo raccomanda esplicitamente come prima contromisura: abilitare HVCI / Memory Integrity garantisce che la blocklist dei driver vulnerabili sia effettivamente enforced.

Il problema: HVCI può causare incompatibilità con driver legacy e applicazioni che richiedono accesso diretto al kernel. Alcune organizzazioni lo disabilitano per ragioni operative, esponendosi esattamente all’attacco che dovrebbe prevenire.

WDAC (Windows Defender Application Control)

WDAC consente di definire policy granulari su quali driver e applicazioni possono essere eseguiti. Configurato correttamente in modalità allowlist, WDAC può bloccare proattivamente il caricamento di qualsiasi driver non esplicitamente autorizzato, inclusi quelli non ancora presenti nella blocklist di Microsoft.

È la contromisura più efficace in termini di copertura, ma anche la più complessa da implementare. Richiede un inventario accurato di tutti i driver legittimi necessari nell’ambiente, un processo di test rigoroso e una gestione continua delle eccezioni. In ambienti enterprise complessi, il deployment di WDAC in modalità enforced può richiedere mesi.

ASR Rules (Attack Surface Reduction)

La regola ASR “Block abuse of exploited vulnerable signed drivers” impedisce a un’applicazione di scrivere su disco un driver vulnerabile firmato. Tuttavia, come documentato da Microsoft, questa regola non blocca un driver già presente nel sistema – agisce solo sulla fase di installazione. Inoltre, le ASR rules dipendono da Microsoft Defender e possono essere disattivate da processi in user-mode, il che ne limita l’efficacia contro attaccanti che hanno già ottenuto privilegi elevati.

Monitoraggio comportamentale e telemetria

Se le difese preventive falliscono – e come abbiamo visto, in molti ambienti mancano i prerequisiti per attivarle – il rilevamento diventa l’ultima linea di difesa. I SOC dovrebbero monitorare attivamente: la creazione di servizi kernel con nomi che mimano componenti OEM o hardware; il caricamento di driver non standard, specialmente se firmati con certificati obsoleti; la terminazione anomala dei processi EDR; l’uso di sc.exe per la creazione di nuovi servizi kernel; l’attività IOCTL sospetta verso driver appena caricati.

Huntress ha evidenziato come la telemetria SIEM proveniente dal SonicWall sia stata determinante per ricostruire la timeline dell’intrusione. La lezione operativa è chiara: la visibilità a livello di rete e di autenticazione deve complementare, non sostituire, la protezione endpoint.

Il quadro strategico: dalla rincorsa delle blocklist alla riduzione strutturale del rischio

Il BYOVD come vettore EDR killer mette in discussione un assunto implicito della sicurezza endpoint degli ultimi dieci anni: che l’EDR sia sufficiente come difesa primaria.

Non lo è. Non perché l’EDR non funzioni – funziona eccellentemente nel proprio dominio. Ma perché opera a un livello di privilegio inferiore rispetto allo spazio in cui gli attaccanti possono agire quando sfruttano un driver kernel vulnerabile. È come avere una guardia armata all’ingresso che un intruso può addormentare prima di entrare.

La risposta strategica non è abbandonare l’EDR, ma costruire architetture dove la compromissione dell’EDR non equivalga alla compromissione dell’intero ambiente. Questo significa defense in depth reale, non come slogan ma come architettura: segmentazione di rete che limita il lateral movement indipendentemente dallo stato dell’endpoint; monitoraggio a livello di rete e di identità che non dipende dall’agente endpoint; policy di allowlisting dei driver che prevengono il caricamento di codice non autorizzato a livello kernel; autenticazione multifattore robusta su ogni punto di accesso remoto (l’incidente Huntress è iniziato con credenziali VPN senza MFA).

Il modello mentale deve evolvere dalla domanda “il nostro EDR rileverà l’attacco?” alla domanda “cosa succede se l’attaccante spegne il nostro EDR?”. Se la risposta alla seconda domanda è “non abbiamo visibilità e non possiamo contenere l’intrusione”, l’architettura difensiva ha un problema strutturale che nessun upgrade dell’EDR potrà risolvere.

Implicazioni per NIS2, DORA e la compliance

Il fenomeno EDR killer BYOVD ha implicazioni dirette per i framework normativi europei in fase di implementazione. NIS2 richiede alle organizzazioni essenziali e importanti di adottare misure di gestione del rischio proporzionate, inclusa la sicurezza della supply chain e la gestione delle vulnerabilità. Un ambiente in cui driver legacy vulnerabili possono essere sfruttati per disabilitare le difese endpoint rappresenta un rischio di supply chain tecnologica che deve essere esplicitamente indirizzato nel risk assessment.

Non si tratta di un rischio teorico: CISA ha aggiornato l’advisory congiunto su Akira nel novembre 2025 documentando specificamente l’uso di malware POORTRY per modificare configurazioni BYOVD su driver vulnerabili e disabilitare le protezioni endpoint, confermando che il fenomeno è monitorato dalle autorità di sicurezza a livello internazionale.

DORA, per le entità finanziarie, richiede test di resilienza operativa digitale che includano scenari di threat-led penetration testing. I TLPT dovrebbero necessariamente includere scenari BYOVD per validare la capacità dell’organizzazione di rilevare e contenere un’intrusione in cui l’EDR è stato neutralizzato.

La responsabilità ricade sull’organizzazione, non sul vendor EDR. Se un ransomware riesce a cifrare l’ambiente perché l’EDR è stato spento con un driver vulnerabile che avrebbe potuto essere bloccato da HVCI o WDAC, la domanda delle autorità di supervisione sarà: perché queste contromisure non erano abilitate?

Cosa aspettarsi: il BYOVD embedded come nuovo standard

Il caso Reynolds non è un’anomalia. È un segnale direzionale.

Come ha osservato il Symantec and Carbon Black Threat Hunter Team, l’integrazione di capacità aggiuntive direttamente nel payload ransomware potrebbe funzionare come unique selling point per gli sviluppatori che cercano di attrarre affiliati. In un mercato RaaS competitivo, offrire un payload che gestisce autonomamente l’evasione difensiva riduce la complessità per l’affiliato e rende gli attacchi più facili da eseguire.

È ragionevole prevedere che nel corso del 2026 vedremo altri gruppi ransomware adottare il modello del BYOVD embedded, e che la ricerca di driver vulnerabili ancora non presenti nella blocklist di Microsoft diventerà un’attività sistematica da parte dei threat actor. I numeri supportano questa proiezione: secondo i dati aggregati da Cyble e ReliaQuest, gli attacchi ransomware nel 2025 hanno raggiunto quota 4.737, in aumento rispetto ai 4.701 del 2024, con il riscatto medio balzato a 591.988 dollari nel Q4 2025 (+57% sul trimestre precedente, secondo Coveware).

In un ecosistema dove la competizione tra gang è feroce e le barriere d’ingresso continuano a scendere, offrire un payload con EDR killer BYOVD integrato diventa un vantaggio competitivo concreto nel reclutamento di affiliati. La corsa è già in atto: ogni driver firmato legittimamente in due decenni di storia Windows è un potenziale candidato.

Per i difensori, questo significa che la finestra per implementare contromisure strutturali – HVCI, WDAC, segmentazione, monitoraggio indipendente dall’endpoint – si sta chiudendo. Il BYOVD non è una minaccia futura: è il presente del ransomware. E il costo dell’inazione non è più un rischio teorico da inserire nel risk register. È un incidente in attesa di accadere.

Checklist operativa per SOC analyst e security architect

Per chi deve tradurre questa analisi in azioni concrete, ecco le priorità operative immediate:

• Verificare lo stato di HVCI/Memory Integrity su tutti gli endpoint Windows. Se disabilitato, pianificare l’attivazione con test di compatibilità. Senza HVCI, la Vulnerable Driver Blocklist di Microsoft potrebbe non essere enforced correttamente.
• Valutare il deployment di WDAC in modalità audit come primo passo, per identificare i driver caricati nell’ambiente e costruire una policy di allowlisting progressiva.
• Abilitare la regola ASR “Block abuse of exploited vulnerable signed drivers” su tutti gli endpoint con Microsoft Defender attivo.
• Implementare il monitoraggio SIEM per la creazione di servizi kernel anomali, il caricamento di driver non standard e la terminazione dei processi EDR. In particolare, monitorare chiamate DeviceIoControl verso device handle sconosciuti e la creazione di link simbolici (\??) verso driver appena installati.
• Condurre un inventario dei driver kernel attualmente caricati nell’ambiente tramite PowerShell (Get-WindowsDriver o driverquery /si) e confrontarlo con la Vulnerable Driver Blocklist di Microsoft per identificare driver a rischio già presenti.
• Verificare che l’MFA sia attiva su tutti i servizi di accesso remoto (VPN, RDP, SSH). L’incidente Huntress è iniziato con credenziali VPN senza MFA.
• Testare lo scenario “EDR down” negli esercizi di incident response e nei TLPT previsti da DORA: cosa succede se l’attaccante spegne l’EDR? Quali controlli compensativi entrano in funzione? Se la risposta è “nessuno”, l’architettura ha un problema strutturale.
• Aggiornare la Vulnerable Driver Blocklist manualmente se non si è su Windows 11 22H2 o successivo. Le versioni precedenti di Windows potrebbero avere una blocklist obsoleta.
• Implementare il monitoraggio dei driver con certificati obsoleti. Configurare regole di alerting per il caricamento di driver kernel firmati con certificati emessi prima del 2015, con particolare attenzione a quelli con timestamp di firma antecedenti al 2010.

https://www.ictsecuritymagazine.com/cyber-crime/edr-killer-byovd-endpoint/