L'attacco che ha bypassato i sistemi aggiornati nel 2026
Il 23 febbraio 2026, i ricercatori di Ransom-ISAC hanno "detonato" in ambiente controllato un ransomware open source scritto in Rust chiamato VEN0m. Il risultato è stato netto: su un sistema Windows 11 Pro 24H2, aggiornato e con Windows Defender attivo, VEN0m ha completato le 9 fasi dell'attacco senza generare un singolo alert. File cifrati, persistenza stabilita, nota di riscatto visualizzata, tutto senza che Defender intervenisse. Ma la stessa cosa è accaduta con soluzioni EDR commerciali, quali BitDefender e Kaspersky.
Sul secondo endpoint, configurato con una soluzione di security specifica (Magicsword), dotata di protezione specifica contro i driver vulnerabili, la chain si è interrotta in 127 millisecondi. Zero file cifrati, zero persistenza, zero nota di riscatto.
Uno stesso payload. Due esiti opposti. E la differenza non sta nella capacità di rilevare il comportamento del ransomware in sé, ma in un controllo molto specifico: bloccare un driver vulnerabile prima che venga caricato nel kernel.
Questa è la lezione tecnica più importante che emerge dal report DFIR pubblicato da Ransom-ISAC, e merita un'analisi approfondita, poichè impatta direttamente sulle scelte architetturali di chi deve proteggere endpoint reali.
La tua infrastruttura è pronta a reggere un attacco kernel-level? Non aspettare un incidente per scoprirlo. Scopri come i nostri esperti possono blindare i tuoi endpoint: richiedi un Vulnerability Assessment con Nexsys.
Cos'è VEN0m: oltre il semplice malware
VEN0m è un ransomware open source pubblicato su GitHub, scritto in Rust, distribuito con licenza GPL-3.0. Un singolo binario da 15 MB che incorpora al suo interno il driver IObit (IMFForceDelete.sys), la GUI della nota di riscatto e l'immagine del wallpaper.
Classificarlo come "proof of concept" accademico sarebbe un errore strategico. Il motivo è semplice: l'interesse non è nel campione, ma nelle tecniche che implementa. VEN0m combina in un unico binario automatizzato alcune delle tecniche di attacco più efficaci documentate negli ultimi anni:
- UAC Bypass via manipolazione del registro (slui.exe DelegateExecute hijack) per ottenere privilegi elevati senza interazione utente.
- BYOVD (Bring Your Own Vulnerable Driver) tramite CVE-2025-26125 sul driver IObit ForceDelete.sys.
- Cancellazione kernel-mode delle difese (Kaspersky, Bitdefender, Windows Defender) tramite IOCTL diretto al driver.
- Persistenza Winlogon via modifica della chiave Userinit nel registro.
- Cifratura AES-256-GCM con nonce random per file.
- Scheduled task mascherato da aggiornamento Microsoft per riproporre la nota ogni 2 minuti.
Ognuna di queste tecniche è documentata da anni. La novità è l'integrazione in un singolo binary Rust compilato, pronto per essere ricompilato con varianti del tipo: chiave diversa, driver diverso, nome diverso da chiunque abbia competenze di sviluppo medio-basse.
VEN0m combina in un unico binario automatizzato alcune delle tecniche di attacco più efficaci documentate negli ultimi anni:
- UAC Bypass via manipolazione del registro (
slui.exe DelegateExecutehijack) per ottenere privilegi elevati senza interazione utente - BYOVD (Bring Your Own Vulnerable Driver) tramite CVE-2025-26125 sul driver IObit
ForceDelete.sys - Cancellazione kernel-mode delle difese (Kaspersky, Bitdefender, Windows Defender) tramite IOCTL diretto al driver
- Persistenza Winlogon via modifica della chiave
Userinitnel registro - Cifratura AES-256-GCM con nonce random per file
- Scheduled task mascherato da aggiornamento Microsoft per riproporre la nota ogni 2 minuti
Ognuna di queste tecniche è documentata da anni. La novità è l'integrazione in un singolo binary Rust compilato, pronto per essere ricompilato con varianti del tipo: chiave diversa, driver diverso, nome diverso da chiunque abbia competenze di sviluppo medio-basse.
BYOVD: bypassare le difese User Mode
Il nucleo dell'attacco è il BYOVD. Vale la pena spiegarlo chiaramente, perché è la tecnica che rende VEN0m capace di eludere un antivirus tradizionale senza nessuna evasione sofisticata.
Il paradosso dei driver firmati
Windows richiede che i driver kernel siano firmati digitalmente. Questo crea un'illusione di sicurezza: se è firmato, è affidabile. Il problema è che la firma attesta l'identità del publisher al momento del rilascio, non la sicurezza del codice nel tempo. Se in quel driver esiste una vulnerabilità e nel caso di ForceDelete.sys di IObit si tratta di un'assenza totale di verifica sul processo chiamante, chiunque può aprire un handle al device del driver e inviare comandi IOCTL privilegiati.
Nel caso di CVE-2025-26125, il device \\.\IMFForceDelete123 risponde all'IOCTL 0x8016E000 con il percorso di un file e lo cancella a livello kernel, senza verificare se il processo chiamante è autorizzato. Un binario Rust scritto da un threat actor, un PowerShell script, qualsiasi processo con accesso alla system call: tutti possono invocare quella capacità con uguale efficacia.
Perché le difese user-mode non bastano
La maggior parte delle difese endpoint (antivirus, EDR tradizionali, hook sulle API Windows) opera in user mode o al più a livello di syscall dispatcher. Quando un driver kernel esegue operazioni, bypassa ogni punto di ispezione user-mode:
- Non chiama DeleteFileW(), non attraversa NtDeleteFile(), non genera gli eventi che un AV monitora.
- Costruisce direttamente una struttura IRP e la invia al filesystem driver NTFS.
- Stripping degli attributi file (read-only, system) avviene in ring-0, invisibile a ogni hook user-space.
Il risultato concreto: VEN0m ha cancellato i file di Windows Defender dalla directory C:\Program Files\Windows Defender\ senza che Defender potesse intercedere. Un processo che si auto-sradica, in modo efficace, lavorando un livello sotto di lui.
La chain di 9 fasi analizzata da Ransom-ISAC
Il report documenta con precisione ogni fase dell'attacco, inclusi source code level analysis, artifact forensici e query di detection. Ecco la sequenza che ha completato senza ostacoli su Windows Defender:
| # | Fase | Tecnica MITRE | Risultato su Defender |
|---|---|---|---|
| 1 | UAC Bypass | T1548.002 | Successo — IntegrityLevel: High |
| 2 | BYOVD Driver Drop | T1211, T1569.002 | Driver caricato nel kernel |
| 3 | AV/EDR Shredding | T1562.001 | Windows Defender distrutto da disco |
| 4 | Winlogon Persistence | T1547.004 | Registro modificato |
| 5 | File Enumeration | T1083 | Drive C:\ enumerato via cmd /c dir /s /b |
| 6 | AES-256-GCM Encryption | T1486 | File utente cifrati (.vnm) |
| 7 | Scheduled Task | T1053.005 | Task ogni 2 min mascherato da MicrosoftUpdate11.01 |
| 8 | Ransom Note GUI | T1491.001 | Fullscreen con input bloccato via BlockInput() |
| 9 | Wallpaper Change | T1491.001 | Completato |
Nello scenario con Magicsowrd, la catena si è fermata alla fase 2, 127ms dopo la scrittura del driver su disco. Nessuna delle fasi successive ha avuto luogo.
Vuoi imparare a mitigare queste minacce? Diventa un esperto di sicurezza e impara a configurare difese avanzate.
MagicSword: prevenzione basata sull'Intelligence
MagicSword è una piattaforma di Application Control e Driver Blocklist alimentata da intelligence live sui LOLDrivers (Living Off The Land Drivers) un progetto open source che cataloga driver vulnerabili e malevoli per Windows, fra i cui contributor ci sono gli stessi sviluppatori di MagicSword.
Il funzionamento rispetto a VEN0m si articola su due livelli distinti.
Livello 1 — Application Control (Enforce Mode)
In un modello di allowlisting realmente enforced, un binario come VEN0m.exe sarebbe il candidato naturale a essere bloccato. In un modello abuse-blocking, il focus si sposta invece sui componenti e sulle tecniche realmente abusate, inclusi i driver vulnerabili.
Ma questo vale anche per ogni variante ricompilata: hash diverso, stesso blocco. È il modello allowlist applicato correttamente, quello che l'analisi Ransom-ISAC segnala come il vero discriminante tra "rilevare" e "prevenire".
Livello 2 — Driver Blocklist via LOLDrivers
Anche ipotizzando che l'attaccante riesca in qualche modo a eseguire il payload (magari con tecniche di initial access più sofisticate), il secondo layer colpisce esattamente la fase più critica: il caricamento del driver.
Il driver IMFForceDelete.sys (CVE-2025-26125) è un candidato diretto per essere incluso in LOLDrivers. MagicSword dichiara un aggiornamento della blocklist ogni 2 ore dalle fonti di intelligence attive ed inoltre è in grado di implementare regole a livello publisher/hash/certificate e blocco del driver a livello kernel prima dell’esecuzione; è il tipo di enforcement che agisce esattamente sul vettore critico emerso nel caso VEN0m
Il confronto pratico
| Scenario | Windows Defender | MagicSword (Enforce) |
|---|---|---|
| VEN0m.exe execution | Non bloccato | Bloccato per policy |
| Driver drop + load | Non bloccato | Bloccato per WDAC |
| File encryption | Non bloccato | Non raggiunto |
| Persistenza Winlogon | Non bloccata | Non raggiunta |
Nota importante: la tabella sopra descrive il comportamento atteso in base a quanto dichiarato e documentato da MagicSword e Ransom-ISAC. Una validazione formale sul campione VEN0m specifico richiederebbe un test controllato in un ambiente con policy MagicSword attive in Enforce mode. Il punto metodologico è che MagicSword opera sul vettore esatto (driver vulnerabili + application control) che l'analisi identifica come il punto di rottura della chain.
Il vero gap che VEN0m espone
La riflessione più importante che emerge dal report non è tecnica: è architetturale.
Molte organizzazioni italiane hanno investito in EDR, SIEM, MFA, awareness training. Coprono bene lo user mode. Ma nel percorso kernel, i driver vulnerabili che qualunque processo può caricare, i BYOVD firmati che Windows accetta senza contestare, rimane spesso scoperto o sottovalutato.
La percezione comune è: "abbiamo l'antivirus, abbiamo l'EDR, siamo protetti." VEN0m dimostra che questo ragionamento ha un buco strutturale. Non perché gli EDR siano inutili, ma perché non tutti gli EDR implementano la vulnerable driver protection.
Il risultato è una sicurezza formalmente presente, aggiornata, certificata, e tuttavia incapace di fermare una chain che un attore con skills medie può costruire in pochi giorni a partire da codice open source.
Checklist: come proteggere il tuo perimetro IT
Indipendentemente dal prodotto, ecco i controlli che ogni organizzazione dovrebbe verificare alla luce di quanto emerge dall'analisi VEN0m:
1. Driver Blocklist attiva e aggiornata Verificare se la policy WDAC o la soluzione EDR include una blocklist sui driver vulnerabili, con frequenza di aggiornamento documentata. Una lista statica aggiornata una volta all'anno è insufficiente.
2. Application Control in Enforce mode, non Audit L'Audit mode registra ma non blocca. La maggior parte dei deployment rimane in Audit indefinitamente per paura di disruptione. La fase di audit serve per capire l'ambiente, non come postura permanente.
3. ASR Rule: "Block abuse of exploited vulnerable signed drivers" Su ambienti con Microsoft Defender for Endpoint (MDE/Intune), la regola GUID 56a863a9-875e-4185-98a7-b882c64b5ce5 blocca specificamente questo vettore. Verificarne lo stato: è in Block, Audit o non configurata?
4. HVCI (Hypervisor-Protected Code Integrity) Dove il workload lo consente, HVCI isola il kernel da driver non verificati. È la difesa più strutturale contro BYOVD, ma richiede hardware compatibile e può impattare driver legacy.
5. Monitoring su indicatori ad alto segnale Tra i 42 behavioral detection query del report, quelli con il rapporto segnale/rumore migliore:
- Driver
.sysscritti in%TEMP%,%APPDATA%, Desktop - Kernel service (ServiceType=1) creati con ImagePath fuori da
System32\drivers - Modifiche alla chiave
Winlogon\Userinit FileWrittenWithEntropyHigh> 20 eventi da stesso processo in finestra breve
Hai bisogno di supporto per configurare le tue ASR Rules o WDAC? I consulenti Nexsys sono a tua disposizione per ottimizzare le tue difese Microsoft. Contattaci per una consulenza tecnica
Il ruolo di Nexsys: dalla consapevolezza alla prevenzione concreta
Per Nexsys questo tipo di analisi non è solo threat intelligence teorica. È il punto di partenza per conversazioni concrete con i clienti su tre domande operative:
- Il vostro ambiente è esposto a tecniche BYOVD? Dipende dalla presenza di driver legacy e dalla configurazione WDAC.
- Le policy di application control coprono davvero i driver vulnerabili? Gestire separatamente WDAC e blocklist è fondamentale.
- I controlli esistenti prevengono o solo segnalano? La prevenzione (block) è l'unica vera difesa contro attacchi a 127ms.
Il nostro approccio al cybersecurity assessment incorpora esplicitamente la verifica del kernel path: WDAC policies, driver blocklist, HVCI configuration, ASR rules attive su MDE. Non perché siano checklist formali, ma perché VEN0m ha dimostrato che è esattamente lì che oggi si decide tra un incidente e un non-incidente.
Conclusioni: bloccare, non solo rilevare
Il report Ransom-ISAC su VEN0m è un documento che ogni security architect italiano dovrebbe leggere per separare "sicurezza percepita" da "sicurezza effettiva". Windows Defender aggiornato non è bastato; un controllo specifico sul driver vulnerabile sì.
Strumenti come MagicSword, le iniziative open source come LOLDrivers, le WDAC policies alimentate da intelligence live esistono esattamente per coprire quel gap. Nel panorama del ransomware moderno, la domanda non è più "abbiamo un antivirus?". È: "Blocchiamo ciò che l'attaccante vuole caricare nel kernel prima che ci riesca?"
Questo articolo è basato sull'analisi DFIR pubblicata da Ransom-ISAC il 26 febbraio 2026 in collaborazione con Barricade Cyber Solutions.
Vuoi mettere alla prova la sicurezza dei tuoi sistemi contro minacce come VEN0m? Siamo qui per aiutarti a implementare una strategia di difesa a più livelli.
Richiedi un'analisi dei rischicon gli esperti Nexsys