PEERSTITCH infetta FortiGate dopo il furto dei segreti di oltre 500 firewall

🛡️ Executive Summary

• UNC5820 ha sfruttato CVE-2024-47575 contro un FortiManager di un provider telecom, sottraendo configurazioni e materiale crittografico relativo a oltre 500 FortiGate.
• Le informazioni rubate hanno permesso agli attaccanti di tornare sui firewall, intercettare traffico, avviare VPN e sfruttare CVE-2025-61624 per ottenere accesso root.
• PEERSTITCH viene iniettato direttamente nei processi miglogd e iked: non lascia un binario persistente, non apre porte e non crea connessioni outbound proprie.

Un singolo FortiManager compromesso ha consegnato agli attaccanti la mappa, le configurazioni e il materiale di fiducia di oltre 500 firewall FortiGate. La nuova ricostruzione di Unit 42 mostra cosa accadde dopo lo sfruttamento di FortiJump nel settembre 2024 contro un provider di servizi telecom: gli operatori monitorati come CL-STA-0954, alias UNC5820, non si limitarono al server di gestione centrale. Utilizzarono quanto sottratto per tornare sui firewall amministrati, intercettare traffico, stabilire sessioni VPN e infine distribuire PEERSTITCH, un impianto ARM64 che vive dentro la memoria dei processi FortiOS. È il caso esemplare di come la compromissione del management plane possa sopravvivere alla patch iniziale.

FortiJump svuota FortiManager e consegna oltre 500 firewall agli attaccanti

L’accesso iniziale passa da CVE-2024-47575, vulnerabilità FortiManager nota come FortiJump che consente a un attaccante remoto non autenticato di inviare comandi attraverso il canale di gestione FMG-Access sulla porta TCP 541. Gli operatori registrarono sul FortiManager una falsa appliance FortiGate denominata localhost e crearono un archivio .tm successivamente esfiltrato. Nella ricostruzione tecnica di Unit 42 il contenuto rappresenta il vero moltiplicatore dell’incidente: configurazioni complete di oltre 500 FortiGate, database centrali, topologia interna, routing, indirizzi pubblici, credenziali cifrate, certificati e chiavi private utilizzate nel rapporto di trust tra piattaforma centrale e firewall gestiti.

Il caso porta a un livello superiore il problema già emerso con FortiBleed e il furto di credenziali dagli apparati FortiGate. Qui non viene colpito un singolo firewall: viene violata la macchina che conosce e amministra tutti gli altri. Unit 42 precisa che non ha investigato le reti dei clienti protette dai dispositivi interessati e quindi non può affermare che oltre 500 organizzazioni siano state compromesse. È però confermata l’esposizione del materiale necessario per individuare, raggiungere e impersonare parti dell’infrastruttura gestita.

Leggi anche: CISA inserisce FortiOS tra le vulnerabilità sfruttate e impone verifiche oltre la patch

Configurazioni e credenziali rubate diventano un secondo accesso

Dopo un lungo dwell time gli attaccanti hanno utilizzato il FortiManager già violato per distribuire configurazioni di packet sniffing verso più FortiGate downstream, intercettando traffico HTTP non cifrato e diversi servizi amministrativi. Le configurazioni sottratte contenevano inoltre password amministrative e SSL/VPN conservate in forma reversibile: Unit 42 ha verificato durante l’indagine che tali valori potevano essere recuperati e gli attaccanti li hanno poi utilizzati per aprire sessioni VPN legittime verso i firewall perimetrali.

È un passaggio importante perché modifica la natura dell’accesso. Dopo l’exploit iniziale l’operatore non deve necessariamente continuare a comportarsi come un intruso: può rientrare utilizzando credenziali valide e protocolli previsti dall’architettura. Lo stesso problema interessa tutte le appliance che concentrano identità, VPN e accesso ai sistemi interni, come mostrano le compromissioni di NetScaler nelle quali sessioni e credenziali restano utilizzabili oltre la vulnerabilità iniziale.

CVE-2025-61624 porta l’attaccante dalla console FortiOS a root

Il secondo exploit completa la catena. CVE-2025-61624 colpisce system.auto-script di FortiOS e consente a un amministratore autenticato di utilizzare path traversal nel nome dello script per leggere o scrivere file al di fuori della directory prevista. Il problema è particolarmente grave perché la normale console amministrativa FortiOS resta separata dalla shell Linux sottostante, mentre il motore degli auto-script opera con privilegi root. Gli attaccanti hanno quindi trasformato un account amministrativo già ottenuto in capacità di scrittura sul filesystem e di esecuzione al livello del sistema operativo.

La dinamica ribadisce perché sui dispositivi di sicurezza una vulnerabilità post-authentication possa diventare critica quando viene concatenata a un precedente furto di credenziali. Anche le recenti campagne contro FortiOS hanno mostrato che il rischio reale nasce spesso dalla combinazione tra accesso precedente, persistenza e vulnerabilità successive, non dal CVSS isolato di una singola falla.

PEERSTITCH vive dentro miglogd e iked senza aprire una porta

PEERSTITCH è un eseguibile Linux ARM64 scritto in C che funziona come injector one-shot. Dopo avere individuato i processi /bin/miglogd, responsabile dei log, e /bin/iked, che gestisce IKE e IPsec, utilizza ptrace per interromperli temporaneamente, analizzarne la memoria e allocare una nuova regione RWX da 16 KB. Il payload viene quindi scritto direttamente attraverso /proc/<pid>/mem e il binario utilizzato per l’iniezione può essere eliminato.

Il risultato è molto diverso da una backdoor tradizionale. PEERSTITCH non mantiene un proprio processo persistente, non apre una porta di ascolto e non genera una connessione command-and-control riconoscibile. Il codice malevolo osserva invece i dati già elaborati dai processi FortiOS legittimi e crea un canale tra miglogd e iked direttamente attraverso la loro memoria. Questa tecnica rende insufficienti molti controlli basati sulla ricerca di file, socket o processi inattesi e conferma la tendenza degli attaccanti a rifugiarsi nei dispositivi edge dove EDR e telemetria endpoint tradizionale hanno visibilità molto più limitata.

Anche ACME viene trasformato in un canale per la reverse shell

Unit 42 ha trovato inoltre un secondo meccanismo di persistenza che abusa del modulo Apache mod_md, normalmente utilizzato per la gestione automatizzata dei certificati attraverso ACME. Gli operatori hanno modificato la configurazione affinché FortiGate interrogasse una authority controllata dall’attaccante e utilizzasse /bin/node durante le challenge DNS-01. I comandi inseriti nelle risposte del server ACME potevano così essere trasformati in esecuzione locale e stabilire una reverse shell SSH.

L’interesse dell’attore per i protocolli nativi dell’appliance emerge anche dal tentativo di impersonare FortiManager nei confronti dei FortiGate attraverso FGFM. Unit 42 ritiene possibili due strade: l’abuso di CVE-2024-26009 oppure il riutilizzo diretto del materiale crittografico sottratto dal FortiManager. Le evidenze disponibili non consentono di scegliere con certezza tra le due. È però il trust rubato a rappresentare il vero problema: una piattaforma centrale compromessa può continuare ad avere conseguenze anche quando il bug che l’ha aperta è stato corretto.

Gli attaccanti spengono i log prima di cancellare le proprie tracce

La campagna comprende una fase anti-forense particolarmente aggressiva. Gli operatori hanno terminato miglogd e syslogd, cancellato crash log, rimosso amministratori temporanei e configurazioni VPN, eliminato gli auto-script utilizzati per il deployment e sovrascritto file modificati con contenuti apparentemente normali. Lo stesso PEERSTITCH elimina il proprio artefatto dal filesystem dopo l’iniezione. Unit 42 ha inoltre osservato interruzioni della telemetria verso il sistema di gestione nei periodi coincidenti con l’attività malevola.

Il comportamento conferma un principio già evidente nelle compromissioni degli apparati perimetrali dove patchare non equivale a dimostrare che la macchina sia pulita. Se log locali, processi di logging e revisioni della configurazione possono essere manipolati dal sistema compromesso, l’assenza di un IoC semplice non costituisce una prova di integrità.

Continua con:

FortiBleed mostra come i FortiGate diventino depositi di credenziali ad alto valore

Le appliance Internet-facing richiedono verifica forense anche dopo l’aggiornamento

Chi gestisce FortiManager deve considerare compromesso anche il trust downstream

La remediation non può quindi fermarsi all’aggiornamento di FortiManager o FortiOS. Le organizzazioni esposte devono verificare revisioni di configurazione, auto-script contenenti traversal ../../, crash anomali di miglogd, iked e syslogd, regioni di memoria RWX inattese e accessi a /proc/<pid>/mem. Vanno inoltre controllati account amministrativi, sessioni VPN, certificati e chiavi utilizzati nel rapporto tra FortiManager e FortiGate.

La conseguenza più pesante riguarda però il materiale crittografico rubato. Certificati, chiavi e credenziali che hanno lasciato la piattaforma rimangono validi finché non vengono ruotati. Per un MSP o un provider che gestisce centinaia di firewall, il management plane diventa così uno dei punti più sensibili dell’intera infrastruttura: compromettere FortiManager significa ereditare una parte della fiducia accordata a tutti i dispositivi collegati. PEERSTITCH è il malware visibile alla fine della catena; il vero incidente comincia molto prima, quando un solo sistema centrale perde i segreti con cui controlla centinaia di firewall.