FortiBleed Credential Theft Campaign Linked to INC and Lynx Ransomware

Security researchers at SOCRadar have linked the FortiBleed credential-theft campaign to the INC Ransom and Lynx ransomware operations — the first confirmed case connecting mass FortiGate credential theft to actual ransomware deployment. Despite the name, FortiBleed is not a software vulnerability: there is no CVE and no patch. It runs on stolen and cracked passwords against internet-exposed FortiGate devices that were never properly secured.

Last updated August 4, 2026: corrected the root-cause description (credential compromise, not a CVE-based exploit), and added the campaign's harvested-credential total, timeline, and Fortinet's own mitigation guidance, which were missing from the original report.

What Happened: FortiBleed Linked to Active Ransomware

SOCRadar published research on July 2, 2026 linking FortiBleed to the INC Ransom and Lynx ransomware groups. Researchers identified a Windows server belonging to FortiBleed's infrastructure with access to both groups' ransomware negotiation panels, and found victim data harvested during FortiBleed overlapping with organizations later listed on INC's leak site. Multiple outlets reporting on the connection describe at least 12 ransomware deployments, encrypting hundreds of endpoints, as traceable to this access.

Separately from the ransomware link, attackers deployed a traffic-sniffing tool on roughly 19,000 of the exposed devices to harvest additional credentials in transit; victim-notification efforts have since reduced the number of actively compromised devices to around 11,000.

How FortiBleed Actually Works

Earlier coverage of FortiBleed, including CapisTech's own original report, described it as exploiting "vulnerabilities" in Fortinet devices. That framing was imprecise. Per Bitdefender's technical advisory, FortiBleed does not exploit a software flaw. It works in stages: attackers scan for internet-exposed FortiGate management interfaces and SSL VPN endpoints, extract configuration files containing password hashes, and crack the older, weaker SHA-256 hashes offline — a technique that doesn't work against devices already upgraded to FortiOS's newer PBKDF2 hashing. With valid, cracked credentials in hand, attackers log in normally, no exploit code required, and on some devices use FortiOS's own legitimate diagnose sniffer packet diagnostic command to turn a compromised firewall into a credential-harvesting listening post for traffic passing through it.

The campaign has been running since at least February 2026 and, per multiple outlets tracking it, had harvested more than 110 million credentials across 24 network protocols by the time SOCRadar published the ransomware connection in July.

Why the Hashing Algorithm Change Matters

The shift from SHA-256 to PBKDF2 that Fortinet's newer FortiOS versions use is a meaningful, not cosmetic, security improvement. SHA-256 is a fast general-purpose hash function, which is exactly the property that makes it weak for password storage: an attacker with password hashes and enough compute can test billions of guesses per second against it. PBKDF2 is a "key derivation function" built specifically to be slow, deliberately running the underlying hash thousands of times per attempt, which shrinks the number of guesses an attacker can test in the same amount of time by orders of magnitude. That's why devices already running FortiOS's newer hashing weren't vulnerable to the offline-cracking stage of FortiBleed even if their configuration files were exposed the same way: the math of testing password guesses against PBKDF2 output is simply too slow to be practical at the scale FortiBleed's operators were working at.

The INC Ransom and Lynx groups both operate on a ransomware-as-a-service model, in which developers license or license-share their encryption tooling to affiliates who handle the actual intrusion and negotiation, then split the ransom proceeds. That structure is part of why a credential-harvesting campaign like FortiBleed and a ransomware deployment operation can be run by loosely connected groups rather than a single organized team, and it's also why SOCRadar's discovery, shared server infrastructure used for both credential harvesting and ransomware negotiation, was needed to prove the connection rather than it being obvious from the ransomware attacks alone.

Why the "No Patch" Distinction Matters

Because FortiBleed is a credential and configuration problem rather than a code vulnerability, patching alone does not close it. Fortinet's own advisory (FG-IR-25-647) attributes the exposure to credential reuse from prior incidents and weak password hygiene, and recommends terminating all existing admin and VPN sessions, resetting every credential, enforcing phishing-resistant MFA, upgrading to FortiOS 7.4, 7.6, or 8.0 for stronger PBKDF2 hashing, and restricting external access to management interfaces. Organizations that only apply software updates without rotating credentials and enforcing MFA remain exposed.

What Happens Next

Fortinet's mitigation guidance is available now; there is no separate patch to wait for. Ransomware groups will keep using FortiBleed-derived credentials for initial access as long as they remain valid and unrotated, which is why credential rotation, not just software updates, is the step organizations most often skip.

Final Takeaway

FortiBleed shows how a purely credential-based compromise, with no code exploit involved, can still cascade into active ransomware deployment. Because there's no patch to apply, the defenses that matter are the ones organizations most often deprioritize: credential rotation, MFA, and moving off legacy password hashing, none of which show up as a single line item on a vulnerability scanner the way a missing software patch does.

Key Points

The FortiBleed Attack Chain

The chain runs: exposed management interface → stolen or cracked credentials (not a code exploit) → valid administrator login → in some cases, abuse of a legitimate diagnostic command to sniff further credentials → sale or reuse of that access by ransomware affiliates. Every stage offers a chance to break the chain, but the entry point is specifically weak credential hygiene, which is why software patching alone doesn't close it.

Fortinet's guidance addresses the credential side directly: reset every credential that may have touched an affected device, terminate existing sessions so old credentials can't still be used, and move to FortiOS versions with PBKDF2 hashing so future configuration exposure can't be cracked as easily offline.

FAQs