La campagna è attiva in questo momento, mentre leggi questo articolo.

Non è stata una nuova vulnerabilità. Non è stato uno zero-day. Ciò che ha compromesso tra 30.000 e 75.000 firewall FortiGate in 194 paesi è stato qualcosa di molto più semplice: password riutilizzate, account amministrativi con nomi predefiniti di fabbrica e hash di autenticazione SSL VPN craccati offline. La campagna "FortiBleed" è un promemoria diretto che un perimetro non garantisce sicurezza quando le credenziali che lo proteggono circolano già nei database di infostealer. La grande maggioranza dei dispositivi compromessi rimane online e attiva. L’attaccante ha ancora accesso.

Cosa è successo

Il ricercatore Volodymyr Diachenko ha identificato un server operativo di un gruppo di minaccia esposto pubblicamente, contenente strumenti di automazione e un database di credenziali Fortinet validate. Hudson Rock e SOCRadar hanno analizzato i dati in modo indipendente. I numeri divergono (30.791 dispositivi contro più di 73.000 URL uniche), ma la diagnosi è la stessa: scala industriale, credenziali funzionanti e operazione in corso.

Tra i domini identificati figurano Foxconn, Samsung, Siemens, Oracle, PwC, Comcast, Chevron, AT&T, Toyota e centinaia di enti governativi. La presenza nel set di dati indica credenziali validate per quel dominio. Non è una conferma di violazione dichiarata da ciascuna organizzazione, ma non è nemmeno un falso allarme.

Casi di compromissione totale della rete sono stati documentati in Giappone, Taiwan, Vietnam, Iraq e Turchia. Nel caso turco, l’indagine punta a un appaltatore del settore difesa associato alla NATO, con accuse di esfiltrazione di documenti classificati. Questa specifica accusa attende ancora conferma indipendente.

Come funziona la catena

L’operazione è automatizzata e autorinforzante. Ogni dispositivo compromesso alimenta il ciclo con nuove credenziali:

• Scansione di istanze FortiGate esposte su internet (porta 443 e varianti: 4443, 8443, 10443).

• Credential stuffing con password provenienti da violazioni precedenti e raccolte di infostealer.

• Acquisizione di hash SSL VPN per cracking offline su un cluster di 45 GPU tramite Hashtopolis.

• Validazione automatica di ogni credenziale prima dell’inserimento nel database: entra solo ciò che funziona.

• Movimento laterale verso Active Directory in compromissioni più profonde.

• Utilizzo del dispositivo compromesso come punto di ascolto per catturare credenziali in transito e rialimentare il motore di scansione.

Perché le password complesse non hanno aiutato

Una parte rilevante delle credenziali compromesse includeva password fino a 20 caratteri. La complessità non protegge una password già raccolta da un infostealer e circolante in testo in chiaro nei database underground.

Dettaglio tecnico critico: Fortinet ha migrato all’algoritmo PBKDF2 per l’archiviazione delle credenziali amministrative all’inizio del 2025. Questa protezione si applica solo ai dispositivi i cui amministratori hanno effettuato l’accesso dopo aver applicato l’aggiornamento del firmware. I dispositivi senza quel successivo accesso hanno continuato ad archiviare le credenziali in SHA-256 con salt, molto più vulnerabile al cracking offline. Il firewall era aggiornato. La credenziale, no.

Cosa fare adesso: raccomandazioni complete di mitigazione

Esegui questa checklist immediatamente. Non aspettare la conferma della presenza nei set di dati.

1. Ruotare tutte le credenziali ora. Reimpostare le password di tutti gli account amministrativi e VPN SSL associati ai dispositivi Fortinet. La complessità della password precedente è irrilevante se è già stata violata.

2. Abilitare l’MFA obbligatorio su tutte le interfacce di gestione e accesso remoto esposte esternamente, senza eccezioni.

3. Verificare e rinominare gli account predefiniti. Le variazioni dell’utente "admin" rappresentano più di un terzo di tutte le voci nel set di dati. Rinominare o disabilitare tutti gli account amministrativi generici e gli account di sistema nativi di Fortinet.

4. Limitare l’accesso al pannello di amministrazione. Applicare policy local-in per limitare l’accesso all’interfaccia di gestione esclusivamente agli IP interni attendibili. Disabilitare FortiCloud SSO quando non strettamente necessario.

5. Aggiornare il firmware ed effettuare l’accesso dopo l’aggiornamento. La migrazione delle credenziali a PBKDF2 avviene solo con un accesso amministrativo successivo all’applicazione dell’update. Senza quell’accesso, un dispositivo aggiornato continua ad archiviare le credenziali nel formato vulnerabile.

6. Esaminare i log di accesso e VPN alla ricerca di posizioni di accesso anomale, sessioni amministrative inaspettate, accessi fuori orario e volumi di traffico insoliti.

7. Verificare l’esposizione del dominio con i due strumenti gratuiti disponibili. Hudson Rock ha pubblicato un portale di ricerca per dominio per la verifica diretta nel set di dati della campagna. SOCRadar offre il Free Dark Web Report per la scansione nel dark web, nei log di infostealer e nelle basi di credenziali violate. Usali entrambi: i set di dati hanno una copertura parzialmente distinta.

8. Coinvolgere immediatamente il team di risposta agli incidenti se il dominio dell’organizzazione viene identificato in uno dei set di dati. Trattare un risultato positivo come indizio di accesso non autorizzato già avvenuto, non come un rischio teorico. Non attendere ulteriori conferme prima di avviare la risposta.

Conclusione

FortiBleed non ha richiesto nessuna nuova scoperta tecnica. Ha richiesto automazione, credenziali vecchie e un elenco di obiettivi che qualsiasi port scanner può generare.

L’attaccante ha già l’accesso. La domanda è per quanto tempo lo manterrà.