ShieldBreak: exploit zero-day su Windows Defender, escalation a…

Nightmare Eclipse ha pubblicato ShieldBreak, un exploit zero-day che ottiene privilegi SYSTEM su Windows tramite Microsoft Defender. Indipendenti confermano la

Nightmare Eclipse ha pubblicato il 12 agosto 2026 ShieldBreak, proof-of-concept che ottiene privilegi SYSTEM su sistemi Windows aggiornati sfruttando Microsoft Defender. L'exploit è stato verificato indipendentemente da Kevin Beaumont e Will Dormann. Microsoft ha confermato di stare indagando, ma al momento non risulta alcuna patch disponibile.

La vicenda si inserisce in un pattern ricorrente: il ricercatore rilascia zero-day coincidenti con il Patch Tuesday di Microsoft. Questa strategia amplifica l'esposizione, perché i sistemi appena aggiornati si trovano vulnerabili fino al ciclo successivo. ShieldBreak colpisce un prodotto abilitato di default su ogni installazione Windows, rendendo la superficie di attacco virtualmente universale.

Punti chiave

L'exploit ShieldBreak pubblicato il 12 agosto 2026 ottiene privilegi SYSTEM su Windows 11 e Windows Server 2025 tramite Microsoft Defender
Kevin Beaumont ha verificato indipendentemente il funzionamento su "latest Windows 11"; Will Dormann ha analizzato la catena tecnica completa
L'attacco abusa l'API Cloud Filter (cfapi) durante la scansione di idratazione cloud di Defender, non una race condition del filesystem come il precedente RoguePlanet
Microsoft conferma di indagare sulla segnalazione; non risulta patch rilasciata, ma test di Tom's Hardware su build 26200.9168 suggeriscono possibile rilevamento in versioni recentissime

La catena d'attacco: da cfapi a conhost.exe con SYSTEM

Il meccanismo sfrutta un percorso di scansione poco documentato. L'attaccante registra una directory temporanea come provider Cloud Sync, posiziona un file EICAR per forzare l'intervento di Defender, poi usa il Common Log File System (CLFS) per scambiare dati di identità e idratazione. Questa manipolazione redireziona la scansione verso System32, dove viene piazzato phoneinfo.dll.

Il file phoneinfo.dll non esiste nativamente in Windows. Una volta piazzato, viene caricato da wer.dll durante l'esecuzione del task pianificato QueueReporting. Il risultato è l'avvio di conhost.exe con privilegi SYSTEM. Will Dormann di Tharros Labs ha tracciato questo percorso, confermando che l'exploit richiede Defender attivo per funzionare, a differenza di RoguePlanet.

La dipendenza da Defender attivo introduce un vincolo operativo rilevante: l'esecuzione richiede che il prodotto antivirus sia in stato attivo, non disabilitato o sostituito da soluzione terza. Questo rende l'attacco inapplicabile solo in ambienti con protezione endpoint alternativa, ma non mitiga la vulnerabilità per la stragrande maggioranza delle installazioni Windows globali.

RoguePlanet e ShieldBreak: meccanismi diversi, framing contestato

Nightmare Eclipse ha presentato ShieldBreak come bypass della patch di RoguePlanet, vulnerabilità corretta nel Microsoft Malware Protection Engine versione 1.1.26060.3008 e tracciata come CVE-2026-50656. Questa caratterizzazione è stata contestata da analisti indipendenti. RoguePlanet sfruttava una race condition del filesystem con dischi virtuali e manipolazione nativa NT; ShieldBreak opera tramite callback in user-mode sull'API cfapi durante la scansione cloud.

"RoguePlanet was a filesystem race condition vuln that uses virtual disks and NT native file manipulation to trick quarantine process into overwriting system files. ShieldBreak user-mode callback hook to change file contents during a Defender cloud-hydration scan via cfapi (Cloud Filter API)."
— Kevin Beaumont

La distinzione tecnica ha conseguenze sulla classificazione. Se ShieldBreak è una vulnerabilità distinta, richiede un CVE separato e un percorso di remediation autonomo. Se fosse invece un bypass della patch precedente, Microsoft dovrebbe riclassificare l'intervento su CVE-2026-50656. Allo stato attuale, Microsoft non ha assegnato identificatore CVE per ShieldBreak né ha confermato la natura esatta della relazione con RoguePlanet.

Kevin Beaumont, ex dipendente Microsoft, ha verificato direttamente l'exploit: "I've tried it, it works on latest Windows 11". Questa convergenza tra ricercatore indipendente e analista con background aziendale rafforza la credibilità della minaccia, indipendentemente dal framing scelto da Nightmare Eclipse.

Pattern di divulgazione e tensioni con Microsoft

Nightmare Eclipse ha pubblicato 10 zero-day da inizio aprile 2026, secondo quanto riportato da The Register. La concentrazione temporale e la scelta sistematica del Patch Tuesday come data di rilascio creano finestre di esposizione predicibili. I sistemi aggiornati il secondo martedì del mese restano vulnerabili fino al ciclo successivo, con intervalli tipici di 30 giorni.

La relazione tra ricercatore e vendor è deteriorata. A maggio 2026 Microsoft aveva minacciato azioni legali, poi ritirate dopo reazione della comunità security. Questo contesto alimenta comportamenti di divulgazione coordinata sempre più tesi, con potenziale effetto disincentivante sulla cooperazione futura. Il caso illustra una frattura strutturale nelle norme di responsible disclosure, con impatti che trascendono la singola vulnerabilità.

TechCrunch ha documentato il retroscena legale, confermando che la minaccia di maggio è stata successivamente attenuata. Non emergono nel dossier dettagli su eventuali contatti intercorsi tra Nightmare Eclipse e Microsoft prima della pubblicazione di ShieldBreak, né sulle modalità esatte di segnalazione.

Stato della protezione: rilevamenti esistenti, patch assente

Microsoft ha rilasciato una dichiarazione ufficiale il 12-13 agosto 2026: "Microsoft is aware of the reported vulnerability and is actively investigating the validity and potential applicability of these claims". Questa formulazione indica indagine in corso, non conferma tecnica né impegno di remediation con calendario definito.

Beaumont ha pubblicato tre query di detection/hunting per difensori. Questi indicatori permettono ricerca proattiva nella rete, ma non costituiscono mitigazione preventiva. L'assenza di patch ufficiale costringe gli ambienti enterprise in postura reattiva, dipendente dal monitoring e dalla threat hunting.

Tom's Hardware ha tentato verifica indipendente su build 26200.9168 di Windows 11, riscontrando blocco da parte di Defender. Il PoC pubblicato da Nightmare Eclipse mostra invece build 26100.33296. Questa discrepanza apre due ipotesi non mutualmente esclusive: Microsoft potrebbe aver introdotto rilevamento o modifica in build recentissime, oppure le condizioni di test di Tom's Hardware differiscono per configurazione o ambiente. Il test è condotto su singola VM e non è statisticamente conclusivo. Il dossier non specifica se altri tester abbiano replicato l'esito positivo o negativo su build 26200.9168.

Cosa fare adesso

Le azioni seguenti derivano direttamente dalle informazioni documentate nel dossier:

Implementare le tre query di hunting pubblicate da Kevin Beaumont per ricercare indicatori di compromissione correlati alla catena ShieldBreak
Verificare la versione build di Windows 11 in uso e confrontarla con le build 26100.33296 (PoC riuscito) e 26200.9168 (possibile rilevamento) per valutare lo stato di esposizione specifico
Mantenere Microsoft Defender attivo ma monitorare anomalie nei log relativi a cfapi, CLFS e caricamento DLL non standard in System32, in particolare phoneinfo.dll
Pianificare verifica di compatibilità del PoC sui propri sistemi Windows Server 2025, dato che il ricercatore dichiara vulnerabilità ma il dossier non documenta test indipendenti su questa piattaforma

L'architettura cloud di Defender come nuova superficie

La lettura tecnica più rilevante non riguarda la polemica sul "bypass di patch", ma l'emergere di un vettore d'attacco inedito. L'integrazione cloud di Defender, progettata per ottimizzare scansioni e idratazione file, espone API interne con permessi che consentono redirezione del filesystem. Questo è un difetto architetturale, non un bug di implementazione isolato.

Se il ciclo di vulnerability discovery di Microsoft, anche con supporto AI-driven, sta individuando difetti di race condition e buffer overflow ma non sta mappando le interazioni tra componenti cloud e kernel, la superficie di attacco resta sottostimata. ShieldBreak suggerisce che la sicurezza dei prodotti security richieda audit specifici dell'interfaccia tra servizi cloud e operazioni locali con privilegi elevati, un ambito che il dossier non documenta come coperto dai test attuali di Microsoft.

La vicenda solleva inoltre interrogativi sulla governance della divulgazione. Il pattern di rilasci di Nightmare Eclipse, sistematicamente calibrato sul Patch Tuesday, sfrutta una predicibilità istituzionale. Se le norme di responsible disclosure non trovano ricomposizione tra le parti, la tendenza a pubblicazione pubblica senza preavviso coordinato potrebbe consolidarsi, con effetti destabilizzanti sulla capacità difensiva collettiva.

Domande frequenti

ShieldBreak funziona solo su Windows 11?

Secondo il ricercatore, il PoC supporta Windows 11 25H2 (incluso canale Canary) e Windows Server 2025 con tasso di successo dichiarato del 100%. Windows 10 risulterebbe vulnerabile ma non è supportato dal codice pubblicato. Il dossier non documenta test indipendenti su Windows 10.

Microsoft ha già corretto la vulnerabilità?

Microsoft non ha rilasciato patch dichiarata per ShieldBreak. Un test di Tom's Hardware su build 26200.9168 ha mostrato rilevamento da parte di Defender, ma questo risultato non è confermato da altri tester né documentato come fix ufficiale.

È necessario disabilitare Defender per proteggersi?

No. Secondo Will Dormann, l'exploit richiede Defender attivo per funzionare. La disabilitazione rimuove il vettore ma espone a altre minacce. Il dossier non documenta alternative di mitigazione che preservino la protezione antivirus.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti