VEN0m Ransomware: il punto debole di Windows Defender

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.

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 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.

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:

1. Non chiama DeleteFileW(), non attraversa NtDeleteFile(), non genera gli eventi che un AV monitora.
2. Costruisce direttamente una struttura IRP e la invia al filesystem driver NTFS.
3. 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.

Questo è il tipo di superficie che soluzioni di threat-driven application control cercano di ridurre. MagicSword combina policy di execution control con threat intelligence su LOLDrivers, RMM abuse, LOLBAS e altri tool trusted frequentemente weaponizzati. Non è il prodotto identificato dal test Ransom-ISAC; è una tecnologia rilevante perché opera sulla stessa classe di controllo preventivo emersa dal caso VEN0m.

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:

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 e il controllo preventivo di BYOVD, RMM e tool Living off the Land

MagicSword non va presentato come “l’EDR che ha fermato VEN0m nel test Ransom-ISAC”. La fonte primaria non identifica il vendor. Va invece descritto come piattaforma di threat-driven application control che utilizza intelligence su LOLDrivers, LOLRMM, tool dual-use, firmatari e certificati per costruire policy di enforcement.

Il collegamento con VEN0m è architetturale: la chain dipende dal caricamento e dall’abuso di un driver vulnerabile; una policy che impedisce l’esecuzione o il caricamento del componente rischioso può interrompere il percorso prima delle fasi ransomware successive. L’efficacia sul singolo campione deve essere verificata con test controllati e policy effettivamente in Enforce.

Approfondisci: MagicSword - Threat-Driven Application Control.

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 .sys scritti 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?".

La lezione di VEN0m non è che un singolo prodotto risolva il ransomware, ma che alcune fasi decisive possono essere prevenute prima dell’esecuzione. Per ambienti che vogliono aggiungere execution control a EDR/XDR, Nexsys propone un percorso di Application Control basato su assessment, Audit mode, tuning ed enforcement progressivo, con MagicSword valutabile come tecnologia per gli scenari adatti.

Questo articolo è basato sull'analisi DFIR pubblicata da Ransom-ISAC il 26 febbraio 2026 in collaborazione con Barricade Cyber Solutions.

Preferisci compilare il modulo? Scrivi i tuoi dati qui sotto