If your organization runs a Fortinet firewall, in particular a FortiGate device handling VPN or remote access, this is worth reading closely, even if you don't touch the technical side of your network day to day.
Over the past several weeks, security researchers have pieced together the full picture of a campaign called FortiBleed: a long-running, financially motivated operation that has targeted more than 430,000 internet-facing FortiGate firewalls worldwide, using a custom tool to silently listen in on network traffic passing through compromised devices. The result, so far, is more than 110 million stolen credentials, a confirmed breach at a NATO-aligned defense contractor, and a formal hardening advisory from the U.S. Cybersecurity and Infrastructure Security Agency (CISA).
Unlike the CVE-driven stories we usually cover, FortiBleed isn't a single software flaw with a patch number attached. It's an active, ongoing criminal operation built almost entirely out of legitimate administrative features, weak passwords, and exposed management interfaces. That distinction matters for how you should respond, and we'll walk through why below.
How this came to light
The first public sign of trouble came when security researcher Volodymyr "Bob" Diachenko discovered a server left open on the internet containing what looked like valid Fortinet VPN credentials: usernames, email addresses, and plaintext passwords tied to roughly 74,000 firewall URLs across the globe. The exposed dataset also included each victim organization's industry, revenue, and employee count, details that read less like a leak and more like a target list assembled for future attacks.
CISA responded on June 18, 2026, urging Fortinet customers to terminate active SSL VPN and administrative sessions, reset credentials, and harden their devices. Threat intelligence firm SOCRadar, which had already been tracking related activity, then published a much deeper technical breakdown that traced the operation from that single exposed directory to more than 150 additional attacker-controlled servers. That report, along with independent analysis from ZenoX and CloudSEK, gave defenders their first real look at how the campaign actually works from end to end.
Fortinet has stated that the exposed data reflects previously compromised credentials rather than a new, unpatched vulnerability in its products. SOCRadar's follow-on research, however, shows this is not a static, one-time leak; it is an active, ongoing pipeline that continues to compromise new devices. Both things can be true at once, and organizations should treat the risk accordingly: this isn't about a single patch you can install and move on from.
What is FortiBleed?
FortiBleed is the name researchers gave to a large-scale credential-harvesting campaign targeting FortiGate firewalls and SSL VPN gateways. Analysts assess with reasonable confidence that it is run by a Russian-speaking, financially motivated initial access broker (IAB), a type of criminal actor that specializes in breaking into networks and then selling that access to other groups, including ransomware operators. Tooling comments written in Cyrillic, business-hours operational patterns aligned to Moscow time, and infrastructure analysis all point in the same direction, though attribution in cases like this is rarely absolute.
The campaign has been active since at least February 2026 and, as of late June, was still running: SOCRadar's researchers found the operation actively sniffing traffic on more than 19,000 devices at the time of their report, out of a broader pool of over 80,000 identified targets.
The core tool: FortigateSniffer
The centerpiece of the operation is a Golang-based tool the researchers named FortigateSniffer. Rather than exploiting a new software vulnerability, it abuses a legitimate, built-in FortiOS diagnostic command, diagnose sniffer packet, that administrators normally use to troubleshoot connectivity and authentication problems. Once attackers have administrative access to a device (more on how they get that below), they connect over SSH and use this feature to passively capture live authentication traffic flowing through the firewall.
FortigateSniffer is built to monitor roughly two dozen different protocols, including Kerberos, RADIUS, NTLM, LDAP, RDP, WinRM, SMB, MS-SQL, MySQL, PostgreSQL, SMTP, IMAP, POP3, and Telnet. Because it works by watching traffic rather than installing malware on the device, there is no unusual file to detect and no unfamiliar process running; it is, functionally, a wiretap built entirely out of features Fortinet shipped on purpose.
Notably, the sniffer is only run between roughly 7 a.m. and 6 p.m. Moscow time, a deliberate choice to blend the traffic into normal business-hours activity and avoid drawing attention from anomaly-based monitoring.
From packets to passwords
Captured traffic is reconstructed into standard packet capture (PCAP) files by a component researchers dubbed SNIFTRAN, then run through a Python-based analysis toolkit that pulls out cleartext credentials, password hashes, Kerberos tickets, NTLM material, and other authentication artifacts. Hashed credentials are converted into Hashcat-ready files and cracked using a distributed GPU cluster, orchestrated through the Hashtopolis framework and a Telegram bot that reports cracking progress to a single administrator in real time. Some of that GPU capacity was rented on demand from cloud GPU marketplaces such as Vast.ai; researcher Kevin Beaumont separately found evidence the group also rented capacity from a generative-AI compute provider, running password cracking on enterprise-class GPU clusters normally reserved for AI workloads.
The scale is substantial: SOCRadar counted more than 659 separate credential-harvesting pipelines and over 110 million identified credentials, including roughly 14.8 million RADIUS credentials, 924,000 NTLM hashes, 130,000 Kerberos hashes, and 89 million MySQL authentication tokens.
The full attack chain
Researchers have reconstructed the operation as a five-phase pipeline that is notably methodical for a criminal campaign of this scale.
1. Reconnaissance and target ranking. The attackers use mass internet scanning tools such as Masscan, combined with a custom utility called FortiProbe-fast, to identify FortiGate devices and filter them out of broader scan results. A companion tool, referred to in reporting as GeoSplit, groups discovered devices by country. Targets are then enriched with business data (industry, revenue, employee count) and ranked by potential value before any exploitation effort is spent on them, a level of pre-attack triage that resembles a sales pipeline more than opportunistic hacking.
2. Initial access via credential attacks. With targets ranked, the attackers run credential-stuffing and brute-force attacks against FortiGate administrative panels and SSL-VPN portals, using wordlists built specifically around common FortiGate account-naming conventions. A tool called "forticheck" automates much of this credential-checking work.
3. Deployment of FortigateSniffer. Once administrative SSH access is obtained, FortigateSniffer is installed and begins passively capturing authentication traffic across the two dozen protocols described above.
4. Cracking and lateral movement. Captured hashes are cracked offline using the GPU infrastructure described earlier, and the resulting credentials are used for password spraying, Active Directory enumeration, SMB access, and broader lateral movement inside the victim's network. Analysts also found the attackers using OpenFortiVPN client configurations to pivot through compromised VPN tunnels as though they were legitimate internal users, along with a toolkit built around the Impacket Python library for further internal movement.
5. Data theft and persistence. In the final phase, sensitive files are exfiltrated from network shares (researchers found a file-spider script that walks shares recursively, hunting for embedded passwords in scripts and configuration files), and stolen web session cookies are reused to maintain authenticated access without needing to log in again. In at least one confirmed case, a NATO-aligned defense contractor had its backup data targeted for exfiltration within minutes of its Kerberos hashes being cracked, an indicator of how quickly the pipeline can move from stolen credential to data theft once cracking succeeds.
Researchers also observed the attackers creating their own administrator accounts on compromised devices, using names designed to blend in with legitimate Fortinet support activity, such as forticloud-sync, forticloud-tech, support_fortinet, and Technical_support. Throughout the operation, the group also appears to have used CyberStrike, a legitimate open-source, AI-assisted penetration testing framework, to help automate parts of reconnaissance, panel interaction, and OSINT enrichment; the same open-source tooling has separately been linked to other automated scanning campaigns against Fortinet devices earlier this year.
Who is affected?
FortiBleed's targeting is global and, by most measures, opportunistic rather than geopolitically driven, though the campaign has clearly touched high-value targets along the way.
Small and mid-sized businesses are the primary target. Roughly two-thirds of affected organizations have fewer than 200 employees, and close to 90 percent report annual revenue under $100 million. This is not a campaign focused narrowly on large enterprises; it is built to sweep broadly.
IT services providers are disproportionately represented. Researchers assess this is a deliberate choice: compromising a managed service provider or IT vendor can open a path into every one of that vendor's downstream customers, multiplying the value of a single successful compromise.
Geography skews toward a handful of countries. India, the United States, and Taiwan together account for close to a third of affected domains, with meaningful additional victim counts across Latin America, the Middle East, and Europe. The exposed dataset that first surfaced this campaign included organizations across 194 countries.
Some large, recognizable names appear in the exposed data. Reporting on the original leaked dataset identified entries associated with organizations including Samsung, Mercedes-Benz, Foxconn, Chevron, Comcast, AT&T, and Toyota, alongside government agencies and critical infrastructure operators in telecommunications, healthcare, and financial services. Appearing in a leaked dataset does not necessarily mean an organization was fully compromised, but it does mean credentials tied to that organization were captured and should be treated as burned.
Any organization exposing FortiGate management interfaces to the public internet is at elevated risk, regardless of size or sector. The campaign's entry point is not a software bug; it's internet-reachable admin panels and VPN portals protected by passwords that were weak, reused, or previously exposed in some other breach.
Why this is different from a typical CVE
Most of the vulnerabilities we cover on this blog have a clear before-and-after: a patch exists, you apply it, and the specific flaw is closed. FortiBleed doesn't work that way, and that's precisely what makes it dangerous.
There is no single patch that stops FortiBleed, because the campaign doesn't rely on breaking Fortinet's software. It relies on breaking into accounts, then abusing a diagnostic feature that FortiOS is supposed to have. That means the fix isn't a version number; it's a set of operational and configuration changes across authentication, exposure, and monitoring, and the campaign will likely continue targeting any organization that hasn't made those changes, patched or not.
It's also worth being direct about a nuance that's caused some confusion in coverage: even organizations that patch every known Fortinet CVE promptly can still be exposed, if their management interfaces are internet-facing and their credentials are weak, reused, or already circulating from an unrelated breach. Patching and credential hygiene are two different problems here, and FortiBleed is fundamentally a credential hygiene problem.
Detection and indicators
Because FortigateSniffer works by abusing a legitimate diagnostic feature rather than deploying custom malware, traditional file-based detection will largely miss it. A few detection angles are worth prioritizing:
Review administrative account lists for suspicious names. Look specifically for accounts such as forticloud-sync, forticloud-tech, support_fortinet, or Technical_support that were not created by your own team. These names are designed to look like legitimate Fortinet support tooling.
Audit for unexpected use of diagnose sniffer packet. Review command history and administrative logs for this command being invoked outside of a known troubleshooting session, particularly if invoked by an account or session your team doesn't recognize.
Look for authentication anomalies in Active Directory. Beaumont's investigation found direct evidence of Active Directory access at a significant number of affected organizations, consistent with attackers positioning for follow-on ransomware activity. Watch for new service accounts, unexpected privilege escalation events, or AD authentication originating from unfamiliar sources tied to your FortiGate devices.
Check your organization against known FortiBleed datasets. SOCRadar and Hudson Rock have each published free lookup tools that let you check whether your domains appear in the exposed credential data (linked below). Security researcher Kevin Beaumont has also published a list of IP addresses associated with devices known to have been targeted.
What should you do?
1. Determine whether you're in the exposed dataset
Before anything else, check whether your organization's domains or device IPs appear in the known FortiBleed data using the SOCRadar or Hudson Rock tools linked above, or by cross-referencing Beaumont's published IP list. Treat a match as a confirmed compromise indicator, not a maybe.
2. If you're affected, rebuild rather than patch in place
If your organization appears in the exposed data, the strongest recommendation from researchers who've studied this campaign closely is to disconnect the affected device from the internet and rebuild it: a full factory reset followed by reconfiguration from a clean baseline, rather than attempting to clean an already-compromised device in place.
If a full rebuild isn't immediately possible, take these steps as an interim measure:
- Remove all existing administrative accounts and create new ones, with multi-factor authentication required
- Update the device to the latest available FortiOS firmware
- Inspect configuration history for unauthorized changes, such as altered firewall rules
- Rotate IPsec site-to-site VPN tunnel keys and certificates on both ends of every tunnel
3. Rotate credentials, whether or not you're in the dataset
Because the exposed dataset may be incomplete, CISA and Fortinet both recommend rotating all FortiGate admin and SSL VPN credentials as a baseline precaution, not only for organizations with a confirmed match.
# Example: force logout of all active SSL VPN sessions via the FortiGate CLI
config vpn ssl monitor
show
end
# Terminate individual sessions or all sessions, then require re-authentication
Consult Fortinet's own guidance for the exact commands appropriate to your FortiOS version, since CLI syntax varies across releases.
4. Get management interfaces off the public internet
The single highest-leverage structural change available to most organizations is removing FortiGate administrative and management interfaces from direct internet exposure, restricting access to trusted internal networks or a VPN-gated jump host instead. An attacker who cannot reach the login page at all cannot brute-force it.
5. Enable phishing-resistant MFA everywhere
Apply multi-factor authentication, ideally a phishing-resistant method such as a hardware security key or platform authenticator, to every VPN and administrative login. Credential-stuffing and brute-force attacks, which form the entire foundation of FortiBleed's initial access phase, are dramatically less effective against accounts protected by MFA.
6. Store credentials with modern hashing
CISA's advisory specifically recommends storing FortiGate administrative credentials using the PBKDF2 key-derivation function rather than weaker legacy hashing, reducing the value of any credential database that is later exposed or exfiltrated.
7. Remove unnecessary and default accounts
Audit your device for generic or default administrator accounts, and for any account names resembling the ones attackers were observed planting (see the Detection section above). Remove anything that isn't clearly tied to a known, current administrator.
8. Audit Active Directory for downstream compromise
If your FortiGate device authenticates against Active Directory or LDAP, treat that integration as a potential pivot point. Review AD for unauthorized service accounts, unexpected privilege escalations, and authentication activity originating from your Fortinet infrastructure that doesn't match known administrative behavior.
9. Review logs for signs of lateral movement
Look specifically for new VPN users you didn't create, unexpected password resets, and VPN logins originating from unfamiliar geographic locations or ASNs. These are the practical signals of a compromised credential already being used for follow-on access.
A note on scale and what it signals
FortiBleed is a useful case study in a broader pattern we've been watching this year: attackers increasingly don't need a zero-day to compromise widely deployed edge infrastructure. A patient, well-resourced group with good tooling, a target-ranking methodology, and a Telegram bot to manage password cracking can compromise hundreds of thousands of devices using nothing more exotic than exposed management panels and reused passwords. The operational discipline on display here, ranking targets by revenue before spending exploitation effort, running the sniffer only during business hours to blend into normal traffic, using plausible account names for persistence, reflects a criminal operation run with genuine process maturity.
That should inform how organizations think about edge device security generally. Patch management remains necessary but is not sufficient on its own; exposure reduction (getting management interfaces off the public internet) and credential hygiene (MFA, rotation, no reuse) are doing at least as much work in a campaign like this one.
Summary
| Campaign name | FortiBleed |
| Type | Large-scale credential-harvesting campaign (not a single CVE) |
| Target | FortiGate firewalls and SSL VPN gateways |
| Active since | At least February 2026; ongoing as of late June 2026 |
| Scale | 430,000+ firewalls targeted; 110M+ credentials identified across 659+ pipelines |
| Core tool | FortigateSniffer (Golang), abuses the legitimate diagnose sniffer packet FortiOS command |
| Initial access method | Credential stuffing and brute-force against admin panels and SSL-VPN portals; no software exploit required |
| Attribution | Assessed likely Russian-speaking financially motivated initial access broker (IAB) |
| Notable confirmed victim | A NATO-aligned defense contractor (data exfiltration) |
| CISA advisory | Issued June 18, 2026, urging credential resets, MFA, and interface hardening |
| Patchable? | No single patch; mitigation requires configuration and credential hygiene changes |
| Immediate priorities | Check exposure via SOCRadar/Hudson Rock tools; rotate credentials; remove management interfaces from the internet; enforce MFA |
FortiBleed is still active. If you need help determining whether your organization appears in the exposed datasets, auditing your FortiGate configuration and Active Directory environment for signs of compromise, or hardening your edge infrastructure against credential-based campaigns like this one, get in touch. A campaign built on exposed panels and reused passwords is entirely preventable, and getting your Fortinet posture right now is one of the highest-leverage moves available to most security teams this quarter.