Initial Access Broker russofono (non confermato)high
FortiBleed: non c'è una patch, perché non c'è una vulnerabilità
Circa metà dei firewall Fortinet esposti su internet ha le credenziali amministrative in mano a un access broker. Non c'è una CVE da patchare: ci sono file di configurazione esportati, hash SHA-256 crackati offline e login perfettamente legittimi. A luglio SOCRadar ha collegato l'operazione ai ransomware INC e Lynx.
La cosa che manca
Ogni dossier di questo sito, finora, ha avuto al centro un difetto: un CVE, una deserializzazione, un header non validato. FortiBleed non ne ha. Non c'è un bug, non c'è un exploit, non c'è una patch che chiuda la faccenda — e Fortinet, su questo, ha ragione. È esattamente ciò che lo rende difficile da gestire.
- 13 giugno 2026Il server esposto
Diachenko rende pubblico il database di credenziali FortiGate.
- 16 giugno 2026L'analisi
SOCRadar e Arctic Wolf pubblicano.
- 18 giugno 2026L'alert
CISA emette un avviso di hardening.
- 22 giugno 2026La replica
Fortinet risponde rimandando a FG-IR-26-060 e FG-IR-25-647.
- 1 luglio 2026Il collegamento
SOCRadar lega la campagna a INC Ransom e Lynx.
Il 13 giugno 2026 il ricercatore Volodymyr «Bob» Diachenko rende pubblico un server di un attaccante rimasto esposto su internet: dentro, un database in crescita di credenziali amministrative FortiGate, già validate. Il 16 giugno SOCRadar e Arctic Wolf pubblicano l'analisi. Il 18 giugno CISA emette un alert di hardening. Il 22 giugno Fortinet risponde formalmente, rimandando agli advisory FG-IR-26-060 e FG-IR-25-647.
I dispositivi con credenziali confermate arrivano a 86.644, in 194 paesi: circa metà di tutti i firewall Fortinet raggiungibili da internet.
Come funziona una campagna senza exploit
- 01Scansionesi cercano FortiGate con gestione o SSL VPN esposti
- 02Config exportil file di backup contiene topologia e hash delle password
- 03Cracking offlineSHA-256 con sale, su cluster GPU affittati a ore
- 04Login legittimonessun exploit: l'autenticazione riesce perché deve riuscire
- 05Posto d'ascoltoil firewall viene configurato per catturare il traffico di autenticazione
La catena è banale, e la banalità è il punto. L'attaccante scansiona internet in cerca di FortiGate con l'interfaccia di gestione o l'endpoint SSL VPN esposti. Da questi estrae il file di configurazione — un file nato per i backup e le migrazioni, che contiene la topologia della rete e gli hash delle password di amministratori e utenti locali. Poi cracka gli hash offline, con cluster GPU affittati a ore.
Il bersaglio sono i vecchi hash SHA-256 con sale, veloci da testare. Fortinet è passata a PBKDF2 nelle build 7.2.11, 7.4.8 e 7.6.1, con una condizione che vale la pena leggere due volte: l'aggiornamento non riscrive gli hash esistenti. Ogni amministratore resta su SHA-256 finché non fa il primo login dopo l'upgrade. E c'è di peggio: per retrocompatibilità quelle build conservano l'hash originale in un campo nascosto old-password, invisibile dalla console ma leggibile in qualunque backup di configurazione. Un dispositivo che credi protetto da PBKDF2 può ancora consegnare materiale crackabile.
A quel punto l'attaccante fa login. Niente shellcode, niente file su disco, niente da intercettare al perimetro: le credenziali sono corrette, l'autenticazione riesce perché deve riuscire.
Il loop
Qui la campagna smette di essere un furto di credenziali e diventa una macchina. Ottenuto l'accesso amministrativo, l'attaccante configura il firewall come posto d'ascolto passivo. Arctic Wolf ha fatto reverse engineering della toolchain: un pannello «FortiGate Sniffer» che pilota la cattura, e un binario Go chiamato CyberStrike Harvester v1.5 che digerisce pcap e testo FortiGate estraendo credenziali da NTLM, Kerberos, RADIUS, TACACS+, LDAP, HTTP, FTP, MSSQL, cookie e token di sessione — già formattati per Hashcat.
Il firewall non viene bucato: viene usato per quello che sa fare. Sta al confine, tutto il traffico di autenticazione gli passa davanti per definizione, e il comando FortiOS per catturarlo è nel manuale.
Le credenziali raccolte rientrano nell'infrastruttura di scansione e generano il bersaglio successivo. Arctic Wolf lo chiama credential feedback loop: ogni vittima è insieme bersaglio e reclutatore. Fra il 31 maggio e il 15 giugno: 659 pipeline di raccolta, oltre 110 milioni di credenziali.
Dove finisce l'accesso
Per due settimane la domanda aperta è stata: un access broker vende, ma a chi?
Il 1° luglio SOCRadar risponde, per la via più antica: un errore di OPSEC degli attaccanti. Un server lasciato accessibile ha esposto file interni, log e documentazione operativa. Dentro, un operatore risultava loggato nei pannelli di negoziazione di INC Ransom e di Lynx, intento a trattare riscatti. Secondo riscontro indipendente: le vittime di FortiBleed si sovrappongono a quelle di una directory aperta collegata a INC.
Dagli stessi documenti emerge un'organizzazione di circa 20 persone con divisione del lavoro: un nucleo ristretto per le intrusioni ad alto impatto, specialisti, un back-office di junior. La fase post-accesso: scansione di ~11.250 portali FortiGate in oltre 150 paesi, accesso admin confermato su 409 bersagli, catena completa — VPN, domain controller, domain admin — su 354, e almeno 12 deployment di ransomware con centinaia di endpoint cifrati.
Cosa non sappiamo
Molto.
- I numeri non concordano perché non misurano la stessa cosa: ~74.000 dispositivi (CISA, 18 giugno), 86.644 (19 giugno), 430.000+ bersagliati, 110 milioni di credenziali, 30.000-75.000 verificate secondo Arctic Wolf. Stadi di validazione diversi, in date diverse.
- L'attribuzione è una valutazione, non un fatto. «Russofono» deriva da indicatori indiretti sull'infrastruttura. Nessuna agenzia l'ha confermata formalmente.
- Il legame con INC e Lynx poggia su un solo vendor, che trattiene alias, tooling e IOC in attesa del whitepaper. Evidenza forte, non ancora replicata da terzi.
- Fortinet non condivide l'inquadramento: parla di riuso di credenziali da incidenti precedenti più brute force contro dispositivi senza igiene delle password né MFA, e dichiara l'attività «non collegata ad alcun incidente o advisory recente».
- Sull'AI i vendor si contraddicono. Alcuni report descrivono tooling AI-assistito; Arctic Wolf ha esaminato il materiale recuperato e scrive che l'automazione è massiccia ma non prova un processo decisionale basato su AI: il marchio «CyberStrike» usa linguaggio da «AI pentest», e questo è quanto.
Gli ID ATT&CK in testa a questo dossier sono copiati dalla mappatura pubblicata da Arctic Wolf Labs, non dedotti.
Cosa si fa
Senza aspettare un aggiornamento che non esiste: togliere interfaccia di gestione e SSL VPN dall'esposizione diretta a internet — la mitigazione a impatto più alto; ruotare tutte le credenziali admin, utente locale e VPN, trattandole come già compromesse; imporre MFA resistente al phishing (FIDO2 o certificati) su ogni accesso amministrativo e remoto.
Poi la parte che quasi tutti sbagliano: aggiornare a 7.2.11 / 7.4.8 / 7.6.1, far fare a ogni amministratore un login post-upgrade, e su 7.2.x e 7.4.x abilitare login-lockout-upon-weaker-encryption per purgare gli SHA-256 residui. L'upgrade da solo non basta.
Per la caccia retrospettiva l'indicatore migliore è documentato: export del file di configurazione verso un IP esterno nei log di audit del FortiGate. Poi login admin da geografie anomale, account nuovi fuori workflow, modifiche alla configurazione di logging.
La finestra della patch è delimitata, quella delle credenziali no. Un CVE ti dà uno scope e una data. Un database di credenziali valide resta aperto finché non le ruoti tu, una per una — e sopravvive a qualunque aggiornamento.
