FortiBleed: How a Russian-Speaking Threat Group Quietly Compromised 75,000 Fortinet Firewalls Worldwide

There’s a detail in the FortiBleed story that nobody’s talking about enough: the attackers left a directory open.

Not intentionally. They forgot. And when security researcher Volodymyr “Bob” Diachenko found it, he didn’t just find stolen credentials. He found cron jobs, bash histories, scripts, connection strings, and telemetry from an active operation – a live window into the backend of what may be the largest single Fortinet credential theft campaign ever documented.

The number you’ll see in headlines is 73,932. That’s how many unique Fortinet firewall URLs sit in the dataset Hudson Rock has analyzed. It spans 194 countries, touches 21,632 unique domains, and includes some of the largest enterprises on the planet: Samsung, Oracle, Foxconn, Siemens, Comcast, PwC, Accenture, Lenovo, Chevron, AT&T, Mercedes-Benz, Toyota. Governments. NATO-adjacent defense contractors. Critical infrastructure operators. Healthcare providers. Telcos.

Researchers are calling it FortiBleed.

Here’s what actually happened, how the machine worked, and what you need to do if you’re running a FortiGate

What Diachenko actually found

Diachenko didn’t stumble onto a dark web paste. He found a misconfigured server the operators had left exposed and because they were sloppy with directory indexing, he got a full view of their toolchain.

The exposed artifacts included automated scanning scripts, credential-testing tools, data logs, cron jobs showing the operation’s timing and structure, and bash histories from the operators themselves. This is how he was able to reconstruct the campaign’s methodology with such specificity. These weren’t educated guesses, they were the attackers’ own operational records.

Kevin Beaumont, who reviewed portions of the data independently, confirmed the core finding: the credentials are real. Multiple organizations whose credentials appeared in the dataset were verified to still be using them on devices that were still online and internet-accessible.

“The data is legit,” Beaumont said. “It is around 75k devices. Almost all are still online, and Fortinet devices. It appears to be recent data.”

How the operation actually works

This isn’t credential stuffing in any conventional sense. The FortiBleed campaign is a multi-phase, self-reinforcing loop that uses compromised devices to generate new compromised devices. Understanding the full chain matters if you’re trying to defend against it.

Reconnaissance and initial scanning

The group starts with internet-wide scans targeting exposed Fortinet appliances, primarily FortiGate SSL VPN endpoints and administrative interfaces. Based on data from Shodan, Beaumont estimated the dataset contains approximately half of all internet-accessible Fortinet firewalls. Most of them have their management interfaces directly exposed to the internet.

That’s your attack surface.

Credential sourcing

Here’s where it gets interesting. The attackers aren’t generating random wordlists. According to Diachenko’s reconstruction of the operation, they’re pulling from two distinct credential pools:

Historical Fortinet leaks. Fortinet has had multiple significant credential exposures over the past several years. In 2021, a threat actor leaked credentials for nearly 500,000 FortiGate VPN accounts, scraped from devices running vulnerable versions of FortiOS. The Belsen Group subsequently published another batch from a 2022 zero-day. These leaks were widely circulated. The FortiBleed operators built curated lists specifically from Fortinet-sourced credential dumps – meaning they weren’t testing random internet passwords, they were testing passwords that had already worked on Fortinet devices before.

Infostealer databases. The second pool is credentials harvested through endpoint-level infostealer malware. This is the part that makes password complexity completely irrelevant as a control. When a keylogger or credential-dumping infostealer captures a password on an endpoint, it captures it before any encryption is applied. A 25-character random string with numbers, symbols, and mixed case looks exactly like “password123” in a plaintext infostealer log. The Hudson Rock analysis specifically flagged this: a significant volume of highly complex credentials in the dataset were compromised because they existed verbatim in previously harvested infostealer databases, not because they were cracked.

This is why the discovery of complex passwords in the FortiBleed dataset rattled people. They weren’t cracked. They were already known.

Credential validation at scale

The operation ran an estimated 1.16 billion authentication attempts against more than 320,000 FortiGate targets. They also ran 2.1 billion brute-force attempts against over 163,000 Microsoft SQL Server systems in parallel, which suggests this is a broader initial-access operation, not a Fortinet-specific campaign.

The credential testing is automated and distributed. Successful logins get flagged and written to a verified database with metadata: organization name, industry sector, estimated revenue, employee count, country, and the specific interface the credential works against (admin panel vs SSL VPN endpoint). That last part is important. The dataset isn’t just a credential dump, it’s an enriched access inventory assembled for operational targeting.

SSL VPN hash interception and offline cracking

For targets where credential stuffing didn’t immediately yield plaintext access, the group used a more technically intensive approach: intercepting SSL VPN authentication hashes.

FortiGate SSL VPN uses challenge-response authentication in certain configurations, where the client’s password hash is transmitted as part of the handshake. By positioning themselves to capture these hashes – either through a man-in-the-middle position or via access to a device they’d already compromised on the same network path. The attackers extracted hashed credentials and cracked them offline.

The cracking infrastructure is a 45-GPU cluster managed through Hashtopolis, an open-source distributed hash-cracking framework that coordinates workloads across multiple machines. At that GPU count with modern hardware, this cluster can push through billions of hash candidates per second against common hashing algorithms.

It’s worth noting the specific hashing angle that Beaumont flagged in his analysis: Fortinet hardened admin credential storage in early 2025, migrating to PBKDF2 for password hashing. But this migration only protected accounts where the administrator actively logged in after applying the relevant firmware update. Any device that was patched but whose admin accounts never re-authenticated stayed on the older SHA-256 with Salt format. That’s a much weaker target for offline cracking, and it’s likely a meaningful portion of the 75,000 verified devices.

Post-compromise sniffer deployment and the self-feeding loop

This is where FortiBleed becomes distinctly more dangerous than a simple credential theft campaign.

Once a FortiGate device is compromised, the attackers don’t just extract the configuration and move on. They deploy network sniffers that passively monitor all traffic transiting the firewall. Because the device sits on the network perimeter, it sees everything crossing into and out of the organization: internal authentication traffic, VPN user credentials, LDAP and RADIUS binds, application logins, service account calls.

All of that feeds back into the credential pool.

A compromised Fortinet box becomes a live credential harvester for every organization on its network segment. The more devices they compromise, the more traffic they can observe, the more credentials they collect, the more devices they can compromise. The loop is self-sustaining.

SOCRadar’s analysis described the same mechanism: the FortiBleed operation evolved from initial credential stuffing into a harvesting network where compromised perimeter devices serve as collection points for future attacks.

The scale and what it means

Hudson Rock’s breakdown of the dataset shows the highest concentration of affected devices in India, the United States, Taiwan, Mexico, Turkey, Thailand, Colombia, Malaysia, Chile, and the UAE.

By industry: telecommunications was the most affected sector, followed by IT services, financial services, government organizations, healthcare providers, educational institutions, and manufacturing.

Diachenko confirmed full network compromises meaning the attackers established persistence and conducted lateral movement beyond the initial Fortinet device at organizations in Japan, Taiwan, Vietnam, Iraq, and Turkey. The most serious confirmed case is a Turkish NATO defense contractor. The attackers got in, moved through the internal network, and exfiltrated classified defense documents.

Beaumont made one comparison that’s worth sitting with: the prior Belsen Group leak covered roughly 15,000 devices and came from a 2022 zero-day exploit. FortiBleed covers 75,000 devices, the affected IPs don’t overlap with the Belsen dataset, and many of the compromised devices are running relatively recent FortiOS versions. This isn’t old vulnerability inventory being revisited. It’s a separate, more recent, and larger collection.

Why the configuration data is the tell

One thing nobody has fully explained yet is how the attackers obtained Fortinet configuration files in the first place and that’s actually the most important open question in this story.

Beaumont’s analysis flagged a specific detail: the dataset contains email addresses associated with Fortinet accounts. That information is not exposed through a standard SSL VPN login interface. It’s only accessible if you have the device configuration. This strongly suggests the attackers exported Fortinet configs, not just captured login credentials.

Configuration files for FortiGate devices are encrypted, but the encryption key is derived from the device’s serial number which is often visible on the management interface login page. With the config file and the serial number, decryption is straightforward.

How they got the configs is still unknown. The possibilities include exploitation of previously disclosed vulnerabilities (there are several FortiOS RCE and authentication bypass CVEs that have been actively weaponized over the past few years), an undisclosed vulnerability, or administrative access obtained through earlier credential stuffing that then enabled config export.

The SOCRadar analysis noted separately that two FortiClient EMS vulnerabilities, CVE-2026-21643 and CVE-2026-35616, were under active exploitation during the same period. CVE-2026-35616 specifically allows unauthenticated attackers to bypass API authentication in FortiClient EMS versions 7.4.5 and 7.4.6 which could potentially be used to push credential-stealing functionality to managed endpoints. Whether that’s connected to FortiBleed isn’t confirmed, but the timing is notable.

Fortinet had not responded to BleepingComputer’s request for comment at the time of publication.

The dark web context

Beaumont noted that the organization of the dataset sorted by company type, revenue, and headcount is a recognizable fingerprint of eCrime syndicates packaging initial access for sale. The FortiBleed database isn’t just a record of successful compromises. It’s an inventory formatted for buyers who want to filter targets by industry and deal size.

This kind of structured access brokerage has become the standard operating model for ransomware-affiliated initial access brokers. They don’t deploy ransomware themselves – they build verified access databases and sell individual entries or bulk packages to ransomware affiliates and espionage operators.

The classification data (industry, revenue, employee count) in the FortiBleed dataset is precisely what a ransomware affiliate needs to price a ransom demand or decide whether a target is worth deploying to.

What you need to do now

If you run Fortinet and if you’re reading this, you probably know whether you do. Here’s what matters.

Rotate everything. Every VPN credential. Every admin account password. Every service account that authenticates against or through the FortiGate. Don’t filter this by age or complexity. Complexity didn’t protect the 25-character passwords in this dataset. Rotation is the only relevant action.

Enable MFA on every external gateway. MFA neutralizes a stolen plaintext credential completely. If the attackers have your password but can’t satisfy the second factor, they can’t log in. This is the single most leverage you can get from the least configuration effort.

Restrict management interface access immediately. The fact that a majority of affected devices exposed their FortiGate admin interfaces directly to the internet is not an accident, it’s a prerequisite for this attack. Apply local-in-policies to restrict admin panel access to your internal management IP ranges only:

config firewall local-in-policy
edit 1
set intf "port1"
set srcaddr "trusted_mgmt_ips"
set dstaddr "all"
set action accept
set service "HTTPS" "SSH"
set schedule "always"
next
end

If you’re not managing the device remotely from arbitrary internet IPs, there’s no reason the admin interface should answer to arbitrary internet IPs.

Implement SSL VPN login attempt limits. Three failed attempts before a 5-minute block eliminates most automated credential testing:

config vpn ssl settings
set login-attempt-limit 3
set login-block-time 300
end

For higher-security environments, consider dropping to two attempts.

Require client certificates for SSL VPN. This is the most robust control against credential stuffing on VPN endpoints. A certificate-authenticated SSL VPN doesn’t present a password prompt to unauthenticated clients:

config vpn ssl settings
set client-certificate enable
end

Check for sniffer processes running on your device. If you were compromised and the attackers deployed a passive sniffer, the device may still be transmitting traffic to C2:

diagnose sniffer packet any "host <suspicious_IP>" 4
diagnose vpn ssl debug
execute log filter category 1
execute log display
diagnose sys session list | grep admin

Check the FortiBleed lookup tool. Hudson Rock has a free lookup at hudsonrock.com/fortinet where you can enter your domain to check whether it appears in the dataset.

Audit your firmware and re-authenticate admin accounts. If you applied FortiOS patches in early 2025 that included the PBKDF2 credential hardening, but your admin accounts never logged in after patching, your credentials are still stored in the weaker SHA-256 format. Force re-authentication of all admin accounts against updated firmware.

Review LDAP and RADIUS credential exposure. Fortinet configurations often contain LDAP and RADIUS bind credentials in encrypted form. If attackers extracted your configuration file, those service account credentials are potentially compromised. Rotate them.

The question that doesn’t have an answer yet

Nobody – not Diachenko, not Hudson Rock, not Beaumont, not SOCRadar has identified the original infection vector. How did this group get Fortinet configuration files for 75,000 devices?

The most likely explanations are old credential abuse against management interfaces on pre-hardened devices, exploitation of one or more of the several Fortinet RCE and authentication bypass vulnerabilities that have been publicly disclosed over the past three years, or a previously unknown vulnerability. The third option is the one that keeps incident responders up at night because there’s no patch for it yet and no known indicator of compromise specific to it.

Until Fortinet responds and the forensics are clearer, the honest answer is that the initial vector is unknown.

What’s not unknown: the credentials are real, the compromises are real, the devices are still online, and the database is formatted for operational use. The attackers aren’t done with it.

A note on what FortiBleed actually is

Waseem Ahmed, head of engineering at Secure.com, put it well in his comments to Dark Reading: “There’s no zero-day, no exploit, no actual ‘bleed.’ Despite the name, this isn’t a vulnerability – it’s a pile of credentials leaked in earlier Fortinet breaches, fired back at organizations that never bothered to change them.”

That’s mostly accurate, and the SOCRadar finding supports it: many of the compromised accounts were generic admin accounts, default or built-in Fortinet system accounts, or long-lived accounts whose passwords had never been rotated after prior breaches.

But the “no zero-day” framing undersells what actually happened here. The self-reinforcing sniffer loop, the 45-GPU offline cracking cluster, the structured access inventory formatted for dark web sale, the classified document exfiltration from a NATO contractor – this wasn’t opportunistic. Someone built infrastructure to do this at scale, ran it against half the internet-facing Fortinet population, and is now sitting on verified admin access to tens of thousands of corporate and government networks.

The original sin may have been credential reuse and password staleness. But the machine that weaponized that sin was anything but casual.

FAQ