Cosa è successo

Il 14 ottobre 2026 l'unità di ricerca Unit 42 di Palo Alto Networks ha reso pubblica l'analisi di PEERSTITCH, un impianto per firewall FortiGate scoperto durante l'indagine su un'intrusione prolungata ai danni di un fornitore di servizi gestiti nel settore delle telecomunicazioni. Pochi giorni dopo, la CVE-2025-61624 – la falla di FortiOS usata per installarlo – è stata aggiunta da CISA al catalogo delle vulnerabilità sfruttate (KEV), con scadenza di rimedio fissata al 19 ottobre per le agenzie federali statunitensi.

La storia è interessante perché mostra una catena completa, con tempi lunghi. Secondo la ricostruzione riportata da SecurityWeek, l'attore – tracciato da Unit 42 come CL-STA-0954 e sovrapponibile a UNC5820, sospettato di essere legato a uno Stato – ha ottenuto l'accesso iniziale nel settembre 2024 sfruttando la CVE-2024-47575 (nota come "FortiJump"), una falla critica di FortiManager, la console che governa centralmente i firewall. Da lì ha registrato un FortiGate virtuale "fantasma" ed estratto un archivio di configurazione con i dettagli del FortiManager, di oltre 500 FortiGate gestiti e della rete della vittima. La falla di FortiManager è stata corretta a ottobre 2024; quella di FortiOS ad aprile 2026. Tra la violazione e la divulgazione sono passati circa 25 mesi.

I dettagli tecnici essenziali

  • CVE-2025-61624: path traversal nel motore di auto-script della CLI di FortiOS, che consente di scrivere o cancellare file arbitrari. SecurityWeek la descrive come sfruttabile da un attaccante autenticato; una delle fonti tecniche secondarie indica un punteggio CVSS di 9,8 e l'esecuzione come root. Le versioni esatte colpite e corrette vanno verificate nell'advisory Fortinet, che le elenca per FortiOS, FortiPAM, FortiProxy e FortiSwitchManager.
  • PEERSTITCH: impianto ARM64 scritto in C che vive solo in memoria. Inietta codice nei demoni miglogd (logging) e iked (IKE/IPsec) e crea tra i due un canale di comunicazione nascosto che aggira i controlli di validazione predefiniti di FortiOS. Non apre porte in ascolto e non genera connessioni in uscita proprie.
  • Persistenza e anti-forensics: secondo l'analisi tecnica, un canale di comando separato abusa del modulo Apache mod_md per ottenere una reverse shell a ogni rinnovo ACME; l'attaccante ha inoltre terminato processi di log, cancellato i crash log e ripristinato le configurazioni modificate.
  • Impersonificazione del FortiManager: l'attaccante si presenta ai FortiGate come il FortiManager legittimo nelle comunicazioni FGFM, terminando la sessione reale oppure riutilizzando i segreti esfiltrati.

Perché è diverso da una "solita" falla sui firewall

Nelle ultime settimane abbiamo raccontato molte vulnerabilità su apparati perimetrali. Questa però ha una caratteristica che merita attenzione: il bersaglio reale non era il singolo firewall, ma il piano di gestione. Chi controlla il FortiManager ha in mano configurazioni, credenziali, chiavi private e topologia di centinaia di dispositivi. La falla di FortiOS serve solo a trasformare quel patrimonio informativo in presenza persistente sui dispositivi.

Il secondo elemento è l'invisibilità. Un impianto che non scrive su disco, non apre porte e si innesta in processi legittimi non viene intercettato dagli strumenti che molte aziende usano per i controlli di integrità sugli apparati. Il fatto che la patch di FortiManager esista dal 2024 non basta: chi era già stato compromesso prima di aggiornare resta compromesso dopo l'aggiornamento. Questo è il punto che le procedure di patch management, da sole, non coprono.

Cosa significa per le aziende italiane

Il caso riguarda un operatore di telecomunicazioni, ma il profilo di rischio è quello di molte realtà italiane: MSP, system integrator, provider di connettività e società che gestiscono decine o centinaia di firewall dei clienti da un'unica console. In Italia questo modello è diffusissimo nelle PMI, che esternalizzano la sicurezza di rete, e nelle strutture sanitarie e negli enti locali, dove la gestione è spesso affidata a un singolo fornitore. Se la console di quel fornitore viene violata, la compromissione si propaga a tutti i clienti, con un effetto di supply chain.

Sul piano normativo il quadro è chiaro. Per i soggetti rientranti in NIS2 (telecomunicazioni e fornitori di servizi gestiti sono espressamente tra i settori interessati) la compromissione prolungata di un'infrastruttura di rete è un incidente da valutare per la notifica al CSIRT Italia entro i termini previsti: pre-notifica entro 24 ore dalla conoscenza di un incidente significativo, notifica entro 72 ore. Se nelle configurazioni esfiltrate o sul traffico gestito transitano dati personali, entra in gioco anche il GDPR con la valutazione della violazione e l'eventuale notifica al Garante entro 72 ore. Inoltre, l'art. 21 di NIS2 e le misure dell'ACN chiedono esplicitamente attenzione alla sicurezza della catena di fornitura: chiedere al proprio MSP come protegge la console di gestione non è una curiosità, è un requisito di due diligence.

Un'ultima considerazione da consulente: il tempo di permanenza di oltre due anni dimostra che "abbiamo applicato la patch" e "non siamo compromessi" sono due affermazioni diverse. Chi ha avuto FortiManager esposto o non aggiornato prima di ottobre 2024 dovrebbe trattare la verifica retroattiva come un'attività dovuta, non facoltativa.

Cosa fare subito

  • Aggiornare entrambi i livelli: FortiManager (advisory FG-IR-24-423) e FortiOS alla versione corretta per la CVE-2025-61624, controllando i numeri di build direttamente nell'advisory Fortinet.
  • Verificare le registrazioni sul FortiManager: cercare FortiGate registrati da indirizzi IP esterni o inattesi. Una registrazione anomala va trattata come compromissione di tutti i dispositivi gestiti.
  • Cercare gli indicatori sui FortiGate: controllare le revisioni di configurazione (diagnose sys config diff) per script system.auto-script con sequenze ../ nel nome; leggere i crash log (diagnose debug crashlog read) alla ricerca di segnali 11 in miglogd, iked o syslogd; ispezionare le mappe di memoria dei processi per regioni anonime RWX da 16 KB. L'assenza di tracce dopo un riavvio non prova che il dispositivo sia pulito.
  • Bloccare e monitorare: inserire in blocklist gli indirizzi IP indicati da Unit 42 (45.32.41.202, 198.199.122.22, 23.240.77.233, 47.18.167.159) e generare un alert su traffico TCP in uscita verso le porte 8084-8085 dagli IP di gestione dei FortiGate.
  • Se c'è sospetto di compromissione: coinvolgere il supporto Fortinet per l'analisi forense prima di ricostruire; poi reset di fabbrica, ripristino da configurazioni offline verificate e rotazione di password amministrative, segreti VPN, chiavi private e certificati.
  • Ridurre l'esposizione: l'interfaccia FGFM e la gestione non devono essere raggiungibili da Internet; limitare gli accessi amministrativi a reti di gestione dedicate e a indirizzi autorizzati.
  • Chiedere al proprio fornitore: se la gestione dei firewall è esternalizzata, richiedere per iscritto lo stato di patching del FortiManager e le evidenze di una verifica retroattiva.

Nota di metodo: i dettagli su CVSS, comandi di verifica e indicatori provengono in parte da fonti tecniche secondarie e vanno confrontati con il report originale di Unit 42 e con gli advisory Fortinet prima di essere usati in produzione.