SignDrop, lo zero-day che weaponizza la mitigazione CLFS contro Windows Defender

Il ricercatore Abdelhamid Naceri ha pubblicato SignDrop, uno zero-day che sfrutta la mitigazione CLFS di Microsoft per scalare i privilegi da utente standard a SYSTEM. Nessuna patch è disponibile.

Il ricercatore Abdelhamid Naceri, noto come Nightmare Eclipse e MSNightmare, ha pubblicato su GitHub il 10 novembre 2026 SignDrop, un exploit funzionante per un nuovo zero-day Windows. L'attacco non sfrutta una vulnerabilità di memoria né un bug nel kernel: abusa della stessa mitigazione che Microsoft aveva introdotto nell'ottobre 2025 per bloccare proprio questa classe di exploit CLFS. Il risultato è una scalata di privilegi da utente standard a SYSTEM che costringe Windows Defender a creare file controllati dall'attaccante.

Limiti delle fonti. Questo articolo si basa su dichiarazioni del ricercatore Naceri riportate da SecurityWeek, The Hacker News, BleepingComputer e CyberSecurityNews. Test indipendenti del proof-of-concept sono stati condotti solo da Cyderes e da Heewon Song di 78researchlab. Microsoft non ha confermato la vulnerabilità né assegnato un CVE. Le affermazioni sul funzionamento dell'exploit sono verificate solo su Windows Defender, non su altri motori antimalware.

Punti chiave

SignDrop sfrutta la creazione del file .cnpf di autenticazione CLFS, forzando un processo con privilegi SYSTEM a generare un file controllabile dall'attaccante
L'exploit costringe Windows Defender attraverso la sua interfaccia RPC di aggiornamento firme a creare il file .cnpf in una posizione scelta dall'attaccante
Nessun CVE è stato assegnato e nessuna patch esiste al novembre 2026, secondo SecurityWeek, The Hacker News e CyberSecurityNews
Secondo stima non verificata del ricercatore Naceri, circa l'80% delle installazioni Windows con più di 90 giorni di attività è vulnerabile

Come la mitigazione CLFS diventa superficie di attacco

Microsoft ha introdotto la mitigazione di autenticazione CLFS nell'ottobre 2025, con aggiornamenti rilasciati a partire dal 28 ottobre 2025 per Windows 11 25H2, 26H1 e Windows Server 2025, come documenta la pagina di supporto ufficiale. Il meccanismo prevede che, quando un processo apre un file di log CLFS, il driver clfs.sys crei un file companion con estensione .cnpf contenente un hash crittografico che autentica il contenitore del log. Se il file .cnpf manca, viene rigenerato nel contesto di sicurezza del processo che ha aperto il log.

SignDrop manipola questo flusso. L'attaccante prepara un file di log CLFS con un percorso del contenitore sotto il proprio controllo, quindi utilizza link simbolici del gestore oggetti Windows per redirigere la creazione del .cnpf verso una posizione scrivibile dall'utente standard. Quando un processo privilegiato apre il log, clfs.sys crea il file .cnpf con privilegi SYSTEM ma eredita le autorizzazioni del file di log originale, consentendo all'attaccante di scriverci sopra e riaprirlo per ottenere esecuzione con privilegi massimi.

La scelta del processo privilegiato distingue SignDrop da altre tecniche. Secondo SecurityWeek e The Hacker News, Naceri ha individuato una via per costringere il servizio antimalware di Windows Defender attraverso la sua interfaccia RPC di aggiornamento firme. Il processo SYSTEM che crea il file è l'antivirus stesso: una componente che i sistemi EDR considerano attendibile.

Perché Windows Defender diventa il veicolo dell'attacco

Naceri ha sottolineato in una dichiarazione riportata da BleepingComputer che la logica di Microsoft è tecnicamente corretta: "Everything is done properly by Microsoft here but the logic allows abuse". Il problema non è un errore di implementazione ma una conseguenza non prevista di un meccanismo progettato per essere robusto.

Il ricercatore ha affermato che la tecnica potrebbe funzionare contro qualsiasi motore antimalware, poiché la creazione del file avviene nel contesto del processo legittimo dell'antivirus. Questa affermazione è riportata da BleepingComputer come dichiarazione diretta del ricercatore, non come risultato di test indipendenti. The Hacker News e SecurityWeek non riportano verifiche su altri prodotti antivirus o EDR. La generalizzabilità della tecnica rimane non verificata.

La Cyderes ha compilato e testato con successo il proof-of-concept. Heewon Song di 78researchlab ha confermato il funzionamento, ma ha rilevato limitazioni operative: l'esecuzione modifica ogni prompt UAC aprendo contemporaneamente una shell utente standard e una shell SYSTEM, bloccando altre azioni. Questo comportamento rende l'exploit inaffidabile per uso operativo continuativo.

"You're generally vulnerable if your Windows installation is older than 90 days" — Abdelhamid Naceri, via SecurityWeek. Secondo stima non verificata del ricercatore, circa l'80% delle installazioni Windows con più di 90 giorni sarebbe vulnerabile.

Le fasi della mitigazione CLFS e la finestra di rischio

La vulnerabilità di SignDrop è legata alla cronologia di attivazione della mitigazione CLFS. Secondo la documentazione Microsoft, il sistema opera inizialmente in modalità learning per circa 90 giorni, generando i file .cnpf senza imporne la validazione. Passato questo periodo, il sistema transisce automaticamente in modalità enforcement, dove l'assenza o la manomissione del .cnpf causa il rifiuto dell'operazione.

È nella fase enforcement che SignDrop diventa esplorabile: il driver è costretto a ricreare il file di autenticazione, generando la finestra di attacco. I valori di registro HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication\Mode indicano lo stato: 0 per enforcement, 1 per learning, entrambi vulnerabili a SignDrop; 2 o 3 indicano mitigazione disabilitata, che elimina il rischio di questo exploit specifico ma espone a vulnerabilità CLFS di corruzione di memoria precedentemente documentate.

Secondo l'analisi di Naceri riportata da SecurityWeek, BleepingComputer e The Hacker News, circa l'80% delle installazioni Windows con più di 90 giorni sarebbe in stato enforcement e quindi vulnerabile. Questa stima non è stata misurata indipendentemente.

Cosa fare adesso

Gli amministratori possono verificare lo stato della mitigazione CLFS controllando il valore di registro HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication\Mode. Valori 0 o 1 indicano configurazione vulnerabile a SignDrop; valori 2 o 3 indicano mitigazione disabilitata, non vulnerabile a SignDrop ma esposto a precedenti vulnerabilità di corruzione della memoria CLFS.

Non esiste patch disponibile al novembre 2026. Microsoft non ha confermato la vulnerabilità né assegnato un CVE. Le organizzazioni devono monitorare gli aggiornamenti di sicurezza e valutare le contromisure in base al proprio profilo di rischio, considerando che l'exploit richiede accesso locale e presenta limitazioni operative documentate.

Il contesto di minaccia include il pattern di disclosure del ricercatore: Naceri ha rilasciato multiple zero-day Windows e Defender dall'aprile 2026, alcune poi patchate da Microsoft come ShieldBreak (CVE-2026-69414), RoguePlanet (CVE-2026-50656), YellowKey, GreenPlasma e MiniPlasma. Microsoft ha precedentemente avvertito di possibili azioni legali contro "attività dannose che causano danni reali" dopo disclosure pubbliche senza segnalazione privata.

Chiusura editoriale

SignDrop rappresenta una evoluzione significativa nella catena di exploit CLFS: non una vulnerabilità di memoria da correggere con patch, ma una conseguenza strutturale di una mitigazione progettata per essere protettiva. La tecnica di coercizione di Windows Defender attraverso la sua interfaccia RPC di aggiornamento firme dimostra come processi considerati attendibili possano diventare vettori di attacco quando la logica di sistema li espone a manipolazioni controllate.

L'assenza di CVE e patch al novembre 2026, combinata con l'elevata percentuale stimata di sistemi vulnerabili, posiziona SignDrop come rischio prioritario per le organizzazioni Windows. La comunità di sicurezza attende una risposta Microsoft che chiarisca se la correzione richiederà una modifica del driver clfs.sys, una revisione dell'interfaccia RPC di Defender, o entrambe.

Fonti

Fonti e riferimenti

Ricevi DeafLetter