Trackr.Live The landing site for Trackr Services
§ AC

FortiBleed Has No Single Patch — It’s Credential Debt, Not a CVE. Your Edge Is an Identity Perimeter Now

By AutoCypher ·

Somewhere in your CMDB there is a FortiGate that has been on the internet since 2021, running SSL VPN or exposed admin access with local password auth and no MFA, last touched when someone bumped the firmware and walked away. For local administrator accounts, one overlooked post-upgrade step matters: until each admin successfully logs in after upgrading to FortiOS 7.2.11, 7.4.8, or 7.6.1, that admin credential can remain stored as legacy SHA-256 rather than PBKDF2 — and unless the downgrade/weaker-encryption lockout setting is enabled, the old SHA-256 material can linger in hidden downgrade-support storage even after conversion. Legacy SHA-256 is materially easier to crack offline on GPU infrastructure than PBKDF2. FortiBleed is the bill for thousands of devices exactly like that one, and the thing that makes it disorienting for a security team is that there is no single product patch to chase. No CVE assigned to FortiBleed. No advisory. No “fixed in 7.4.x.” The patch-and-move-on reflex has nothing to grab.

That’s the whole story, and it’s worth sitting with before reaching for a remediation checklist. FortiBleed is not a breach of Fortinet. It’s the predictable compounding of credential debt: a curated corpus of FortiGate credentials assembled from older incidents, enriched with infostealer logs, sprayed against every reachable device, with the harder targets cracked offline. The output is a database of confirmed, working logins. The reporting clustered around June 17, 2026, after researcher Volodymyr “Bob” Diachenko found an exposed server holding the harvested dataset, Kevin Beaumont independently sized the affected fleet, and Hudson Rock — credited with the name — analyzed the data. SOCRadar and Arctic Wolf followed with defender-facing writeups.

The numbers, and which one you’re allowed to quote

Get the figures straight, because the dramatic version and the defensible version are different numbers and people will conflate them in your incident channel.

Per Hudson Rock’s analysis, the dataset covers 73,932 unique firewall URLs across 194 countries, touching roughly 21,632 corporate domains. The attack volume Diachenko reported is staggering on its own: about 1.16 billion credential attempts against 320,777 FortiGate targets, and the same operation also threw an estimated 2.1 billion attempts at 163,650 Microsoft SQL Server systems. So this wasn’t a Fortinet-only crew; FortiGate was one front of a broad credential-spraying operation.

The number to handle carefully is “working credentials.” SOCRadar puts confirmed working logins at around 30,791 devices. The widely-quoted ~75,000 figure is Beaumont/Hudson Rock’s estimate of the affected fleet — described as roughly half of all internet-exposed FortiGates — not 75,000 verified passwords. If someone in your bridge says “75,000 confirmed creds,” correct them. Tens of thousands of confirmed working logins, about 30,000 verified, with the affected device estimate reaching ~75,000. The gap between those two numbers is itself information.

Corporate names are circulating — Samsung, Sony, Oracle, Mercedes-Benz, Foxconn, Comcast and others appear in media coverage of the domain list. Those are names in an exposed dataset per reporting, not confirmed breaches that those companies have acknowledged. Treat them accordingly, especially if one of them is your customer or your parent org.

How it actually worked, at altitude

The mechanism matters because it tells you where to look. Three things stacked.

The credential corpus appears to draw from older Fortinet-related exposures and exported device configurations, and may have been enriched by other credential sources such as infostealer logs — but the exact origin of the full dataset remains unclear, and reporting hasn’t tied it to any single CVE or prior leak. Beaumont noted the affected IPs differ from the 2025 Belsen Group leak, pointing to a newer, larger collection. The infostealer-to-edge angle is still the reusable lesson worth sitting with: a browser-stored VPN credential lifted off some developer’s malware-infected laptop becomes a firewall admin login, and that pipeline is the part most teams underweight, because the laptop and the firewall live in different parts of the org chart and usually in different parts of the SIEM.

Then the spray: test everything against every reachable device, log every success.

For the targets that didn’t fall to a known password, the group intercepted SSL VPN authentication hashes and cracked them offline on a 45-GPU cluster orchestrated with Hashtopolis. This is where the FortiOS-specific hygiene gap turns into recovered plaintext. Legacy SHA-256 password storage persisted on a lot of devices after firmware upgrades, because the stronger PBKDF2 hashing (which Fortinet made the default for administrator accounts in FortiOS 7.2.11, 7.4.8, and 7.6.1) only takes effect once an admin actually logs in again post-upgrade. Upgrade the box, never re-auth, and you keep the weaker hash indefinitely. Weak hash plus GPUs equals plaintext. That is a configuration and lifecycle problem, not a code flaw, and it’s why “force a post-upgrade admin login” is a real remediation step and not busywork.

Post-access, the reporting describes lateral movement into Active Directory once a VPN or admin foothold existed. The pivot isn’t magic: the box terminates into internal segments, and its config holds the LDAP and RADIUS bind credentials it uses to authenticate users against the domain — so a pulled config or a live tunnel is a step onto the inside, not just a login. The firewall is the front door, not the prize.

One guardrail: keep FortiBleed mentally separate from the patchable Fortinet bugs making news the same week — the recently targeted FortiSandbox vulnerabilities, including the critical command-injection flaw CVE-2026-25089. Those are real, and you should patch them. They compound the risk picture, but they are a different kind of problem. Conflating them leads to the worst outcome here: patching the CVEs, declaring victory, and leaving the credential debt untouched.

Where the detection actually lives

There’s no exploit signature to write a rule against. The adversary is using valid credentials through the front door the way you designed it to be used. So detection moves to authentication telemetry and behavioral baselines, and the first thing you discover is that your most-exposed devices are frequently the ones not shipping logs anywhere.

Start with what you can see. If you’re running the Fortinet TA in Splunk, SSL VPN auth lands in the VPN subtype with action="ssl-login-fail" for failures and tunnel-up for established sessions; admin-plane logins show up under the system subtype with a logdesc like “Admin login failed” and status. The naive spray detection is a count of action="ssl-login-fail" grouped by srcip over a rolling window — say, more than 20 failures from one source in five minutes. Write it, sure. But understand what it does and doesn’t catch before you trust it.

It catches the loud, single-source brute force. It misses the case that actually matters here. The operators already hold valid credentials from the dump, so against your device they don’t fail — they succeed on the first attempt. No failed-login spike. And the spraying itself is distributed across many source IPs, so a per-srcip threshold sees a trickle from each and never trips. Both of your obvious signals are blind to the dangerous path.

The signal that holds up is the successful login that doesn’t fit. A tunnel-up for a user account from an ASN or geography that account has never used. A successful admin login sourced from the public internet at all — which, if your management interface is correctly off the internet, should be a flat zero, making any hit a high-fidelity alert rather than a tuning headache. And on the remediation side, inventory admin accounts still showing legacy SHA-256 / old-password state in configuration backups or through approved administrative checks; if your FortiOS logging exposes a legacy-hash signal at login, treat it as both a detection signal and a to-do list of devices that never got their post-upgrade re-login.

Build the baseline as a per-user lookup of historical source ASNs from your tunnel-up events — 60 to 90 days is enough to capture normal travel and roaming without baking last quarter’s anomalies into the “known good” set — then alert on first-seen ASN per account. Here’s the tuning you’ll do in week one, because everyone does it: the new-ASN rule lights up on roaming sales staff, anyone on mobile carrier NAT (CGNAT pools shuffle ASNs constantly), and your own VPN-over-VPN power users. Carve those out by group, not globally, or you’ll punch a hole big enough to drive the actual intrusion through. The carve-outs are also where identity context earns its keep: correlate the new-ASN hits against HR travel status, device assignment, or your IdP’s own sign-in telemetry so the survivors are anomalies a human will actually chase, not noise the SOC mutes in week two. Expect to drop the alert volume by an order of magnitude between the lab version and the version the SOC will actually keep enabled.

A few things will bite the data quality before the logic does. FortiGate syslog timestamps drift if NTP isn’t solid, so cross-device correlation skews unless you’re anchoring on index time. Geo and ASN enrichment is only as current as your MaxMind feed, and cloud and carrier ranges churn. The biggest gap is coverage: the internet-facing FortiGate that an acquired business unit stood up and never onboarded is precisely the one in this dataset and precisely the one not in your index. You cannot baseline auth you never ingested. Before any of the detection work, run the external view — Shodan-style enumeration of your own exposed FortiGate management and VPN endpoints (RA-5, CA-7). You can’t defend an edge you didn’t know was lit up.

Remediation is rotation and exposure, not a firmware bump

The reflex to resist is rotating “the admin password” and calling it contained. A working login may have already pulled the full config, and a FortiGate config is a credential pinata: local user passwords, IPSec pre-shared keys, API keys, LDAP and RADIUS bind credentials. Rotate the lot (IA-5). For any device whose config ever leaked in 2022 or 2025, or that turns up in this dataset, assume the config walked and treat the device as compromised until you’ve proven otherwise — review for persistence, check for the AD lateral movement. And rotation alone doesn’t evict anyone already inside: a session established with a valid credential before you changed it survives the change, so terminate active SSL VPN and administrative sessions as part of the same step, then verify no authenticated sessions remain under the compromised identities (AC-12). A password reset that leaves a live tunnel up is not containment.

The single highest-leverage control is the boring one. MFA on both the SSL VPN and the admin interface (IA-2(1), IA-2(2)). It defeats credential replay even when the password is valid and already sitting in the dump, which is the entire threat model here. A bare password on an internet-facing SSL VPN in 2026 is a pre-breached control. If you do one thing this quarter, it’s this.

Then shrink the surface. The management interface should not be reachable from the internet at all — restrict it to internal networks or a jump host (SC-7). Get the SSL VPN MFA-gated, disable unused VPN portals (AC-17), and geo or ASN-restrict where your user population allows it. Force the post-upgrade admin re-login so password storage migrates off SHA-256 to PBKDF2 (CM-6) — and turn on login-lockout-upon-weaker-encryption (7.2.x/7.4.x) so the legacy SHA-256 hash is actually purged once it converts, instead of lingering as a crackable fallback. Add sane account-lockout thresholds (AC-7) to blunt the spraying that still gets through.

And treat the inherited-exposure piece as an ongoing control, not a one-time cleanup (the SR family fits better here than people expect). Infostealer-sourced credentials and old leaked configs are someone else’s incident becoming your problem. Credential-dump monitoring — are our domains and our edge devices showing up in these corpora? — is a real detective control, and FortiBleed is the case study for why.

The patch-centric muscle memory is the trap. There is no version number that fixes this, because nothing here is broken in the code. The edge VPN became an identity boundary years ago; FortiBleed is just the invoice arriving all at once. Rotate everything in the config, put MFA on every internet-facing auth surface, get management off the public internet, and start watching the successful logins instead of the failed ones. That’s the work. None of it is a download.

Sources