6 Things to Know About the FortiBleed Credential Campaign
Table of contents
A massive credential theft operation has compromised verified login data for approximately 75,000 Fortinet FortiGate firewalls across 194 countries. Many researchers are calling it FortiBleed.
Here is what you need to know as this news story develops.
1. This Is Not a Vulnerability (It Is a Credential Campaign)
FortiBleed has no CVE and there is no patch to apply.
Security researcher Volodymyr “Bob” Diachenko discovered the dataset after finding the attackers’ own server accidentally left open on the internet, complete with tooling, scripts, and logs. Threat intelligence firm Hudson Rock analyzed the data and named the campaign. Independent researcher Kevin Beaumont verified credentials personally across multiple organizations in the dataset and confirmed they were real and active.
The dataset spans 73,932 unique FortiGate firewall URLs, 21,632 corporate domains, and covers roughly half of all internet-facing Fortinet firewalls globally, according to Shodan network data.
The scale is without precedent for a credential-only operation of this kind.
2. The Attackers Built an Industrial-Scale Credential Machine
The operation combines three techniques to harvest verified credentials at volume.
Credential reuse at scale. The group sourced passwords from prior Fortinet breach dumps and infostealer malware logs, software that silently extracts credentials saved in browsers and VPN clients. They then tested those credentials automatically against every reachable FortiGate device, recording every successful login. Approximately 1.16 billion authentication attempts were launched against more than 320,000 FortiGate targets.
SSL VPN hash cracking. For devices where reuse failed, the attackers intercepted SSL VPN authentication hashes during the login handshake and cracked them offline using a dedicated 45-GPU cluster managed through Hashtopolis, an open-source distributed cracking framework.
Parallel MSSQL targeting. Simultaneously, the group ran 2.1 billion brute-force attempts against over 163,000 Microsoft SQL Server systems. This is not a Fortinet-specific operation. It is a broad initial-access campaign using FortiGate devices as a primary entry point.
3. Password Complexity Offered No Protection
One of the most significant findings from FortiBleed is that credential complexity alone provided no defense.
Passwords of 25 or more characters, including symbols, numbers, and mixed case, were found in the dataset in plaintext. They were not cracked. They were already known, pulled verbatim from previously harvested infostealer logs. The Hudson Rock analysis flagged this explicitly: a significant volume of highly complex credentials were compromised not through brute force, but because they already existed in infostealer databases.
This reframes the entire risk calculus. A strong password that has passed through an infostealer infection offers the same protection as a weak one.
Fortinet did migrate to the stronger PBKDF2 hashing algorithm in early 2025, but this only protects accounts whose administrators actively re-authenticated after the firmware update was applied. Any device patched but not re-authenticated remained on the weaker SHA-256 with Salt format, a far easier target for offline cracking.
4. At Least Four Organizations Were Fully Compromised
The campaign did not stop at the firewall.
Once inside, attackers pivoted directly into internal Active Directory environments, the central directory managing all Windows accounts and permissions across an organization. From there, they moved laterally through internal networks. At least four organizations were fully compromised, with confirmed lateral movement across Japan, Taiwan, Vietnam, Iraq, and Turkey.
The most serious confirmed case involves a Turkish NATO defense contractor, from which classified defense documents were reportedly exfiltrated. This raises the operation’s geopolitical significance well beyond financial cybercrime.
The victim list in the broader dataset includes Foxconn, Samsung, Comcast, Siemens, Lenovo, FedEx, Accenture, Oracle, Chevron, AT&T, Mercedes-Benz, and Toyota, among many others. The Register’s full coverage provides additional detail on confirmed victim communications.
5. Fortinet’s Response Does Not Change the Threat for Defenders
Fortinet has characterized FortiBleed as a recycling of data from past incidents combined with brute-force activity, and has stated no new vulnerability exists in its products.
That framing is technically defensible. It does not change the situation for any organization currently in the dataset.
Whether credentials were obtained last week or two years ago is irrelevant if they have not been rotated. A device that remains internet-accessible with unchanged passwords represents an open door, regardless of when those credentials were first obtained. As BleepingComputer reported, a majority of the affected devices had their FortiGate management interfaces directly exposed to the internet at the time of discovery, and most remained online.
The distinction between old data and a current threat dissolves when the keys still work.
6. What Organizations Running Fortinet Devices Should Do Now
Hudson Rock has published a free FortiBleed lookup tool at infostealers.com allowing organizations to check whether their domain appears in the campaign’s database. This should be the first step.
Within 24 hours:
Rotate all VPN and administrative passwords on every FortiGate device in your environment. Do not limit this to devices flagged in the dataset — treat the dataset as incomplete. Enable Multi-Factor Authentication on all Fortinet VPN and management interfaces immediately. Review gateway logs for anomalous authentication events, unfamiliar IP addresses, or unusual login timing.
Within two weeks:
Audit Active Directory for unauthorized accounts, new service accounts, or privilege escalation events within the campaign’s likely activity window. Ensure all admin accounts re-authenticate after firmware updates to trigger the PBKDF2 migration. Search for persistence mechanisms before closing access — rotating credentials without removing an active implant leaves the network exposed.
Structurally:
Build a credential rotation policy that triggers automatically following any public disclosure involving Fortinet products, named or not. Pair this with continuous monitoring of your external attack surface to detect exposed management interfaces before they appear in the next dataset.
For a broader view of how credential exposure connects to your organization’s attack surface, visit our Credential Intelligence page and our Attack Surface Management page.
CybelAngel is actively monitoring the FortiBleed campaign and cross-referencing the disclosed dataset against our own telemetry. We will publish updated findings as the situation develops.
About the author
