By: Garrett Gross, Field CISO, Portnox
Security researchers published findings this week on a campaign they’re calling FortiBleed, and I want to cut through some of the noise around it because the framing matters for how you respond.
Here’s what happened: a threat actor, using Russian language-based tooling and targeting patterns, built an automated system that scanned the internet for Fortinet FortiGate firewalls and VPN gateways, sprayed known and previously leaked passwords against them, and recorded every successful login. They ran this at an industrial scale: over a billion credential attempts across a dedicated 45-GPU cracking cluster. The result is a verified, actively maintained database of working credentials for roughly 75,000 to 86,000 devices across 194 countries. The result: about half of all Fortinet firewalls currently exposed to the internet.
The campaign is still running today.
What makes this operationally interesting is the feedback loop. Once inside a device, the attackers used it as a passive traffic sensor, collecting credentials flowing through the firewall in real time. Those fresh credentials got fed back into the scanner. The more devices they compromised, the more credentials they harvested, the more devices they could compromise. The attack pays for itself.
Names confirmed in the dataset include Oracle, Samsung, Siemens, FedEx, PwC, Comcast, and Accenture. A Turkish NATO defense contractor was fully compromised with classified documents stolen. Fortinet itself reportedly appears in the list.
What This Is Not
There is no zero-day here. No novel exploit. No sophisticated technique that required nation-state resources to develop. This is credential reuse, weak hash formats, and internet-exposed management interfaces combining into a disaster at a global scale.
Fortinet has framed this as “a resharing of data from previous incidents” and says it’s not related to any recent advisory. Multiple independent researchers, including Kevin Beaumont and teams at SOCRadar, Hudson Rock, and Arctic Wolf, disagree. They’ve independently confirmed the credentials are valid and current; the affected device set differs from prior leaks, and many compromised systems are running recent firmware. When you have that level of independent corroboration, practitioners should act on it regardless of vendor positioning.
There’s also a technical wrinkle worth understanding. Fortinet introduced stronger PBKDF2-based password hashing in FortiOS 7.2.11, 7.4.8, and 7.6.1. But here’s the catch: upgrading your firmware doesn’t automatically re-hash existing administrator passwords. Those accounts stay in the older, significantly more crackable SHA-256 format until each administrator logs in after the upgrade. Organizations that patched their firmware but skipped that step are still exposed to exactly this kind of offline cracking. The patch alone wasn’t sufficient.
The Part Most Teams Are Getting Wrong
“Exposed credentials are not the same as a fully breached network” is technically accurate and practically dangerous if you let it slow you down.
If your FortiGate admin credentials are in this database, an attacker can log in remotely, gain access to the network behind the firewall, modify security settings, and create backdoor accounts that survive a password rotation. The question isn’t whether you’ve been breached, it’s how long that door has been open and whether someone already walked through it and left a key under the mat.
I’d also flag the telecom sector’s exposure here, because it’s getting less attention than it deserves. Telecoms account for over 5,600 entries in the dataset, the most of any sector. Telecom infrastructure underpins communications for banking, healthcare, government, and critical infrastructure. Compromise at that layer doesn’t stay contained to the telecom company. The blast radius extends to everyone downstream.
Why This Keeps Happening
FortiBleed is not a Fortinet story in isolation. It fits a pattern that’s been accelerating for a few years now. VPN appliances and firewall management interfaces have become a preferred initial access vector for attackers who want persistent, quiet footholds. The perimeter device, the thing organizations have historically treated as inherently trustworthy, is now one of the most reliably targeted entry points in the enterprise.
The reason that matters is that traditional network security architecture is built on the assumption that getting past the perimeter means you’re in a trusted zone. Once you’re authenticated to the firewall, you’re inside. There’s often very little between that point and lateral movement across the environment.
This is where the zero trust conversation stops being abstract. Zero trust doesn’t assume the perimeter is impenetrable. It assumes the perimeter will eventually fail, or in this case, that valid credentials for the perimeter device will end up in someone else’s hands. The architecture responds accordingly by requiring continuous verification, enforcing least-privilege access, and limiting what any authenticated session can actually reach.
At Portnox, the access control and compliance enforcement we do sits downstream of authentication. That means even if an attacker has valid VPN credentials and gets through the front door, what they can do inside the network is constrained by policy that’s enforced at the device and user level, not just at the perimeter. But there’s a layer worth adding before that: passwordless authentication eliminates the credential itself as an attack surface. If there’s no password to steal, reuse, or crack offline, campaigns like FortiBleed lose their primary weapon. Certificate-based or FIDO2-backed authentication means the thing the attacker is harvesting at scale simply doesn’t exist on your network. Combined with post-authentication access controls, you’re not just limiting blast radius; you’re closing the initial vector. Neither is a silver bullet on its own, but together they represent a fundamentally different posture than hoping your passwords don’t show up in someone’s GPU cluster.
What to Do Right Now
Rotate every FortiGate admin and VPN password now. As in today, not at the next maintenance window. Check which FortiOS version you’re running, and if you’ve recently upgraded, make sure every administrator has logged in post-upgrade to trigger the PBKDF2 re-hash. If that hasn’t happened, manually update the passwords through a super admin account.
Pull your management interface off the public internet if it isn’t already. Enforce MFA on all external access. Hunt for backdoor accounts you didn’t create. Pull authentication logs and look for logins from unfamiliar IPs or accounts that shouldn’t be active.
SOCRadar has a free lookup tool at socradar.io/free-tools/fortibleed to check whether your devices appear in the dataset.
The underlying lesson from FortiBleed is the same one we keep relearning: trusting any single authentication event, at any single point in the network, is not a security posture. It’s a bet. Right now, a lot of organizations are finding out they lost it.