A month ago, FortiBleed was a credential-harvesting story: leaked FortiGate passwords, a sniffer tool abusing a built-in diagnostic command, tens of thousands of exposed logins. Now SOCRadar says it has traced that same campaign’s infrastructure directly into the negotiation panels of two active ransomware operations — the same operator, logged into both, handling live extortion chats. If that holds up, FortiBleed isn’t a credential leak anymore. It’s a documented supply chain from firewall compromise to encrypted network. The catch is that “if it holds up” is doing real work in that sentence, and this piece exists to spell out exactly how much weight the evidence currently carries.

TL;DR

  • SOCRadar reports that its FortiBleed credential campaign infrastructure was used to scan roughly 430,000 FortiGate devices worldwide, with the attack chain fully completed against 354 organizations and 12 confirmed ransomware deployments.
  • The attribution to INC Ransom and Lynx ransomware rests on three findings: a shared operator logged into both groups’ negotiation panels, victim overlap between FortiBleed infrastructure and an INC-linked open directory, and the confirmed deployments themselves.
  • This is currently a single-vendor claim. No CVE has been assigned to FortiBleed, and as of this writing there is no independent confirmation from CISA, Fortinet, or a competing threat intelligence firm of the specific INC Ransom/Lynx linkage — treat it as SOCRadar’s assessment, not an established fact.
  • Separately confirmed by other researchers (Unit 42, among others): Lynx is itself a 2024 rebrand of INC Ransomware, sharing roughly 90% of its codebase — so finding “one operator working both panels” is consistent with prior public research, even though it doesn’t independently verify SOCRadar’s FortiBleed-specific evidence.
  • Fortinet’s own position, stated in its PSIRT analysis of the underlying credential campaign, is that this is not a new FortiGate vulnerability — it’s credential reuse, weak passwords, and brute force against exposed management interfaces, the same root cause we covered in our original FortiBleed post.

Why This Matters to You

If your organization runs a FortiGate anywhere on its perimeter, this report changes the risk calculus even if you can’t independently verify every number in it. A credential leak is a bad day. A credential leak that a threat intelligence vendor says is feeding two active ransomware operations is a different kind of bad day, because it reframes “reset the password” from a hygiene task into a race against an attacker who may already be selecting your organization as the next target. Whether or not the specific INC Ransom/Lynx attribution survives scrutiny, the underlying exposure — internet-facing FortiGate credentials harvested at scale — is not in dispute, and that’s the part you need to act on regardless of how the attribution question resolves.

Table of Contents

What FortiBleed Actually Is

Despite the name’s echo of “Heartbleed,” FortiBleed is not a CVE. There is no assigned vulnerability number, and no Fortinet advisory ties it to a specific software flaw in FortiOS. Fortinet’s own PSIRT analysis of the underlying campaign — the one we covered when it first broke in June 2026 — states plainly that the initial access does not rely on a new FortiGate vulnerability. Instead, the company’s assessment points to credential reuse from previous, unrelated incidents and brute-force activity against accounts protected by nothing more than a single weak password, on management interfaces and SSL-VPN portals that should never have been internet-facing in the first place.

Where the technical story does have a distinct signature is what happens after that initial access. SOCRadar’s researchers describe a custom Go-language tool, tracked as FortigateSniffer, deployed onto compromised FortiGate appliances. The tool abuses FortiOS’s built-in diagnose sniffer packet command — a legitimate diagnostic feature meant for network troubleshooting — to passively capture authentication traffic crossing the firewall across roughly two dozen protocols, then extracts credentials, password hashes, session tickets, and cookies from that captured traffic. This is the mechanism that turns “we harvested some FortiGate logins” into “we’re harvesting RADIUS, NTLM, and Kerberos material from every internal system that authenticates through this box” — a compromised perimeter firewall repurposed as a passive credential-collection point for the internal network it was supposed to protect.

A historic FortiOS SSL-VPN flaw, CVE-2018-13379 (unauthenticated path traversal, still listed in CISA’s Known Exploited Vulnerabilities catalog), remains relevant background context because it illustrates how old, unpatched FortiOS instances continue to circulate exploitable weaknesses years after disclosure — but Fortinet has not tied that specific CVE, or any other, to the FortiBleed credential campaign itself. The separate detail worth flagging: some reporting on this latest SOCRadar update mentions a suspected zero-day in Nextcloud used for post-compromise lateral infrastructure access, but as of this writing no advisory or CVE number has been assigned to that finding either — it describes how attackers moved around after gaining a foothold, not how they got onto the FortiGate devices in the first place.

The Funnel: From 430,000 Targets to 354 Breaches

The “430,000” figure is the number that will get quoted the most, so it’s worth being precise about what it measures. According to SOCRadar, that number represents FortiGate devices targeted by the campaign’s scanning infrastructure worldwide — the addressable surface the operators were working against, not a count of confirmed breaches. The actual attack chain narrows sharply at each subsequent stage:

  • ~430,000 FortiGate devices targeted by scanning infrastructure globally.
  • Roughly 11,000–19,000 devices where SOCRadar identified sniffer or credential-harvesting activity (reporting varies on the exact figure as the sniffer’s footprint was reduced following vendor and customer notifications).
  • 409 targets where SOCRadar confirmed admin-level access was achieved.
  • 354 organizations where the full attack chain completed — VPN access, domain controller reach, and domain admin privileges.
  • 12 confirmed ransomware deployments stemming directly from FortiBleed-derived access, with hundreds of endpoints encrypted across the affected organizations.

That funnel matters because headline numbers in security reporting routinely get flattened into “430,000 organizations hit by ransomware,” which is not what SOCRadar is claiming. The earlier, separately reported credential figures from the original FortiBleed disclosure — 86,644 working credential entries per SOCRadar’s initial report, corroborated independently in scale (not in exact count) by Hudson Rock and Huntress researchers — describe the harvested-credential stage, one step before the admin-access and ransomware stages described here. Keep the stages separate: targeted, scanned, admin-access-confirmed, fully-compromised, and ransomware-deployed are five different numbers, not one.

The INC Ransom and Lynx Connection

SOCRadar’s attribution of FortiBleed-derived access to INC Ransom and Lynx ransomware rests on three specific findings, reported by the firm and picked up by outlets including BleepingComputer, SecurityWeek, The Hacker News, and Cybersecurity Dive:

  1. A shared operator across ransomware negotiation panels. SOCRadar says it identified a server tied to FortiBleed’s own infrastructure from which an operator was logged into the negotiation panels of both INC Ransom and Lynx simultaneously, actively handling ransom demands — meaning whoever ran (or had access to) the credential-harvesting operation also had working access to both groups’ victim-negotiation backends.
  2. Victim overlap. Comparing target and victim data recovered from FortiBleed’s infrastructure against a separately discovered INC-linked open directory, SOCRadar’s Threat Research Unit (STRU) found matching organizations across both datasets — the same victims appearing on both the credential-harvesting side and the ransomware-negotiation side.
  3. Confirmed deployments. STRU reports at least 12 ransomware deployments traced directly to FortiBleed-derived access, with an internal tracking document recovered during the investigation describing a structured operation of roughly 20 people, split between primary operators handling high-impact intrusions and junior operators and support staff handling reconnaissance and scanning.

Taken together, these findings describe a plausible and specific operational link — not just “these groups exist in the same criminal ecosystem,” but “the same infrastructure and, in at least one case, the same person touched both the credential theft and the ransom negotiation.” That’s a meaningfully stronger claim than typical loose ransomware attribution, and it’s worth taking seriously on its merits.

INC Ransom and Lynx: One Operation Wearing Two Names

Context that predates FortiBleed by roughly two years makes SOCRadar’s “shared operator” finding less surprising than it might first appear. INC Ransom emerged in mid-2023; its source code was reportedly sold on the RAMP cybercrime forum for around $300,000 in May 2024. Shortly after, in October 2024, Lynx ransomware appeared — and researchers at Unit 42 (Palo Alto Networks), among others, subsequently assessed Lynx as a direct rebrand of INC Ransomware, citing roughly 90% code similarity between the two families’ encryptors, alongside overlapping ransom-note structure and leak-site infrastructure patterns.

That means “INC Ransom” and “Lynx” are best understood not as two independent gangs that happen to both benefit from the same leaked FortiGate credentials, but as largely the same operation running under two brand names — likely for the operational flexibility of maintaining a fresh leak-site identity while retaining the tooling, affiliates, and business relationships built under the earlier name. This context doesn’t verify SOCRadar’s FortiBleed-specific evidence, but it does mean the “one operator working both negotiation panels” finding fits a pattern independently documented well before this report, rather than describing an implausible coincidence.

Confirmed vs. Claimed: Reading This Report Correctly

Here is the distinction this article exists to draw clearly: the underlying FortiGate credential exposure is confirmed by Fortinet itself — the company has acknowledged the campaign in its own PSIRT analysis, confirmed it identified potentially compromised systems, and is contacting affected customers. That part of the story is not in dispute.

The specific attribution to INC Ransom and Lynx, however, is currently a single-vendor claim from SOCRadar. As of this writing:

  • No CVE or vendor advisory formally connects FortiBleed to either ransomware operation.
  • CISA’s alerts on the underlying Fortinet credential exposure address the exposure itself, not the ransomware attribution.
  • No competing threat intelligence firm, law enforcement statement, or the ransomware groups themselves have corroborated the specific claims — the shared negotiation-panel access, the victim-overlap analysis, or the 12-deployment count.
  • Every piece of press coverage we reviewed — BleepingComputer, SecurityWeek, Cybersecurity Dive, The Hacker News — attributes these findings explicitly to SOCRadar (“SOCRadar says,” “according to SOCRadar,” “SOCRadar told BleepingComputer”), with no independent verification presented.

None of this means the claim is wrong. SOCRadar’s evidence — shared infrastructure access, matched victim data, confirmed deployment counts — is more specific and falsifiable than typical loose attribution, and the firm has a track record on the underlying FortiBleed credential story that Fortinet itself has since corroborated in broad strokes. But “more credible than average unverified claim” and “independently confirmed” are different confidence levels, and this report currently sits at the former. Treat it accordingly: plan your response around the confirmed exposure, and treat the ransomware-pipeline claim as a serious, specific, but still single-source data point that should sharpen your urgency without being restated as settled fact in your own incident reports.

MITRE ATT&CK Mapping

TacticTechniqueID
Initial AccessValid AccountsT1078
Credential AccessBrute ForceT1110
Credential AccessNetwork SniffingT1040
StealthImpair DefensesT1562
ImpactData Encrypted for ImpactT1486

What You Can Do Today

  1. Treat any FortiGate exposed to the internet as a potential incident, not a patch item, right now. Given SOCRadar’s report of a live pipeline into ransomware deployment, the cost of assuming “we’re probably fine” has gone up regardless of whether the specific attribution holds.
  2. Rotate every credential the appliance can authenticate — not just the admin password. Local administrator accounts, SSL-VPN credentials, API tokens, IPsec pre-shared keys, and any AD/LDAP service account integrated with the firewall all need resetting, because the sniffer-based collection described in the underlying campaign specifically targets traffic crossing the device, not just stored passwords.
  3. Remove administrative interfaces and SSL-VPN portals from public internet exposure wherever operationally possible. Where remote administration is unavoidable, restrict it with trusted-host policies or a local-in policy, and require MFA on every externally reachable authentication path.
  4. Hunt for the specific signal that separates a credential leak from a full compromise: unexpected administrator CLI activity or diagnostic packet captures you didn’t initiate. The diagnose sniffer packet abuse described in this campaign is a legitimate built-in command being misused — log and alert on its use outside of scheduled troubleshooting windows.
  5. Correlate FortiGate authentication logs against your ransomware and dark-web monitoring feeds, not just your SIEM. If SOCRadar’s victim-overlap methodology is directionally correct, organizations with exposed FortiGate credentials may already be enumerated as targets before any ransomware note appears.
  6. Do not restate SOCRadar’s INC Ransom/Lynx attribution as confirmed fact in your own internal reporting or customer communications. Cite it as “reported by SOCRadar, not independently corroborated as of [date]” — the distinction protects your organization’s credibility if the attribution is later revised, and it’s the accurate characterization regardless.
  7. Revisit your edge-device inventory now, before the next report lands. Record every internet-facing Fortinet appliance, its firmware version, authentication method, and log destination — the organizations that responded fastest to the original FortiBleed disclosure are the ones best positioned to rule themselves out of this newer ransomware-pipeline claim with actual log evidence, rather than hoping it doesn’t apply to them.

Sources