FortiBleed harpoons 86,644 exposed FortiGate firewalls with no flaw to patch

October 6, 2026. The FBI and the US Secret Service publish joint advisory JCSA-20261006-01, confirming that the FortiBleed campaign is still compromising internet-facing FortiGate firewalls and SSL VPN gateways. October 6, 2026. SOCRadar counts more than 86,644 compromised devices across 194 countries. October 6, 2026. Fortinet reiterates that this is not a new vulnerability but credential theft at industrial scale. Why it matters: a CISO facing this campaign will find no patch to apply — remediation runs through MFA, PBKDF2 hashing and pulling firewall administration off the internet.

A campaign with no exploit, but a complete chain

What defines FortiBleed is that it rests on no new software flaw at all. The attack chain — reconstructed after the operators accidentally exposed their own backend server — reads like an industrial access-theft pipeline: scan exposed FortiGate devices, collect credentials through credential stuffing and password spraying fed by earlier leaks and infostealer logs, then exfiltrate password hashes into a distributed GPU cluster.

That cluster runs Hashcat and Hashtopolis, the open-source platform that spreads password cracking across machines, to turn hashes back into plaintext. The underlying weakness, identified by Fortinet, is the legacy storage of administrator credentials as SHA-256 on older FortiOS releases. Unsalted SHA-256 hashes crack quickly on a GPU fleet — which is why the vendor pushes customers toward the 7.4, 7.6 and 8.0 branches, which support PBKDF2.

The rest of the chain is more worrying than the cracking itself. Once credentials are validated, operators create additional administrator accounts on the firewall, sometimes delete the original accounts to lock the organization out of its own device, then enumerate Active Directory and run internal password spraying. It ends in access resale: the recovered logs contain VPN configurations and target lists sorted by revenue — the signature of an initial access broker feeding ransomware affiliates.

The SSL VPN gateway, the entry point everyone forgets to harden

That FortiBleed targets SSL VPN gateways specifically is no accident. An SSL VPN is, by design, an internet-exposed service that accepts connections from anyone before authenticating. It concentrates three weaknesses exploited here in cascade: an exposed perimeter, password-only authentication, and local accounts with weak hashing. The result is that a campaign needs no zero-day and no exploit at all — just enough leaked credentials and enough GPU time to crack what it harvests.

The FBI/USSS advisory therefore recommends measures that require no patch at all: terminate all active admin and VPN sessions, reset passwords, enforce phishing-resistant MFA on administration and remote access, and shrink the administration surface. The hierarchy is explicit — restrict external management via trusted hosts (good), a local-in policy (better), or remove internet administration altogether (best).

This is the hardest point to sell inside a company. Many network teams administer their FortiGate boxes directly from outside, out of convenience, over the HTTPS management port. FortiBleed turns that convenience into security debt: every administration interface reachable from the internet is a door waiting for valid credentials.

What the indicators reveal about the playbook

The advisory publishes a set of indicators of compromise that matter in a SOC. On the infrastructure side, 45.154.12.132 was observed as a C2 server, 154.202.59.169 and 103.27.186.156 as proxy nodes, 45.155.250.158 as a beacon relay, and 85.11.187.8 as a Hashtopolis host. Beacons leave mostly over HTTPS, on non-standard ports such as 4332 and 4432. These are worth blocking at the edge and hunting for in egress logs, since a FortiGate that has already been compromised will keep phoning home long after the initial credential theft.

On the account side, operators add users whose names mimic support accounts — forticloud, fortiuser, fortinet-support, fortinet-tech-support. A SOC should treat the appearance of any of these names as an alarm, not just check IP addresses. Fortinet additionally recommends comparing the current configuration against a known-good baseline, watching domain controller logs for lateral movement, and auditing REST API keys: an unknown key left behind by an attacker equals persistent access.

SHA-256 hashing, the other defense line everyone neglects

The blind spot of this campaign is the password storage format itself. On older FortiOS branches, local administrator credentials are stored as SHA-256 — exactly what the FortiBleed operators crack at scale. Unsalted SHA-256 collapses to millions of attempts per second on a GPU cluster; the distance between a leaked hash and a plaintext password shrinks to hours for weak passwords.

The structural fix is to migrate to the 7.4, 7.6 or 8.0 branches, which store credentials as PBKDF2 — a deliberately slow key-derivation function designed to make cracking prohibitively expensive, even on a GPU fleet. Fortinet documents the cutover through the login-lockout-upon-weaker-encryption setting, which refuses logins from accounts still stored in the old format. This is a migration to schedule, not a patch to apply: existing accounts must be reset to be re-recorded in the new format.

In practice, an administrator can audit local accounts and force the cutover from the FortiGate CLI:

# List local administrators, then re-set the password in the PBKDF2 format
show system admin
config system admin
    edit "admin"
        set password ENC <new-password>
    next
end

The show system admin output also surfaces accounts added by the attacker — often names that mimic support, precisely. Cross-referencing that list against the configuration history remains the most reliable way to spot a past intrusion.

The real operational trap, highlighted by the advisory, is lockout: because actors delete or change the passwords of original accounts, some victims end up locked out of their own firewall. Remediation then goes beyond a simple reset — the device must be reconditioned, and trust with Active Directory rebuilt if the LDAP integration was abused.

Verdict

If you run internet-facing FortiGate boxes, act on three fronts without delay: cut direct remote administration (a local-in policy at minimum, ideally no administration from the internet), enforce phishing-resistant MFA on administration and VPN, and migrate to FortiOS 7.4, 7.6 or 8.0 to enable PBKDF2 hashing of administrator credentials. If your firewall is still on SHA-256 with weak local accounts, treat it as likely compromised — reset every password, audit the accounts, and diff the configuration against a baseline. And if detection is your priority, add the impersonated account names (forticloud, fortiuser, fortinet-support) and the advisory’s addresses to your rules: FortiBleed is not patched, it is monitored and hardened.

References

• FBI / USSS — FortiBleed Operations Continue Targeting Exposed Systems (JCSA-20261006-01, October 6, 2026)
• Fortinet PSIRT — Analysis of Reported Credential Compromise of FortiGate Devices
• SOCRadar — FortiBleed: Fortinet Firewalls Compromised
• CloudSEK — Inside the FortiBleed Open Directory
• Fortinet Community — Enforcing PBKDF2 as hash function for administrator accounts (FortiOS 7.2.11+)