CVE-2026-62878: RCE wormable e pre-auth nel DNS Server di Windows

L'11 agosto, in un Patch Tuesday che ha chiuso 398 CVE, una riga dell'advisory avrebbe dovuto gelare ogni amministratore Windows: una vulnerabilità di esecuzione di codice remoto (RCE) wormable e non autenticata nel DNS Server di Windows. CVE-2026-62878 ha un CVSS di 9.8, non richiede credenziali né interazione dell'utente, ha bassa complessità di attacco — e risiede in un servizio che, nella maggior parte degli ambienti Windows, gira sui domain controller. La valutazione di sfruttabilità di Microsoft riporta "Exploitation Less Likely". Quella frase non è il cessato allarme. È un conto alla rovescia.

Che cos'è davvero CVE-2026-62878

La rassegna di agosto della Zero Day Initiative lo dice senza giri di parole: "un vecchio classico buffer overflow su stack che finisce per essere wormable". Classificato come CWE-121, il difetto è raggiungibile inviando pacchetti appositamente costruiti a un DNS Server vulnerabile. Nessun passaggio di login, nessuna esca di phishing, nessuna seconda fase per arrivare al codice vulnerabile — il parser gestisce dati controllati dall'attaccante prima che venga attraversato qualsiasi confine di fiducia. Lo sfruttamento riuscito produce esecuzione di codice con i privilegi del servizio DNS, che su Windows gira come account locale altamente privilegiato.

Le build interessate coprono da Windows Server 2012 a Server 2025 — ogni release supportata che può ospitare il ruolo DNS Server, incluse 2016, 2019 e 2022. Microsoft non ha pubblicato un singolo KB ordinato; la correzione arriva per build del sistema operativo all'interno del cumulative update di agosto, il che significa che "siamo patchati?" va risposto per host, non per parco macchine.

Non è arrivata da sola. Lo stesso Patch Tuesday ha rilasciato altre due RCE non autenticate con CVSS 9.8 in servizi Windows esposti in rete — CVE-2026-62893 nel server TFTP dei Windows Deployment Services (raggiungibile via UDP/69) e CVE-2026-62815 in Microsoft QUIC — oltre a una RCE con CVSS 8.8 nel DHCP Server. L'aggiornamento di agosto è stato un grappolo di RCE di rete pre-autenticazione. Il DNS è quella che pesa di più, per dove si trova.

Perché "sfruttamento meno probabile" è la finestra, non il cessato allarme

I team di sicurezza hanno imparato a leggere l'indice di sfruttabilità di Microsoft come ausilio al triage. È un buon ausilio, ma per un bug di questa forma misura la cosa sbagliata. "Meno probabile" riflette quanto è difficile scrivere l'exploit oggi — il buffer overflow richiede una catena di memory corruption funzionante contro un servizio irrobustito da ASLR e CFG. Non dice nulla su cosa accade dopo che il primo proof-of-concept affidabile atterra su GitHub.

Questa pellicola l'abbiamo già vista. Nel luglio 2020, Check Point rivelò SIGRed — CVE-2020-1350 — una RCE wormable vecchia di 17 anni nello stesso DNS Server di Windows, valutata CVSS 10.0. CISA emise la Emergency Directive 20-03 concedendo alle agenzie federali un solo giorno per applicare la patch. Alla fine non ci fu alcun worm di massa — perché l'industria trattò "RCE wormable nel DNS di Windows" come l'evento a cinque allarmi che era, e patchò dentro la finestra. L'assenza di catastrofe fu il risultato della risposta, non la prova che la minaccia fosse sopravvalutata. Trattare la versione di quest'anno come routine perché l'altra volta non bruciò nulla ribalta la lezione.

"Ci arriviamo alla prossima finestra di manutenzione — Microsoft dice che lo sfruttamento è meno probabile."

Quella frase è esattamente ciò su cui l'attaccante scommette. Il divario tra il rilascio della patch e lo sfruttamento affidabile è dove si decide l'intera gara, e si misura in giorni, non in trimestri.

Il problema dei domain controller

Ecco cosa rende CVE-2026-62878 diversa da un bug wormable in una qualche appliance di frontiera. In un ambiente Active Directory, il ruolo DNS Server è quasi sempre co-locato con AD DS sui domain controller. Active Directory è dipendente dal DNS: i client trovano i domain controller tramite record SRV, e il deployment standard raccomandato da Microsoft fa girare il DNS integrato in AD sui DC stessi.

Quindi "patcha i tuoi DNS Server" è, per la maggior parte delle organizzazioni, un eufemismo per "patcha i tuoi domain controller" — la singola classe di asset più sensibile che possiedi. L'esecuzione di codice nel servizio DNS su un DC è a un passo dalle chiavi della directory: SYSTEM su un domain controller, poi forgiatura di ticket Kerberos, poi l'intero piano dell'identità. Un attaccante che ci arriva da una posizione di rete non autenticata ha saltato ogni fase iniziale della kill chain.

E poiché il bug è wormable, un DNS Server compromesso non resta uno solo. Un exploit auto-propagante trasforma ogni DC infetto in un punto di lancio per il successivo — i DNS server interni si parlano di continuo, e il traffico per veicolare l'exploit assomiglia, a livello di pacchetto, al traffico DNS che quei server sono fatti per scambiarsi.

Come una RCE wormable nel DNS si muove in una rete

Un worm ha bisogno di tre cose: un servizio vulnerabile e raggiungibile; un exploit affidabile; una lista di bersagli. CVE-2026-62878 fornisce le prime due non appena esiste un PoC. La terza è banale in un ambiente AD — un DC compromesso conosce già ogni altro DNS server della foresta, perché replica con loro.

La firma di propagazione è il segnale rivelatore. Il servizio DNS di un domain controller, a regime, è un responder: risponde a query ed esegue ricorsione verso un piccolo insieme di forwarder. Un DC trasformato in paziente zero inizia a fare qualcosa che non ha mai fatto — emettere pacchetti costruiti e sovradimensionati verso altri DNS server, iniziare connessioni che normalmente riceve, propagarsi lungo i percorsi di replica a velocità macchina. Nulla di tutto ciò fa scattare un motore a firme, perché non c'è un file malware da calcolare in hash e i pacchetti sono DNS ben formati sulla porta attesa. Ciò che lo tradisce è il comportamento: una macchina che ha sempre e solo ricevuto ora origina in modo aggressivo, verso i peer, in uno schema a raffica che nessun amministratore umano produce.

Remediation

Trattala come un'emergenza sui domain controller, non come una patch DNS di routine. Il runbook seguente è ordinato per un servizio che non puoi semplicemente spegnere.

1. Sono interessato?

Enumera ogni host con il ruolo DNS Server, non solo quelli che consideri "DNS server":

# Nell'intero dominio: ogni server con il ruolo DNS installato
Get-ADComputer -Filter * -Properties OperatingSystem |
  ForEach-Object {
    if (Get-WindowsFeature -ComputerName $_.Name -Name DNS -ErrorAction SilentlyContinue |
        Where-Object Installed) { $_.Name }
  }

# Su un host sospetto, conferma il servizio e la build in esecuzione
Get-Service DNS
systeminfo | findstr /B /C:"OS Version"

Ogni domain controller in un deployment AD standard è in scope. Lo è anche ogni member server promosso a DNS, e ogni appliance DNS Windows standalone in DMZ — quelle esposte a internet hanno la priorità massima.

2. La patch — la correzione esatta

Applica il cumulative update di agosto 2026 per ogni build interessata. Non esiste un singolo KB; associa la build Windows di ciascun host alla sua voce nella Security Update Guide di agosto 2026 e conferma il numero di build post-patch invece di fidarti dell'interfaccia della cronologia aggiornamenti. Il riavvio è necessario perché il servizio DNS carichi il binario corretto. I domain controller vanno patchati con la stessa cadenza d'emergenza che useresti per un difetto in KEV, anche se questo non lo è (ancora).

3. Non puoi patchare subito? Controlli compensativi

Il DNS non può essere messo offline in un ambiente AD, quindi riduci la raggiungibilità invece della disponibilità:

• Blocca l'exploit al perimetro. Il servizio DNS di nessun domain controller dovrebbe mai essere raggiungibile da internet. Verifica che UDP/TCP 53 verso i DC sia negato in ingresso al bordo. Il DNS autoritativo esposto all'esterno non dovrebbe girare affatto su un DC.
• Segmenta il DNS interno. Restringi quali host possono iniziare traffico DNS verso i tuoi DC; la propagazione di un worm dipende dalla raggiungibilità DC-verso-DC e client-verso-DC sulla 53.
• La mitigazione di registro dell'era SIGRed vale ancora come difesa in profondità. Limitare la lunghezza massima dei pacchetti DNS su TCP (TcpReceivePacketSize = 0xFF00) sotto HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters e riavviare il servizio riduce la superficie per le vie di overflow basate su TCP. È un tampone, non un sostituto della patch — applicalo solo se davvero non puoi ancora riavviare, e rimuovilo dopo aver patchato.

4. Caccia alla compromissione

Poiché non c'è artefatto su file, caccia sul comportamento e sulla genealogia dei processi, mappata su MITRE ATT&CK:

• Segnale di crash-loop. Crash ripetuti di dns.exe o riavvii del servizio DNS (Windows Event ID 1000/7031/7034 riferiti al servizio DNS) sono la classica impronta pre-affidabilità di un exploit in fase di messa a punto. Genera un alert.
• Genealogia anomala dei processi — qualsiasi processo figlio generato da dns.exe è ad alta fedeltà. Un servizio DNS non lancia cmd.exe, powershell.exe o rundll32.exe. Mappa su T1190 (Exploit Public-Facing Application) all'ingresso e su T1059 nel seguito.
• Traffico in uscita da un responder. Il servizio DNS di un DC che origina pacchetti costruiti/sovradimensionati verso altri DNS server, o nuove connessioni in uscita dal servizio DNS verso peer interni, è la propagazione del worm — T1210 (Exploitation of Remote Services) lungo il fan-out.
• Classici del post-exploit sul DC — nuovi servizi, scheduled task o account locali che compaiono su un domain controller poco dopo un riavvio DNS (T1543, T1053, T1136).

5. Eradicazione e verifica

Se un DC mostra uno qualsiasi dei segnali sopra, trattalo come una compromissione a livello di directory, non come un incidente su singolo host:

• Isola il DC, ma pianifica prima la continuità di AD — DNS e autenticazione dipendono da esso.
• Assumi che il materiale d'identità sia esposto. Ruota la password di krbtgt due volte (con l'intervallo di replica richiesto tra le due rotazioni), resetta l'account macchina del DC interessato, e ruota le credenziali privilegiate che si sono autenticate attraverso di esso.
• Ricostruisci il DC da supporti noti-buoni invece di pulirlo in loco; il codice a livello SYSTEM su un domain controller non può essere ripulito in modo affidabile.
• Verifica dopo aver patchato: conferma il numero di build corretto, conferma l'assenza di processi figli residui di dns.exe o servizi inattesi, e ri-baselina il comportamento in uscita del servizio DNS.

Intercettare il worm durante la propagazione — e chiudere prima l'esposizione

La verità scomoda di un exploit DNS wormable e senza file è che gli strumenti su cui la maggior parte degli ambienti conta guardano nel posto sbagliato. L'EDR sorveglia gli endpoint per file malevoli e alberi di processo; una catena da stack-overflow a shellcode che vive nella memoria del servizio DNS e si propaga come pacchetti DNS ben formati offre al sensore centrato sui file pochissimo da confrontare. L'NDR basato su firme non fa meglio — non esiste una firma per "pacchetto DNS legittimo, inviato da un server che non dovrebbe mai inviarlo".

È il caso per cui è stata costruita l'AI Traffic Analysis di Zero Hunt. Un modello di deep learning proprietario, addestrato su miliardi di sequenze PCAP e in esecuzione localmente sulla GPU dell'appliance a 2.7+ Gbit/s, valuta il traffico in modo comportamentale su quattro teste di inferenza parallele — traffico sospetto, classificazione malware, identificazione del tipo di attacco e fingerprinting applicativo. Il segnale che tradisce un worm DNS è esattamente quello che il modello è tarato per far emergere: una macchina il cui ruolo si è silenziosamente invertito, un responder che ha iniziato a originare, una raffica di pacchetti DC-verso-DC che non corrisponde ad alcuna cadenza umana. Lo vede mentre accade, non nel digest SIEM del mattino dopo — il che, per un worm a velocità macchina, è la differenza tra un DC compromesso e l'intera foresta.

Rilevare la propagazione è il secondo risultato migliore. Il migliore è dimostrare che la porta non è mai stata aperta. Le campagne change-triggered di Zero Hunt lanciano una valutazione generativa completa entro un'ora quando un nuovo asset compare sul perimetro — così un DNS Server esposto a internet da una regola di firewall mal configurata viene validato contro un tentativo di exploit fresco e per-bersaglio prima che un worm esterno lo trovi. Lo sciame di 10 agenti scrive l'exploit per il tuo ambiente invece di rieseguire un PoC pubblico, e ogni finding è ri-testato nell'AI Gym e firmato ECDSA per la catena di custodia. "Sfruttamento meno probabile" smette di essere una scommessa che piazzi sul calendario dell'attaccante e diventa un'affermazione che puoi davvero verificare contro i tuoi domain controller — prima che scada il conto alla rovescia.