FortiClient EMS CVE-2026-35616: quando la patch del tuo vendor *è* il malware

Il 27 maggio 2026 Arctic Wolf ha pubblicato la ricostruzione tecnica di una campagna che girava nelle reti dei clienti da settimane: attaccanti non autenticati hanno abusato di CVE-2026-35616 su istanze FortiClient EMS esposte su Internet, hanno modificato policy VPN e flussi di update sul management plane, e hanno usato quel canale di distribuzione legittimo per spingere un eseguibile chiamato FortiEndpoint_Patch.exe su ogni dispositivo gestito. L'eseguibile era l'infostealer EKZ. Ogni credenziale di Chrome, Edge e Firefox — più i cookie di sessione che l'MFA dell'organizzazione doveva proteggere — è uscita dalla rete via HTTP in chiaro verso un singolo VPS all'indirizzo 83.138.53.110.

La parte interessante non è l'infostealer. È che gli endpoint hanno fatto esattamente quello per cui erano configurati — accettare ed eseguire un aggiornamento dal management server del proprio security vendor. La relazione di fiducia che rende EMS utile è la stessa che ha reso l'attacco invisibile. È il pattern supply chain di cui i regolatori scrivono in astratto, istanziato in una rete reale con una CVE reale.

Cos'è davvero CVE-2026-35616

CVE-2026-35616 è un improper access control sull'API di FortiClient EMS. Il record NVD la classifica come CWE-284 con CVSS 3.1 base 9.8 (il bollettino Fortinet FG-IR-26-099 le assegna 9.1; la differenza è nelle assunzioni di scope, non nella gravità). Un attaccante non autenticato invia richieste HTTP costruite ad hoc che bypassano l'autenticazione su endpoint privilegiati. Versioni affette: FortiClient EMS 7.4.5 e 7.4.6. Fix in 7.4.7. I rami EMS 7.2 e precedenti non sono affetti.

I sensori Attacker Eye di watchTowr hanno intercettato lo sfruttamento in natura il 31 marzo 2026 — quattro giorni prima del bollettino Fortinet. Fortinet ha pubblicato il PSIRT il 4 aprile 2026 e CISA ha aggiunto la CVE al catalogo Known Exploited Vulnerabilities due giorni dopo, il 6 aprile 2026, con scadenza federale 9 aprile 2026.

Le agenzie federali civili avevano 72 ore. Per chiunque altro, la cadenza è quella che il proprio change-management board consente.

I due mesi di gap di cui nessuno parla

La timeline è tutta la storia:

Data	Evento
31 mar 2026	watchTowr osserva lo sfruttamento in natura
03 apr 2026	NVD pubblica CVE-2026-35616
04 apr 2026	Bollettino Fortinet PSIRT FG-IR-26-099
06 apr 2026	Aggiunta a CISA KEV (scadenza FCEB 9 apr)
inizio mag 2026	Arctic Wolf inizia a osservare il deployment EKZ via EMS
27 mag 2026	Arctic Wolf pubblica l'analisi completa
28 mag 2026	Copertura BleepingComputer

Due mesi tra l'ordine di patch obbligatoria CISA e la prima campagna infostealer pubblicamente documentata che abusa della stessa falla. La finestra non è stata vuota. Quando Arctic Wolf ha scritto dell'attività EKZ, gli stessi exit node Tor (185.220.101.15, 192.42.116.14) avevano già bussato alle API di FortiClient EMS in più ambienti cliente. Chiunque fosse ancora su 7.4.5 o 7.4.6 a metà maggio era esposto da inizio aprile. È esattamente il gap che la validazione continua esiste per chiudere, ed è il gap che il pentest trimestrale strutturalmente non copre.

Come funziona davvero la campagna EKZ

La parte nuova non è il codice di post-exploitation — EKZ è un credential stealer Chromium/Gecko competente ma poco originale. Il pezzo nuovo è il canale di consegna. L'attaccante non tocca mai l'endpoint direttamente. Si autentica all'EMS (cioè, bypassa l'autenticazione sull'EMS), modifica una policy VPN, spinge una configurazione che lascia uno script in C:\Program Files\Fortinet\FortiClient\logs\Trace\scripts\{GUID}.cmd, e lascia che sia il client FortiClient sull'endpoint a eseguire il resto.

La execution chain ricostruita da Arctic Wolf è uno scenario da incubo per chi gestisce un SOC:

fortitray.exe (oppure ipsec.exe) lancia cmd.exe, che invoca powershell.exe con un payload base64 che scarica hxxp://83.138.53.110/dl/p.exe in C:\ProgramData\ come log.txt, lo rinomina FortiEndpoint_Patch.exe, lo esegue, ed esfiltra i dati raccolti verso hxxp://83.138.53.110/service/save.php in HTTP chiaro.

Riletto con l'occhio di un analista SIEM: ogni passaggio è un'operazione FortiClient legittima. Il processo parent è firmato. La chiamata PowerShell è base64-encoded ma PowerShell viene invocato in continuazione da agent EDR e da tool di management — allertare su ogni invocazione base64 affoga il SOC. Il download è su HTTP, sospetto ma non inaudito per i "mirror di update". Il nome del file di destinazione è FortiEndpoint_Patch.exe — il prodotto del security vendor stesso. L'endpoint di esfiltrazione è /service/save.php su un singolo IP, ma il volume per host è piccolo (cookie, autofill, password cached compresse).

Il credential stealer usa IElevator::DecryptData per estrarre la master key Chromium e carica dinamicamente le librerie NSS per leggere i profili Firefox. Bersaglia autofill (carte di credito, indirizzi, numeri di telefono) e cookie di sessione — il bypass MFA che tutti stanno cominciando a temere. Se ottieni un cookie okta.session valido, il secondo fattore è già stato presentato; non serve ripresentarlo.

Il bollettino PSIRT di Fortinet non pubblica IOC. Il segnale di detection che Arctic Wolf riesce a tirare fuori è una riga di log — Certificate not found in request header seguita da un certificate update riuscito da fortinet-ca2. Se non guardi i log EMS per quell'anomalia specifica, il management plane sembra a posto.

Perché lo stack difensivo classico non lo vede

Tre ragioni, tutte strutturali:

• La finestra di patching presuppone che ci sia una finestra. I pentest trimestrali e i cicli TLPT annuali non possono osservare una fix che va applicata in 72 ore. Anche le scansioni esterne mensili mancano una finestra di sfruttamento attivo di due settimane. La cadenza difensiva deve eguagliare quella offensiva, e quella offensiva si misura ormai in giorni dal CISA-add all'uso in produzione del prodotto dello stesso vendor come canale malware.
• La detection signature-based non cattura un parent process firmato che esegue il suo flusso di update nativo. fortitray.exe è nell'allowlist endpoint di chiunque abbia Fortinet. L'unica anomalia visibile senza analisi comportamentale è l'HTTP outbound inatteso verso 83.138.53.110 — e molti ambienti permettono ancora al software endpoint di scaricare update via HTTP perché alcuni vendor lo fanno davvero così.
• I bollettini vendor senza IOC scaricano l'onere sul cliente. La scelta di Fortinet di non pubblicare IOC è difendibile (non vogliono far capire all'attaccante dove sono ciechi telemetricamente), ma significa che il SOC deve inventarsi il proprio detection content da report di terze parti. Il writeup di Arctic Wolf è la fonte IOC di riferimento per questa campagna. CrowdStrike, Microsoft e Cisco hanno fatto lo stesso negli ultimi trimestri. Il bollettino senza IOC non è più un'eccezione.

Cosa chiedono davvero NIS2 e DORA

Entrambi i framework hanno superato l'assunzione "fidati del vendor".

L'articolo 21(2)(d) della NIS2 elenca la sicurezza della supply chain tra le misure di gestione del rischio obbligatorie, e l'Allegato I del recepimento italiano (D.Lgs. 138/2024) chiede ai soggetti essenziali e importanti di testare la sicurezza dei prodotti e servizi ricevuti dai fornitori ICT, non solo di quelli che producono. Un gap di patch di due mesi su una vulnerabilità CVSS 9.8 in un tool che ha permessi di scrittura su ogni endpoint gestito è esattamente quello che l'ispettore ACN chiederà nel primo ciclo di audit — la prima scadenza di audit NIS2 cade il 30 giugno 2026.

L'articolo 28 della DORA e gli RTS sul TLPT pubblicati a inizio 2025 estendono la stessa logica ai soggetti finanziari. Il rischio ICT di terze parti va dimostrato, non assunto. L'auditor vuole vedere quando l'istanza FortiClient EMS è stata patchata l'ultima volta, quando è stata testata, quale era la copertura di detection dell'API EMS in quel momento, e quale sarebbe stato il tempo di risposta se una configurazione modificata da una richiesta non autenticata fosse comparsa nei log. "Ci fidiamo dei default Fortinet" non è una risposta accettata dal regolatore.

Il lavoro ENISA sul threat landscape degli ultimi due cicli è quasi monotono su questo punto: i report 2024 e 2025 evidenziano entrambi la compromissione supply chain e dei provider di servizi gestiti come top trend, e la percentuale di incidenti che inizia con una CVE nota su un prodotto vendor esposto su Internet continua a salire. CVE-2026-35616 alimenterà la prossima edizione.

Cosa cambia se la validazione è continua

La risposta difensiva al pattern FortiClient EMS non è "patcha più in fretta" — ogni CISO voleva già patchare più in fretta. La risposta è rendere visibile l'esposizione il giorno in cui appare, e rendere auditable l'evidenza di quella visibilità quando il regolatore la chiede.

Il motore di pentest generativo a 10 agenti di Zero Hunt bersaglia esattamente questo gap. L'agente Recon enumera il perimetro esterno a ogni campagna pianificata e change-triggered, identifica nuove appliance e management plane (FortiClient EMS espone un fingerprint distinto che il motore segnala di default), e gli agenti Exploit e Credential validano lo stato sfruttabile dell'host contro le 21 fonti di threat intelligence sincronizzate in continuo — fra cui CISA KEV, NVD ed ExploitDB. Quando CVE-2026-35616 è entrata in KEV il 6 aprile, ogni cliente Zero Hunt con un EMS in scope avrebbe visto un finding fresco al ciclo successivo, con la catena di exploit dimostrata in un container effimero invece che inferita da un banner di versione. I due mesi tra l'aggiunta a CISA e la pubblicazione di Arctic Wolf sono la finestra in cui il patch lag non validato diventa una campagna infostealer documentata — ed è la finestra in cui la validazione continua ha valore difensivo misurabile.

Il lato compliance chiude il cerchio. Ogni finding, scansione e remediation viene mappato automaticamente contro i 32 framework che il motore traccia — NIS2 Titolo 13, DORA articolo 28, ISO 27001 A.5.21 (supplier relationships), NIST CSF SC.RM-04 — e firmato con ECDSA al momento della scrittura, in modo che il bundle di audit che l'ispettore ACN o il lead TLPT EBA effettivamente chiede sia generato in continuo invece che ricostruito a trimestre. Il mapping cross-framework significa che lo stesso finding FortiClient EMS diventa evidenza per audit NIS2, DORA, ISO e SOC 2 in parallelo, invece di tre team che scrivono tre narrative separate sullo stesso patch lag.

Il lato wire è il terzo pilastro, ed è quello che cattura le campagne che sfuggono ai primi due. L'AI Traffic Analysis di Zero Hunt gira sulla GPU dell'appliance a 2.7+ Gbit/s, con quattro head di inferenza paralleli (traffico sospetto, classificazione malware, tipo di attacco, fingerprint applicativo). Il trasferimento HTTP lanciato via PowerShell verso 83.138.53.110 da un host che storicamente parla solo con CDN di update Fortinet è esattamente la signature comportamentale per cui l'head di traffico è stato addestrato — durante l'esfiltrazione, non nel digest SIEM del mattino dopo, e senza dipendere dal fatto che Fortinet pubblichi la lista IOC.

Il management plane del vendor è parte della superficie d'attacco. Trattalo come tale prima che lo faccia l'auditor.