Un nuovo exploit pubblico, battezzato SignDrop, riporta sotto i riflettori il componente Windows Common Log File System (CLFS), già più volte coinvolto in falle di elevazione dei privilegi. Il codice pubblicato dal ricercatore Abdelhamid Naceri, noto online come Nightmare Eclipse o MSNightmare, descrive una catena che parte da un account locale privo di privilegi amministrativi e punta a ottenere l'esecuzione come SYSTEM, il livello di autorizzazione più alto del sistema operativo.

Il caso merita attenzione non perché renda possibile un accesso remoto a un PC Windows: per avviare la catena serve già la capacità di eseguire codice sul dispositivo con un account locale. Il rischio è nell'effetto successivo. Un malware entrato con diritti limitati, oppure un utente locale malevolo, potrebbe tentare di superare le protezioni di Windows e prendere il controllo completo della macchina. Al momento non risultano utilizzi dell'exploit in attacchi reali, ma il proof of concept è disponibile pubblicamente e Microsoft sta esaminando la segnalazione.

Il meccanismo dietro SignDrop

CLFS è il sottosistema di Windows dedicato alla gestione dei file di log, impiegato da varie componenti del sistema. La sua complessità e l'esecuzione di parte della logica nel kernel lo hanno reso nel tempo un bersaglio ricorrente: nel catalogo CISA delle vulnerabilità note per essere state sfruttate figurano dieci difetti collegati a CLFS, inclusi casi associati ad attività ransomware nel 2025.

Per limitare l'esposizione a file di log manipolati, Microsoft aveva introdotto nel 2025 un sistema di autenticazione dei log CLFS per Windows 11 e Windows Server 2025. Il meccanismo usa un codice di autenticazione basato sui dati del log e su una chiave specifica della macchina, così da consentire al driver di fidarsi dei file generati dal sistema stesso. Accanto al log viene gestito anche un file complementare con estensione .cnpf, destinato alle informazioni necessarie al recupero.

SignDrop non prova a spezzare quella autenticazione crittografica. Sfrutta invece la logica con cui il driver clfs.sys crea il file complementare quando un processo con privilegi elevati apre un log preparato in precedenza. Secondo l'analisi e il codice diffusi dal ricercatore, un utente standard può costruire un file di log e un container con riferimenti a percorsi controllati. In determinate condizioni, quando un processo privilegiato accede a quel log, CLFS crea il relativo .cnpf nel contesto di sicurezza del processo che lo ha aperto, anziché in quello dell'utente che ha predisposto i file.

La dimostrazione sfrutta collegamenti simbolici dell'Object Manager di Windows per reindirizzare l'operazione verso una posizione scelta dall'attaccante. Il processo privilegiato impiegato nel proof of concept è il motore antimalware di Microsoft Defender, attivato mediante la sua interfaccia RPC per l'aggiornamento delle firme. Il risultato descritto è la creazione di un file con autorizzazioni SYSTEM, ma scrivibile dall'utente locale. Da qui la catena tenta di collocare un payload e di avviare una shell SYSTEM.

Perché Defender è al centro della catena

L'uso di Defender è una componente cruciale della dimostrazione, non un'indicazione che l'antivirus sia vulnerabile in sé. SignDrop sfrutta il fatto che il servizio antimalware opera con privilegi molto elevati e può essere indotto ad aprire il file predisposto. È quindi CLFS a gestire in modo problematico la creazione del file associato, mentre Defender fornisce il contesto privilegiato che rende utile l'abuso.

Microsoft ha dichiarato a SecurityWeek di stare indagando sulla vulnerabilità riportata e di voler aggiornare i prodotti interessati quando necessario. L'azienda aggiunge che Microsoft Defender rileva e blocca lo sfruttamento della falla, generando un avviso sul comportamento di elevazione dei privilegi collegato alla tecnica. Sempre secondo Microsoft, non sono state osservate compromissioni in natura.

Questa posizione va letta insieme ai limiti emersi dalle verifiche indipendenti. Cyderes ha riferito di essere riuscita a compilare e testare il proof of concept. Un'ulteriore valutazione di 78researchlab ha concluso che l'exploit funziona, pur giudicandolo non abbastanza affidabile per un impiego operativo costante. Il test segnala inoltre un effetto molto visibile: la catena può modificare il comportamento delle richieste UAC, aprendo shell sia con privilegi standard sia SYSTEM e interferendo con altre operazioni sul computer. Non è quindi una tecnica silenziosa né, allo stato delle informazioni disponibili, una via semplice e universale per compromettere qualsiasi sistema.

Versioni interessate e stato della correzione

Il ricercatore afferma di avere testato SignDrop su Windows 11 26H2, una build sperimentale di Windows 11 26H2 e Windows Server 2025 Experimental. Sostiene inoltre che molte installazioni Windows consolidate potrebbero essere interessate. La ragione è legata alle modalità configurabili dell'autenticazione CLFS: le impostazioni di applicazione e apprendimento, rispettivamente indicate dai valori 0 e 1 nel Registro, rientrano nella superficie d'attacco rivendicata dal proof of concept. Sui sistemi più vecchi di circa 90 giorni, l'impostazione tende a passare automaticamente dalla fase di apprendimento a quella di applicazione.

Non è una buona risposta disattivare l'autenticazione CLFS. I valori 2 e 3 escluderebbero il sistema dalla specifica tecnica descritta da SignDrop, ma eliminano proprio una protezione introdotta per evitare che CLFS elabori log alterati. In altre parole, si ridurrebbe l'esposizione a questa catena precisa riaprendo però la porta a classi di vulnerabilità che il controllo di autenticazione era stato progettato per mitigare.

Alla pubblicazione del codice non risultavano un CVE assegnato, un bollettino Microsoft dedicato o una patch inclusa negli aggiornamenti di sicurezza di novembre. Questo spiega la definizione di zero-day: non tanto una conferma di sfruttamento attivo, quanto l'assenza di una correzione pubblica per una tecnica resa disponibile. Non compare neppure nel catalogo CISA Known Exploited Vulnerabilities.

Cosa possono fare amministratori e team di sicurezza

In attesa di indicazioni tecniche ufficiali più complete, la priorità è evitare contromisure improvvisate che indeboliscano CLFS. Organizzazioni e amministratori dovrebbero mantenere Windows e Microsoft Defender aggiornati, verificare che la protezione antimalware sia attiva e investigare tempestivamente gli avvisi relativi a comportamenti di elevazione dei privilegi. La catena pubblicata dipende dalla presenza e dall'attivazione di Defender, ma il ricercatore ipotizza che processi antimalware di terze parti con privilegi equivalenti possano offrire scenari analoghi: è un'affermazione che non risulta verificata indipendentemente.

Per i responsabili della sicurezza, SignDrop è anche un promemoria sulla necessità di contenere l'impatto dell'accesso locale iniziale. Controllo delle applicazioni, riduzione degli strumenti eseguibili dagli utenti, separazione degli account amministrativi e monitoraggio delle attività insolite restano difese rilevanti quando una vulnerabilità richiede già l'esecuzione locale. La sola presenza di un EDR o di un antivirus non elimina il problema, ma può aumentare le possibilità di intercettare una sequenza che, nel caso del proof of concept disponibile, lascia tracce evidenti.

Il prossimo passaggio dipenderà dall'esito dell'indagine Microsoft: potrà tradursi in un aggiornamento di sicurezza, in modifiche alle regole di rilevamento o in chiarimenti sul perimetro effettivo dei sistemi interessati. Fino ad allora, il dato più importante è distinguere tra la prova tecnica pubblicata e una campagna in corso: la prima è stata riprodotta da alcuni ricercatori, la seconda non è stata osservata. Ma la disponibilità del codice rende più urgente la gestione ordinata delle patch e degli alert sui dispositivi Windows.

Fonti