Un file Office, un hash NTLM, un accesso al tuo account

Il Patch Tuesday di novembre 2026 porta con sé un numero già di per sé notevole — 1.094 vulnerabilità corrette, 63 classificate come critiche — ma la voce che merita l’attenzione immediata di ogni amministratore Windows non è quella con il punteggio CVSS più alto. È la CVE-2026-124194, una falla in Outlook con CVSS 6.5 che Microsoft ha confermato attivamente sfruttata in rete, e che CISA ha inserito nel Known Exploited Vulnerabilities Catalog il 10 novembre 2026, con scadenza di rimedio fissata al 24 novembre.

Un CVSS “moderato” che finisce comunque nella lista delle priorità assolute è di per sé un segnale interessante: vuol dire che la facilità di innesco e l’impatto reale pesano più del punteggio tecnico puro. Vale la pena capire perché.

Il meccanismo: furto dell’hash NTLMv2 senza warning

La catena d’attacco è quasi banale da descrivere, il che è parte del problema:

1. La vittima riceve un file Office malevolo e lo apre (è richiesta interazione dell’utente: niente zero-click).
2. Il file è costruito in modo che, all’apertura, Outlook/Office tenti una connessione verso una risorsa di rete controllata dall’attaccante.
3. Normalmente questo tipo di connessione verso contenuto esterno genera un avviso di sicurezza. In questo caso, il bug permette di bypassare quell’avviso.
4. Il client tenta l’autenticazione NTLM verso l’host remoto, e nel farlo espone l’hash NTLMv2 dell’utente.

Da quel momento l’attaccante ha due strade classiche, ben note a chi si occupa di Active Directory: il relay dell’hash verso un altro servizio della rete per autenticarsi come la vittima senza mai conoscerne la password, oppure il tentativo di cracking offline dell’hash per recuperare la password in chiaro, se questa è debole.

Non è una tecnica nuova nei suoi fondamentali — il furto di hash NTLM tramite risorse SMB/WebDAV remote è un classico vettore da anni — quello che cambia qui è che la falla elimina proprio la barriera (l’avviso di contenuto esterno) che era pensata per bloccare esattamente questo scenario.

Chi è colpito e con quali build

Sono interessati:

• Microsoft 365 Apps for Enterprise, con la correzione distribuita nelle build rilasciate il 10 novembre 2026 (Current Channel 2610/20527.20196; Monthly Enterprise Channel 2610/20527.20194, 2609/20430.20264, 2608/20326.20320; Semi-Annual Enterprise Channel 2610/20527.20192, 2609/20430.20262, 2608/20326.20318)
• Office LTSC 2021, corretto a partire dalla build 16.0.14334.21048 (Versione 2108)
• Office LTSC 2024, corretto a partire dalla build 16.0.17932.21140 (Versione 2408)

Per le linee Office 2019 e Retail 2021/2024 la documentazione pubblica non chiarisce in modo definitivo lo stato, quindi se la tua organizzazione le usa ancora conviene verificare direttamente le pagine di release di Microsoft (aka.ms/OfficeSecurityReleases) prima di considerarle al sicuro.

Cosa fare subito

Microsoft non offre workaround ufficiali per questa CVE: la correzione passa dall’aggiornamento. Alcuni punti pratici per chi gestisce un parco client Office:

# Verifica rapida della build installata (PowerShell, da eseguire sul client)
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration" |
    Select-Object VersionToReport, UpdateChannel

Confronta il valore di VersionToReport con le build elencate sopra per il canale di aggiornamento in uso (il canale è indicato in UpdateChannel).

Un dettaglio interessante per chi lavora con il Preview Pane di Outlook come prima linea di difesa: secondo la documentazione Microsoft, il Preview Pane non è indicato come vettore d’attacco per questa vulnerabilità, quindi disabilitarlo non è presentato come mitigazione efficace in questo caso specifico — a differenza di molte CVE Outlook del passato dove invece lo era.

Oltre alla patch, questo è un buon momento per rivedere la postura generale verso NTLM nella propria rete. La policy di Group Policy Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers permette di impostare un audit (o un blocco) sul traffico NTLM uscente verso server remoti. L’approccio consigliato, come sempre con questo tipo di hardening, è incrementale:

• Imposta la policy su Audit all e lascia girare per un periodo rappresentativo (almeno 2-4 settimane)
• Analizza i log degli eventi (Event ID 8001-8004 nel canale Microsoft-Windows-NTLM/Operational) per capire quali servizi legittimi dipendono ancora da NTLM in uscita
• Costruisci una lista di eccezioni per quei servizi
• Solo a quel punto valuta il passaggio a Deny all

Va detto con chiarezza: nessun documento Microsoft collega esplicitamente questa policy come mitigazione ufficiale per CVE-2026-124194. È però una misura di difesa in profondità che riduce l’impatto di qualunque scenario di furto/relay di hash NTLM, questo incluso, e che molte organizzazioni dovrebbero già avere in roadmap vista la progressiva deprecazione di NTLM annunciata da Microsoft negli ultimi anni.

Il contesto: un Patch Tuesday particolarmente carico

Vale la pena segnalare, nello stesso rilascio di novembre, almeno tre altre correzioni critiche che meritano priorità alta nei piani di patching:

• CVE-2026-119958 — RCE non autenticata nel servizio Windows LDAP, CVSS 9.8: un rischio diretto per domain controller e Active Directory.
• CVE-2026-118207 — RCE in Exchange Server, CVSS 9.8, attivabile semplicemente inviando una email all’organizzazione colpita.
• CVE-2026-112967 — RCE nel servizio Xbox Live Networking di Windows, CVSS 9.8, sfruttabile da un attaccante sulla stessa rete.

Nessuna di queste tre risulta, al momento della scrittura, attivamente sfruttata come la CVE-2026-124194 — ma con un CVSS 9.8 e vettori di rete raggiungibili, la finestra per sfruttarle potrebbe chiudersi rapidamente una volta pubblicati i dettagli tecnici completi.

Conclusione

CVE-2026-124194 è un buon esempio di come il punteggio CVSS da solo non basti a definire la priorità di una patch: qui il fattore decisivo è lo sfruttamento attivo confermato e la semplicità dell’innesco (un documento allegato, nessun click aggiuntivo oltre all’apertura). Per i reparti IT, le azioni concrete sono tre: aggiornare Microsoft 365 Apps e Office LTSC alle build corrette entro la scadenza CISA del 24 novembre, verificare lo stato delle linee Office più vecchie non chiaramente documentate, e cogliere l’occasione per avviare (o proseguire) l’audit del traffico NTLM in uscita nella propria rete.

Fonte: CSOonline, Braindetox.kr