FortiBleed Didn't Break In. It Logged In. (And yes, I have used this type of title before)
I have been ranting for a few years now on passwords and how they are archaic for accessing OT networks. So many of the Hackopedia case studies began with credential theft (or the simple use of default passwords) that it makes me die a little inside every time I see a hack that started that way (including sophisticated JLR Vishing version). So I wanted to put my two cents forward on Fortibleed.
FortiBleed is not a hack. It is an architecture review.
What do I mean? Well, let’s look at what happened. Sometime this spring, attackers began pulling configuration files from internet-facing FortiGate firewalls and cracking the credential hashes stored in them offline, at their leisure. No zero-day. No exotic exploit chain. By mid-June, researchers had working administrator credentials for roughly 75,000 devices across 194 countries. That is about half of every Fortinet firewall exposed to the internet. The victim list reads like a Fortune 500 roster: Samsung, Siemens, Chevron, AT&T, Toyota.
The technical trigger was a legacy password-hashing scheme. Fortinet moved to a stronger hash in newer FortiOS builds, but on upgraded devices, the old SHA-256 hashes lingered until an admin logged in again. So the hashes sat there, crackable, in config files accessible from the open internet.
Read that last part again. The secret that unlocked the device was stored on it, and it stood in the middle of the road, easily discoverable by anyone who knew how to find FortiGate firewalls.
A password is a secret you have to keep in two places at once.
This is the part the industry keeps not saying out loud. Every password is a shared secret. For it to work, the secret has to exist on your side and on the device's side at the same time. You are betting that neither copy ever leaks, is ever reused, or is ever cracked for the entire life of the system.
That is a bad bet on a laptop. On an internet-facing firewall guarding an OT network, it is catastrophic. You are not protecting the crown jewels with a lock. You are protecting them with a lock and a photograph of the key, and you have hung the photograph on the front door.
20-character passwords are better photographs. They are still photographs.
Rotating credentials treats the symptom. Removing them treats the disease.
The reflex after an event like this is to rotate, harden, and enforce complexity. All fine. All is necessary this week. None of it changes the shape of the problem, because the problem was never that the passwords were weak. The problem is that the device was reachable, and that reaching it required only a secret, and secrets travel.
The stronger move is to make the device unreachable in the first place. If a firewall's management interface is invisible to anyone who has not already proven their identity, then a cracked hash buys the attacker nothing. There is no login page to submit it to. The config file, if they ever get it, unlocks a door they cannot find.
This is what a software-defined perimeter does. Identity comes before connectivity, not after. The asset does not announce itself to the internet and then interrogate whoever knocks. It stays dark until an authenticated, authorized identity is established, and only then does a connection exist. You cannot brute-force, phish, or crack your way into a service you cannot see.
The OT stakes are not abstract.
An exposed laptop is a bad day. An exposed firewall in front of a substation, a pumping station, or a plant floor is a different category of problem, because the blast radius is physical and the tolerance for downtime is close to zero. OT operators have spent years being told to segment, enforce IEC 62443 zones and conduits, and keep the enterprise network separate from the process network. FortiBleed is a reminder that a segmentation boundary built on an internet-facing, password-gated box is not a boundary. It is a suggestion.
I also hope that somewhere between now and the next advisory, someone asks their OT CISO a harder question than “whether the passwords are strong enough”. The question is why the most sensitive management interfaces in the OT environment were accessible to 75,000 strangers across 194 countries in the first place.
The attackers didn't break in. They logged in. We built the door, we cut the key, and we left both where anyone could find them.
Frequently Asked Questions
What is FortiBleed?
FortiBleed is a large-scale credential exposure incident involving internet-facing FortiGate firewalls. Attackers obtained configuration files containing legacy password hashes and cracked them offline, gaining administrator credentials for thousands of devices.
Why is FortiBleed an architecture problem rather than just a password problem?
FortiBleed shows the danger of placing discoverable, password-gated management interfaces on the public internet. Even a strong password becomes a liability when its stored hash can be copied, cracked, reused, or submitted to an exposed login service.
Why are passwords risky for OT remote access?
Passwords are shared secrets that must exist with both the user and the system being accessed. Either copy can be stolen, phished, reused, leaked, or cracked. In OT environments, compromised credentials can expose systems responsible for physical operations and critical infrastructure.
Would stronger or longer passwords have prevented FortiBleed?
Longer passwords may take more time to crack, but they do not eliminate the underlying architectural weakness. The management interface remains discoverable, and the system still stores information that can be used to verify or attack the password.
How does network cloaking protect OT management interfaces?
Network cloaking makes OT systems and management services invisible to unauthorized users. The asset does not expose a login page, open port, or responding service until the user and device have been authenticated and authorized.
What does “identity before connectivity” mean?
Identity before connectivity means that a user must prove who they are before a network connection to the protected asset is created. Traditional systems establish connectivity first and then ask for credentials, leaving the service visible and available for scanning or attack.
Can network cloaking make stolen credentials useless?
Network cloaking can significantly reduce the value of stolen credentials because an attacker cannot connect to a service they cannot discover or reach. Access also requires an authorized identity, approved device, and applicable access policy—not merely a username and password.
Why is FortiBleed especially concerning for OT networks?
An exposed OT firewall may protect substations, plants, pumping stations, water systems, or other physical operations. Unauthorized access can create safety risks, operational disruption, production losses, and downtime in environments where immediate patching or recovery may not be possible.
How do passwordless MFA and network cloaking work together?
Network cloaking removes the exposed attack surface, while passwordless, phishing-resistant MFA verifies authorized users without relying on reusable passwords. Together, they reduce reconnaissance, credential theft, phishing, brute-force attacks, and unauthorized remote access.
Is rotating passwords enough after a credential exposure?
Password rotation is an important immediate response, but it does not solve the long-term problem. Organizations should also remove direct internet exposure, eliminate password-dependent access where possible, cloak management interfaces, and enforce identity-based Zero Trust access.
How to Protect OT Management Interfaces from FortiBleed-Style Attacks
1. Identify exposed OT access points
Inventory firewalls, VPNs, remote desktop services, web administration panels, and other management interfaces connected to the OT environment. Determine which services are visible or reachable from the public internet.
2. Remove direct internet exposure
Close unnecessary ports and disable public access to management interfaces. Do not rely on a login page and password as the primary barrier protecting critical OT systems.
3. Deploy network cloaking
Place OT management interfaces behind a software-defined perimeter or cloaked network overlay. Configure the environment so unauthorized scans receive no response and protected assets remain undiscoverable.
4. Require identity before connectivity
Authenticate and authorize users before creating a network connection. The protected service should remain unavailable until the user, device, and access request satisfy established security policies.
5. Replace passwords with phishing-resistant authentication
Use passwordless MFA, biometrics, device-based credentials, certificates, or FIDO2 security keys. Avoid authentication methods that depend solely on reusable passwords or easily transferred secrets.
6. Apply least-privilege access
Grant each administrator, operator, and third-party contractor access only to the specific systems required for their role. Prevent users from browsing or reaching unrelated OT assets.
7. Segment remote access from critical operations
Create identity-based segments between remote users, management systems, and production assets. Limit lateral movement so a compromised account or device cannot freely move through the OT network.
8. Test whether protected systems are truly invisible
Conduct external scans and unauthorized connection tests. Confirm that OT management interfaces do not expose open ports, login pages, banners, device details, or other reconnaissance data.
9. Revoke access immediately when risk changes
Establish processes for rapidly disabling users, devices, contractors, or policies when access is no longer required or suspicious activity is detected.
10. Monitor and regularly validate the architecture
Review authentication events, access policies, configurations, and attempted connections. Regularly confirm that new deployments or configuration changes have not restored direct internet exposure.
REvil’s Kaseya attack showed how trusted tools can become attack paths. BlastWave explains why Zero Trust and network cloaking protect OT environments worldwide.
Explore the complete analysis of 23 OT attacks that defeated firewalls, VPNs, and air gaps.
.svg)
.svg)
.jpg)