Windows IKE CVE-2026-33824: l'AI ha fatto la ricognizione, l'uomo ha premuto il grilletto

Il 18 agosto 2026 CISA ha aggiunto CVE-2026-33824 — una vulnerabilità di remote code execution pre-autenticazione nel servizio Internet Key Exchange (IKE) di Windows — al suo catalogo Known Exploited Vulnerabilities, imponendo alle agenzie federali una scadenza di tre giorni per la patch ai sensi della BOD 26-04. Fin qui, una brutta giornata di ordinaria amministrazione. Ciò che rende questa storia degna di lettura è dove è stato trovato lo sfruttamento: dentro una singola campagna che Palo Alto Networks Unit 42 attribuisce a un operatore di lingua cinese che ha collegato un modello DeepSeek all'inizio della propria kill chain, lasciandolo cercare, valutare e attaccare da solo. La metà autonoma di quella campagna non ha compromesso nulla. Gli endpoint IKE sono caduti per mano umana. Il divario tra questi due fatti è la vera notizia.

Cos'è davvero CVE-2026-33824

La vulnerabilità è un double free nella IKE Extension di Windows (ikeext.dll), il servizio che negozia i tunnel VPN IPsec. Un attaccante non autenticato invia pacchetti appositamente costruiti a un host con IKEv2 abilitato su UDP 500 o 4500, libera due volte la stessa allocazione di heap e trasforma la corruzione di memoria risultante in esecuzione di codice sulla rete. Nessuna credenziale, nessuna interazione utente, nessun appoggio preliminare: è il servizio in ascolto a fare il lavoro.

Microsoft la valuta CVSS 9.8, e diversi tracker la segnalano come wormable, perché le precondizioni (un responder IKE raggiungibile da internet) sono esattamente il genere di cosa che si ripete su un intero parco macchine. Le build interessate sono ampie: Windows Server dal 2016 al 2025 (incluso 2022 23H2), Windows 10 dalla 1607 alla 22H2 e Windows 11 dalla 23H2 alla 26H1 — qualsiasi sistema che esegua il servizio IKE IPsec, secondo il report di BleepingComputer.

Il dettaglio scomodo della cronologia: Microsoft ha rilasciato il fix nel Patch Tuesday di aprile 2026. Lo sfruttamento osservato da Unit 42 e l'inserimento in KEV sono arrivati quattro mesi dopo. È lo stesso schema di ogni altro articolo "patchata in primavera, bucata in estate" di questo blog — la patch esisteva; i responder IKE esposti non l'hanno ricevuta.

Un solo attore, due mani: cosa ha visto Unit 42

Unit 42 ha tracciato l'operatore sotto gli alias "knaithe" / "KnYuan", un autodefinito "binary security researcher" con base a Zhuhai, in Cina. Ha condotto la campagna come due flussi di lavoro paralleli, e la separazione è il cuore di tutto.

Il ramo autonomo ha usato DeepSeek come motore di ragionamento dietro Hermes Agent, un framework open-source in grado di pilotare un terminale del sistema operativo, eseguire comandi e raggiungere internet. Orchestrato via Telegram, l'agente ha enumerato i bersagli e le loro debolezze tramite il servizio di scansione FOFA, ha scelto tra sette CVE (in software tra cui Langflow, n8n e Citrix NetScaler) e ha tentato lo sfruttamento end-to-end contro più di 460 bersagli — da solo, secondo l'analisi di Unit 42 e il resoconto di BleepingComputer. DeepSeek sarebbe stato scelto perché aveva le protezioni più deboli da aggirare.

Il ramo manuale — lo stesso operatore, mani sulla tastiera — ha preso di mira bug noti in Citrix NetScaler, Apache Tomcat, Marimo Notebook e negli endpoint VPN IKE di Windows. È qui che compare CVE-2026-33824: Unit 42 ha registrato callback di reverse shell contro tre endpoint VPN IKE. In tutto sono riuscite tre intrusioni manuali, e tutte e tre sfruttavano lo stesso bug — CVE-2026-3055 in Citrix NetScaler, non la falla IKE.

	Ramo autonomo (DeepSeek + Hermes)	Ramo manuale (mani sulla tastiera)
Selezione bersagli	scansione FOFA, guidata dall'agente	scelta dall'operatore
CVE usate	7 (Langflow, n8n, NetScaler, …)	NetScaler, Tomcat, Marimo, Windows IKE
Bersagli toccati	460+	460+
Compromissioni riuscite	0	3 (tutte CVE-2026-3055)
Attività su CVE-2026-33824	—	callback reverse shell su 3 endpoint IKE

Perché "l'AI non ha compromesso nulla" è il titolo sbagliato

È tentante leggere il punteggio — ramo autonomo: 460 tentativi, zero successi — come una rassicurazione. È l'esatto contrario. L'agente non ha fallito la parte difficile; la parte difficile non gli è mai stata assegnata. Ha fatto la ricognizione, il fingerprinting, l'abbinamento CVE-bersaglio e il primo tentativo di sfruttamento — la parte alta dell'imbuto, tediosa e ad alto volume, che un tempo limitava la produttività di un attaccante. Il lavoro delicato di corruzione di memoria, come far atterrare un double free su un responder IKE attivo, è rimasto all'uomo.

"Dammi uno scanner che trovi i miei NetScaler e i miei endpoint IKE esposti, li ordini per quale CVE ha più probabilità di andare a segno e bozzi il primo payload — e i tre che richiedono mano ferma me li prendo io."

È il flusso di lavoro documentato da Unit 42, e i ricercatori sono stati netti sul suo significato: pur con impatto limitato, esso "conferma una capacità offensiva autonoma funzionante ed end-to-end". Il numero che dovrebbe preoccupare un difensore non è 3 compromissioni. È 460 bersagli valutati da una sola persona in pochi giorni — un ritmo di ricognizione e selezione che un operatore solitario non potrebbe mai sostenere a mano, ora disponibile per chiunque sappia puntare un modello privo di guardrail contro FOFA.

La matematica dell'esposizione cambia di conseguenza. Quando la valutazione era limitata dall'uomo, un responder IKE affacciato su internet e sfuggito alla patch di aprile poteva restare inosservato per mesi — gli attaccanti dovevano scegliere dove spendere attenzione. Quando la valutazione è un agente che gira senza sosta, ogni responder esposto viene trovato e messo in coda già al primo passaggio. La finestra tra "hai dimenticato di patchare un host" e "qualcuno gli sta inviando pacchetti IKE malevoli" si comprime.

La IKE Extension è una ferita che si riapre

CVE-2026-33824 non è una superficie inedita — è l'ultima voce di uno schema. La base di conoscenza di Zero Hunt fa emergere un intero grappolo di precedenti bug di corruzione di memoria nella IKE Extension nel momento in cui la si interroga: il lotto di RCE di rete di settembre 2022 (CVE-2022-34721 / 34722 / 21843 / 21849), tutte raggiungibili sulla stessa superficie IKE UDP 500/4500, più i problemi di elevazione di privilegi e denial-of-service del 2023 (CVE-2023-36726, CVE-2022-34720). Il responder IKE è da anni una fonte affidabile di bug di memoria pre-auth.

La lezione difensiva di questa storia è concreta: il servizio IKE/IPsec non dovrebbe quasi mai essere un listener esposto a internet in modo generalizzato. La maggior parte delle organizzazioni lo espone perché un concentratore VPN o una macchina Windows RRAS fu messa in piedi anni fa e nessuno ha più rivisto se UDP 500/4500 dovesse rispondere al mondo intero. La patch chiude questa singola istanza; ridurre la superficie d'attacco chiude la classe.

Remediation

Un runbook completo per CVE-2026-33824. Se gestisci host Windows con IPsec/IKEv2 abilitato e raggiungibile, trattala come priorità da sfruttamento attivo, non come manutenzione del prossimo ciclo.

1. Sono interessato?

Qualsiasi build supportata di Windows 10/11 o Windows Server con il servizio IKE Extension in esecuzione e IKEv2 raggiungibile rientra nel perimetro. Verifica l'esposizione:

# Il servizio IKE è in esecuzione?
Get-Service IKEEXT | Select-Object Status, StartType

# C'è qualcosa in ascolto / che risponde sulle porte IKE?
Get-NetUDPEndpoint -LocalPort 500,4500 -ErrorAction SilentlyContinue

# È effettivamente configurata una connessione IPsec/IKEv2?
Get-NetIPsecMainModeSA; Get-VpnServerConfiguration -ErrorAction SilentlyContinue

Dall'esterno, conferma se UDP 500/4500 rispondono da reti non fidate — un responder esposto è la precondizione per lo sfruttamento pre-auth.

2. Patch — il fix esatto

Microsoft ha corretto CVE-2026-33824 negli aggiornamenti cumulativi del Patch Tuesday di aprile 2026 per tutte le release supportate di Windows 10, Windows 11 e Windows Server. Verifica che l'host abbia installato un cumulativo di aprile 2026 o successivo; conferma la KB specifica per la tua build sull'advisory Microsoft per CVE-2026-33824. Se un sistema riporta un livello di patch precedente, è vulnerabile a prescindere dal fatto che la VPN "sembri a posto".

3. Non puoi patchare subito? — controlli compensativi

• Restringi IKE al perimetro. Filtra UDP 500 e 4500 in modo che rispondano solo agli IP dei peer noti; il responder IKE non dovrebbe mai essere un listener generalista su internet.
• Disabilita IKEv2 dove non serve. Se un host esegue IKEEXT solo come default e nessun tunnel IPsec dipende da esso, ferma e disabilita il servizio.
• Termina la VPN altrove. Metti davanti agli endpoint IPsec di Windows un concentratore o un firewall irrobustito che gestisca la negoziazione IKE affacciata su internet, così lo stack vulnerabile non è la prima cosa che un pacchetto raggiunge.

4. Caccia alla compromissione

Il ramo manuale ha lasciato artefatti di rete, non solo sull'host. Mappa la caccia su MITRE ATT&CK:

• Sfruttamento (T1190 — Exploit Public-Facing Application): pacchetti IKE_SA_INIT / IKE_AUTH malformati o sovradimensionati, crash del servizio IKE o riavvii di IKEEXT correlati a traffico UDP 500/4500 in ingresso da ASN sconosciuti.
• C2 / reverse shell (T1071, T1571 — C2 su porta applicativa/non standard): connessioni in uscita da un host VPN/IPsec che storicamente si limitava a ricevere traffico IKE. Unit 42 ha osservato callback di reverse shell da endpoint IKE compromessi — considera ostile qualsiasi traffico in uscita avviato nel contesto del servizio IKE finché non è provato il contrario.
• Impronta di ricognizione (T1595 — Active Scanning): probing UDP 500/4500 ad alto ritmo e su larga scala, coerente con enumerazione stile FOFA; una raffica di handshake IKE su molti host da una sola sorgente in una finestra breve è la firma della valutazione automatizzata.
• Trasferimento tooling / esecuzione (T1105, T1059): creazione inattesa di processi come System a valle di attività IKE; nuovi binari depositati in C:\Windows\Temp o \ProgramData sui gateway VPN.

5. Eradica e verifica

Patchare una macchina che ha già effettuato un callback non sfratta l'intruso. Dopo la patch:

1. Isola ogni host che mostri connessioni in uscita legate al contesto del servizio IKE.
2. Cerca e rimuovi impianti, scheduled task e nuovi account locali sui gateway VPN/IPsec.
3. Ruota credenziali e pre-shared key / certificati IPsec che risiedevano su un endpoint esposto o vi transitavano — dalli per bruciati.
4. Ri-scansiona dall'esterno per confermare che UDP 500/4500 non rispondano più a reti non fidate, e verifica il livello di patch di aprile 2026 dopo la remediation, non prima.

Dove si inserisce Zero Hunt

La lezione di questa campagna non è "un'AI ha bucato una macchina IKE" — non l'ha fatto. È che un avversario ha appena automatizzato il ritmo dell'offesa: scoperta e valutazione continue, guidate da un agente, di ogni responder esposto, a una scala che un singolo operatore non potrebbe mai raggiungere a mano. Un pentest trimestrale e uno scan mensile delle vulnerabilità non rispondono a questo. Non puoi tenere il passo di un attaccante che ri-valuta l'intero perimetro ogni notte ri-testando il tuo ogni novanta giorni.

È esattamente il divario che la piattaforma Zero Hunt è stata costruita per colmare, ed è il motivo per cui qui la nostra risposta parte dal motore offensivo, non dal sensore. Zero Hunt esegue uno swarm di pentest generativo a 10 agenti — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic e Report sotto un AI Controller — che fa al tuo patrimonio ciò che l'Hermes Agent di knaithe ha fatto alla sua lista di bersagli: enumera di continuo l'esposizione, la confronta con un corpus di threat intelligence sincronizzato da 21 fonti (CISA KEV, NVD, EPSS, ExploitDB e altre) e tenta davvero la catena con un exploit scritto per il singolo bersaglio da un LLM locale, non da uno script preconfezionato. Un nuovo asset sul perimetro, o un host che si è perso una patch di aprile, innesca una campagna completa entro un'ora tramite scheduling change-triggered — lo stesso ritmo del "trovato al primo passaggio", ma al servizio del difensore. Ogni nuova skill offensiva viene ri-testata nell'AI Gym contro corpus Vulhub e CVE black-box prima di toccare la produzione, così il motore che sonda i tuoi responder IKE è validato, non improvvisato.

Il lato traffico è il secondo strato, proprio per gli artefatti della caccia in Remediation. L'AI Traffic Analysis di Zero Hunt — un modello di deep learning con quattro teste di inferenza in esecuzione sulla GPU dell'appliance — è pensata per segnalare il callback di reverse shell da un host che storicamente rispondeva solo a IKE, il traffico in uscita su un percorso mai visto prima, il beacon C2 che l'NDR basato su firme si perde, mentre sta accadendo e non nel digest SIEM del mattino dopo. Quando un avversario autonomo comprime a pochi minuti il tempo tra esposizione e callback, uno strato di rilevamento che legge l'intento dal comportamento — non da una firma corrispondente — è ciò che chiude il cerchio. Entrambi girano al 100% on-prem, senza callback verso il cloud, il che conta quando ciò che stai cacciando è a sua volta un'AI dall'altra parte del filo.