Windows sotto attacco 0-click: la falla che aggira SmartScreen

Da anni i file LNK (i collegamenti di Windows) e i meccanismi di rendering della shell di Windows rappresentano una superficie d’attacco privilegiata, soprattutto in scenari di spear phishing (forma mirata di phishing in cui l’attaccante costruisce messaggi altamente personalizzati per una persona o un’organizzazione specifica, spesso usando informazioni reali per sembrare credibile) e accesso iniziale ai sistemi delle vittime.

Akamai ha messo in luce la grave vulnerabilità CVE-2026-32202, un difetto nella shell di Windows emerso dopo una patch incompleta distribuita da Microsoft. Il problema è correlato con una serie di correzioni rilasciate tra febbraio e aprile 2026, in risposta a campagne offensive attribuite al gruppo APT28.

Tra dicembre 2025 e gennaio 2026, diversi CERT (Computer Emergency Response Team) europei avevano registrato un incremento di attacchi mirati contro enti governativi e infrastrutture critiche. Il gruppo APT28, noto anche come Fancy Bear, ha sfruttato una combinazione di vulnerabilità per ottenere l’esecuzione di codice remoto e accesso a credenziali di rete. Microsoft ha reagito rapidamente con patch correttive; tuttavia, come vedremo, una lacuna nel processo di validazione ha lasciato aperta una porta meno evidente ma comunque sfruttabile.

La catena di exploit: MSHTML e bypass SmartScreen. Come funziona l’attacco

L’attacco iniziale si basa su due vulnerabilità concatenate: CVE-2026-21513, legata al motore MSHTML, e CVE-2026-21510, che consente di aggirare i controlli di sicurezza del sistema. In pratica, un file LNK appositamente costruito induce il sistema a interpretare contenuti remoti come componenti legittimi del Pannello di controllo.

Immaginiamo un attaccante crea un file Fattura_2026.lnk: a dispetto dell’estensione, non è un semplice collegamento. Al suo interno, infatti, inserisce una LinkTargetIDList costruita ad hoc.

Tale struttura contiene un CLSID del Pannello di controllo (oggetto COM legittimo), alcuni dettagli tecnici e un elemento finale che punta a un percorso UNC remoto, ad esempio
\\evil-server.xyz\share\update.cpl. Quando Windows analizza il file, non lo tratta come un link esterno ma come un oggetto del Pannello di controllo.

La risoluzione interna porta Esplora file a passare la richiesta alla shell, come se si trattasse di un file .cpl locale: entra in gioco la falla CVE-2026-21510 che bypassa i controlli di SmartScreen e in parallelo, con CVE-2026-21513 (MSHTML), l’attaccante può preparare contenuti che facilitano l’interpretazione o il rendering del payload, aumentando l’affidabilità dell’exploit.

Il risultato, purtroppo, è che Windows carica una DLL remota travestita da file .cpl, non c’è alcun blocco legato alla gestione di contenuti provenienti da Internet (MotW, Mark-of-the-Web) e non s’innesca alcun blocco da parte di SmartScreen.

La patch Microsoft e il nuovo modello di verifica

Microsoft ha corretto la falla CVE-2026-21510 introducendo un nuovo oggetto COM che estende il sistema di verifica ai file .cpl ampliando anche i controlli svolti da SmartScreen.

Il problema è che prima ancora che si attivi la verifica, Esplora file effettua delle operazioni preliminari per visualizzare gli oggetti. Tra queste c’è il recupero dell’icona associata al file. Qui avviene il comportamento critico: il sistema tenta di risolvere il percorso UNC per verificare l’esistenza del file. Nessuna interazione utente, nessun avviso.

Appena il percorso remoto viene interrogato, Windows avvia automaticamente una connessione SMB: è sufficiente aprire una cartella che contiene un file LNK malevolo perché si avvii automaticamente una negoziazione NTLM, meccanismo di autenticazione usato dal sistema operativo; in questo processo il computer invia al server controllato dall’attaccante l’hash Net-NTLMv2 dell’utente, ovvero una versione cifrata delle credenziali che può essere sfruttata per tentare accessi non autorizzati.

Un hash NTLM può essere riutilizzato direttamente in attacchi di tipo relay (in cui l’autenticazione è inoltrata a un altro servizio senza conoscere la password) oppure analizzato offline tramite tecniche di cracking per tentare di ricavare la password originale. In contesti aziendali complessi, questa condizione può accelerare significativamente i movimenti laterali, permettendo a un attaccante di estendere rapidamente l’accesso ad altri sistemi della rete.

Implicazioni operative e superficie d’attacco

Una caratteristica rende questo bug particolarmente insidioso: l’assenza totale di interazione. Non serve aprire il file, non serve cliccare nulla. Basta che il sistema indicizzi la cartella o ne mostri il contenuto.

In ambienti dove si utilizzano condivisioni di rete, repository documentali o sistemi di sincronizzazione, il rischio aumenta. I file LNK possono transitare facilmente tra utenti e sistemi, spesso senza controlli specifici.

Microsoft ha corretto il difetto con gli aggiornamenti di aprile 2026, chiudendo la finestra tra risoluzione del percorso e verifica di sicurezza.

Conviene comunque monitorare il traffico SMB in uscita verso host esterni; un comportamento anomalo può indicare tentativi di sottrazione degli hash. Limitare o disabilitare NTLM dove possibile riduce drasticamente l’impatto. Inoltre, l’adozione dell’autenticazione basata su Kerberos rappresenta una contromisura efficace, soprattutto all’interno di domini ben strutturati.

Un’altra misura utile consiste nel filtrare i file LNK provenienti da fonti non attendibili e bloccare la risoluzione automatica di percorsi UNC non interni. Alcune organizzazioni stanno introducendo regole specifiche nei sistemi EDR per intercettare accessi sospetti generati da explorer.exe.