Microsoft Defender, la patch non basta: ShieldBreak riapre la falla SYSTEM

• Patch management
• Vulnerabilità

Un tempo si sarebbe detto “puntuale come un orologio svizzero“. Subito dopo la pubblicazione degli aggiornamenti di sicurezza Microsoft relativi al Patch Tuesday di agosto 2026, il ricercatore di sicurezza noto con lo pseudonimo di Nightmare Eclipse si è fatto nuovamente sentire denunciando pubblicamente l’esistenza di una nuova vulnerabilità Windows non corretta dai tecnici di Redmond.

A tornare protagonista è Microsoft Defender: il proof-of-concept inedito pubblicato da Nightmare Eclipse e chiamato ShieldBreak aggira la correzione distribuita da Microsoft per la falla CVE-2026-50656, falla conosciuta come RoguePlanet e individuata nei mesi scorsi dallo stesso ricercatore.

Il problema originario era emerso il 10 giugno 2026 e permetteva a un processo locale con privilegi limitati di sfruttare il motore antimalware di Windows per ad acquisire i diritti SYSTEM sulla macchina. Microsoft aveva risposto il 9 luglio aggiornando il Malware Protection Engine alla versione 1.1.26060.3008. A distanza di poco più di un mese, però, Nightmare Eclipse rompe di nuovo le uova nel paniere della società di Redmond dimostrando di aver individuato una via per bypassare la misura di difesa applicata in precedenza.

Da RoguePlanet a ShieldBreak: perché Microsoft Defender è di nuovo sotto esame

Microsoft classifica CVE-2026-50656 come vulnerabilità di elevazione dei privilegi nel Microsoft Malware Protection Engine: il problema risiedeva nel fatto che un componente dotato di diritti elevati, come nel caso di Defender, può trovarsi a operare su un percorso o su un oggetto diverso da quello verificato poco prima.

RoguePlanet sfruttava proprio questa caratteristica: esisteva una finestra temporale nella quale l’attaccante poteva modificare ciò che Defender avrebbe successivamente elaborato (race condition), facendo sì che un’operazione eseguita dal motore con privilegi elevati finisse per produrre un risultato controllabile dall’utente con privilegi inferiori.

ShieldBreak, la vulnerabilità appena venuta a galla, è presentata dal ricercatore come un patch bypass di CVE-2026-50656. In altre parole, la correzione di luglio avrebbe impedito il percorso utilizzato dal proof-of-concept (PoC, pubblicato su GitHub nel repository MSNightmare) precedente senza eliminare tutte le condizioni necessarie per sfruttare la debolezza originaria.

Se l’analisi sarà confermata, significa che Microsoft ha chiuso una tecnica specifica lasciando aperta una variante capace di raggiungere un effetto equivalente. È un problema abbastanza comune quando una vulnerabilità nasce dall’interazione tra diversi meccanismi del sistema operativo e non da un semplice errore confinato in poche istruzioni.

Nightmare Eclipse sostiene di aver provato ShieldBreak sulle versioni più recenti di Windows 11 25H2, sul Canary Channel di Windows Insider e su Windows Server 2025, ottenendo un tasso di successo del 100% nei test effettuati. Windows 10 e le corrispondenti edizioni Server sarebbero vulnerabili a livello concettuale, anche se l’attuale PoC non li supporta direttamente.

Il salto più importante riguarda Windows Server 2025

Una delle differenze più interessanti rispetto a RoguePlanet riguarda proprio Windows Server. Il PoC originale incontrava infatti un ostacolo pratico: parte della tecnica faceva affidamento sul montaggio di un’immagine ISO, operazione che un normale utente senza privilegi non può effettuare nelle configurazioni Server prese in esame.

ShieldBreak, almeno secondo i risultati dei test condivisi dall’autore della scoperta, elimina tale limitazione e funziona anche su Windows Server 2025.

Un server può ospitare sessioni condivise, servizi aziendali, strumenti di amministrazione o carichi applicativi molto più sensibili rispetto a un normale endpoint. Un’elevazione da utente standard a SYSTEM su una macchina Server non implica automaticamente la compromissione del dominio Active Directory, naturalmente; può però fornire all’aggressore una posizione molto più favorevole per recuperare credenziali, modificare servizi, installare meccanismi di persistenza o muoversi verso altri sistemi.

Il ruolo di mpengine.dll e perché Defender rappresenta un bersaglio così interessante

Il perno dell’intera vicenda poggia sulla libreria mpengine.dll, ossia sul già citato Microsoft Malware Protection Engine usato da Defender per analizzare oggetti potenzialmente pericolosi. Il motore dell’antimalware di Windows deve aprire file, interpretare formati complessi, decomprimere archivi, analizzare contenuti e interagire con numerose strutture del file system.

Molte di queste attività avvengono con privilegi elevati proprio perché l’antivirus deve poter ispezionare aree del sistema che un normale programma non potrebbe raggiungere. Più insomma è potente il componente di sicurezza, maggiore può diventare l’impatto di un errore nella gestione dei dati controllabili da utenti con privilegi inferiori.

È la stessa ragione per cui i motori antivirus rappresentano da anni una superficie d’attacco particolarmente interessante per i ricercatori. Devono processare continuamente input non fidati, spesso prima ancora che un’applicazione li apra. Se un aggressore riesce a far interpretare un input in modo anomalo, il codice vulnerabile può trovarsi dalla parte più privilegiata della barriera e superare i limiti imposti.

Disattivare la protezione in tempo reale non risolve il problema

Già con RoguePlanet il ricercatore aveva osservato che spegnere la protezione in tempo reale non eliminava la possibilità di sfruttamento. È un’informazione utile anche per ShieldBreak: usare il toggle di Defender come misura temporanea non rappresenta una mitigazione sensata e, anzi, ridurrebbe ulteriormente la capacità del sistema di individuare malware.

La vulnerabilità interessa infatti il motore e le operazioni privilegiate che esso può compiere, non semplicemente la scansione real-time così come viene percepita dall’utente attraverso la finestra Sicurezza di Windows.

Allo stesso modo, sostituire Defender con un antivirus differente non può essere considerato automaticamente un rimedio. Negli ambienti aziendali alcuni componenti Microsoft possono restare installati o attivi in modalità differenti; inoltre il vero obiettivo difensivo dovrebbe essere impedire a codice non autorizzato di raggiungere lo stadio necessario per sfruttare una privilege escalation.

In assenza di una nuova correzione specifica per ShieldBreak, il margine di manovra consiste soprattutto nel limitare il primo requisito dell’attacco: l’esecuzione di codice da parte di un utente sprovvisto di particolari privilegi.

Il controllo delle applicazioni acquista quindi particolare importanza: soluzioni come AppLocker, Windows Defender Application Control e criteri equivalenti possono impedire l’avvio di eseguibili o librerie non approvati.