How attackers turned 86,000 firewalls into credential collection nodes without deploying a single piece of malware

The Context

FortiGate firewalls, made by Fortinet, are among the most widely deployed network security devices in the world. They sit at the edge of corporate networks, controlling who can connect remotely via VPN and what traffic can enter or leave. Because they are perimeter devices, they are by design reachable from the public internet. That exposure is the point: employees need to connect from home, from hotels, from client sites. But it also means every FortiGate with a management interface or VPN portal facing the internet is a target that any attacker anywhere in the world can attempt to reach.

FortiBleed is not a single exploit. It is an industrialized operation, built over months, that treated internet-facing FortiGate devices as a global credential mine. The attackers automated every step: finding devices, gaining access, extracting password files, cracking them, and then using the recovered passwords to turn each firewall into a passive wiretap for the organization behind it.

The Attack, Phase by Phase

Phase 1: Reconnaissance and Initial Access

The operation began no later than February 28, 2026, with automated internet-wide scanning using Masscan and Shodan. Custom utilities called FortiProbe-fast and GeoSplit filtered results and sorted targets by geography, sector, and organization revenue.

Attackers gained initial access through brute-forcing management interfaces with weak or default passwords, reusing credentials from prior Fortinet-related incidents (vulnerabilities tracked as CVE-2025-59718, CVE-2025-59719, and CVE-2026-24858, involving authentication bypass flaws in FortiCloud's single sign-on system), and in some cases through methods not publicly confirmed. Once on a device, they exported its configuration backup file.

Phase 2: Offline Hash Cracking and Credential Validation

The configuration files contained password hashes. For any administrator who had set their password before Fortinet's early 2025 firmware update and had not logged in since, that hash was stored in the older SHA-256 format—even on fully current firmware. The attackers cracked these hashes on a 45-GPU offline cluster managed by Hashtopolis, supplemented by rented GPU capacity from vast.ai. Because this happened entirely on the attacker's own hardware, it left no trace on the victim's firewall.

The cracked passwords were organized into a structured database sorted by country, sector, and organization revenue—the format an initial access broker uses to price and sell network access to ransomware groups and other buyers.

Phase 3: Passive Sniffer Deployment and Deep Credential Harvest

With valid administrator credentials, attackers logged back into compromised firewalls and deployed a custom tool called FortigateSniffer. It is a Golang program that calls a legitimate FortiOS built-in diagnostic command, diagnose sniffer packet—a standard tool administrators use for network troubleshooting. By abusing this command, the attackers passively captured authentication traffic across 24 protocols, including Kerberos, NTLM, RADIUS, Remote Desktop Protocol, LDAP, and Microsoft SQL Server logins.

The sniffer ran only between 07:00 and 18:00 Moscow Time, blending captured traffic with normal business-hours activity. Captured hashes were fed back into the same cracking infrastructure. Each compromised firewall became a credential collection node for every system inside the organization it protected.

Phase 4: Lateral Movement, Exfiltration, and Monetization

Cracked Kerberos and NTLM hashes were used to move laterally inside victim networks, impersonating legitimate employees on internal systems. In at least one confirmed case, a Turkish NATO-aligned defense contractor suffered exfiltration of over 12,000 files totaling 105 GB, including military maintenance manuals, radio cryptographic information, and firmware dumps. The exfiltration was triggered within minutes of the Kerberos hashes being cracked.

The credential database was sold on criminal underground markets. The Exploit Forum account SantaAd auctioned access starting at 5,000–$30,000, raising the price to $60,000 after public disclosure on June 13, 2026, citing media coverage as proof of the dataset's value.

What Made This Possible

1. Upgrade without migration. Fortinet's shift to stronger PBKDF2 password storage required a manual human action to complete: an administrator login after the firmware upgrade. Organizations that upgraded but never triggered that login remained silently vulnerable. The device reported as fully patched. The password was not.

2. The management interface was internet-facing. Roughly half of all internet-facing Fortinet firewalls had management interfaces or VPN portals reachable from the public internet, making automated scanning and brute-forcing possible at scale.

3. A legitimate tool became a wiretap. The diagnose sniffer packet command exists for valid network troubleshooting. Because it is a built-in function, its use generates no malware alerts and leaves no anomalous process signatures. The attackers did not need to smuggle anything onto the device.

What Should Have Stopped This

Every defense that would have reduced the blast radius here shares one trait: it does not depend on the firewall's own integrity to work.

• Multi-factor authentication on management interfaces. MFA would have made cracked passwords useless for logging back in. CISA's June 18 advisory explicitly required phishing-resistant MFA on all FortiGate management and VPN interfaces.
• No public internet access to management interfaces. If the management interface is unreachable from the internet, automated scanning cannot find it and brute-forcing cannot reach it.
• Forced password resets after firmware upgrades. If the upgrade process had required password resets rather than making migration optional on next login, SHA-256 hashes would not have persisted silently on upgraded devices.
• Behavioral monitoring for configuration exports. Sophos MDR's earliest confirmed detection, on June 2, 2026, came from flagging an unusual configuration file export to an external IP. Organizations with behavioral monitoring caught the signal. Those relying on signature-based detection did not.

The Takeaway

FortiBleed is the same class of failure as the Stryker Intune wipe: a privileged management tool weaponized against the organization it was built to protect. In the Stryker case, attackers used a legitimate device management platform to issue wipe commands. Here, attackers used a legitimate firewall diagnostic command to run a wiretap. Both attacks used the tool correctly—there was nothing anomalous about the commands themselves.

The deeper lesson is about the gap between patching and security. An organization that upgraded its FortiGate firmware and considered itself protected was not wrong about the firmware. It was wrong about what the upgrade actually changed. The password hash migration was a separate action, undocumented in most upgrade checklists, invisible in the device's status display, and silently incomplete on every device where no administrator had logged in since.

This also connects to the pattern from the Axios supply chain attack: in both cases, telemetry that would have revealed the attack was either absent or indistinguishable from normal activity. FortigateSniffer produced no malware signature. Cracking happened off-device. Valid credentials used to log in look identical to authorized access. When the attack uses legitimate tools and valid credentials, signature-based detection is structurally blind to it.

Pattern to remember: A security upgrade that requires a manual human action to complete is not an upgrade until that action is taken, and most organizations will never know it is pending.

What changed: Perimeter devices can now be turned into passive credential interceptors using their own built-in diagnostic commands, making the firewall itself the source of the breach rather than the barrier against it.

The Technical Mechanism

FortiBleed is a multi-stage credential-harvesting operation with no single CVE at its core. The attack chain exploits three distinct weaknesses in sequence.

Credential acquisition via configuration backup exfiltration. FortiOS configuration backup files store administrator and local user passwords as salted SHA-256 hashes in firmware versions prior to FortiOS 7.2.11, 7.4.8, and 7.6.1. Fortinet introduced PBKDF2-based hashing in those releases. However, the migration is not automatic on upgrade: existing password hashes remain in SHA-256 format until the administrator successfully authenticates post-upgrade, at which point the system re-hashes the credential under PBKDF2. Critically, per Arctic Wolf's analysis, the legacy SHA-256 hash persists in a hidden old-password field even after PBKDF2 migration, for backward compatibility, and is not visible through the management UI but is present in configuration backups exported by a super_admin account. Removing the legacy hash requires explicitly enabling the login-lockout-upon-weaker-encryption setting in FortiOS 7.2.x and 7.4.x.

Offline hash cracking at scale. Attackers operated a 45-GPU cracking cluster managed via Hashtopolis with Hashcat as the underlying engine, supplemented by rented GPU capacity from vast.ai. SHA-256 without key stretching is computationally inexpensive to attack: modern GPU clusters can test billions of candidate passwords per second. The offline methodology means no authentication attempts appear in victim logs. SpyCloud confirmed approximately 143,000 Kerberos hashes and 33,000 NetNTLM hashes were cracked from traffic captured by FortigateSniffer.

FortigateSniffer passive traffic interception. The custom Golang tool FortigateSniffer abuses the legitimate FortiOS CLI command diagnose sniffer packet, which is a built-in packet capture utility intended for network troubleshooting. The tool was configured to capture authentication traffic across 24 protocols. Because it invokes a native FortiOS function rather than injecting foreign code, it produces no process anomaly, no file system artifact detectable by integrity monitoring, and no malware signature. The sniffer operated on a 07:00 to 18:00 Moscow Time schedule (UTC+3), corresponding to standard European and Middle Eastern business hours, to blend captured traffic volume with normal activity patterns.

Prior vulnerability context. Initial access in some cases exploited authentication bypass vulnerabilities in FortiCloud's SAML-based single sign-on implementation. These are tracked as FG-IR-25-647 (covering CVE-2025-59718 and CVE-2025-59719) and FG-IR-26-060 (covering CVE-2026-24858). Fortinet's PSIRT blog characterized the broader campaign as credential reuse from these prior incidents combined with brute force, rather than a new vulnerability.

CVE and Advisories

• CVE-2025-59718 — FortiCloud SSO SAML authentication bypass (part of FG-IR-25-647)
• CVE-2025-59719 — FortiCloud SSO SAML authentication bypass (part of FG-IR-25-647)
• CVE-2026-24858 — FortiCloud SSO authentication bypass (part of FG-IR-26-060)
• Fortinet PSIRT blog: Analysis of Reported Credential Compromise of FortiGate Devices — June 19, 2026
• CISA Alert: CISA Urges Hardening Fortinet Devices After Reports of Credential Exposure — June 18, 2026, updated June 22, 2026

MITRE ATT&CK Mapping

Indicators of Compromise

Detection of FortiBleed is structurally difficult because the core attack phases leave no logs on victim devices. The offline cracking phase produces no authentication attempts in FortiGate logs. FortigateSniffer invokes a native CLI command and leaves no foreign binary signature.

Network Indicators

• Attacker infrastructure IP: 85.11.187.8 (linked by Recorded Future Insikt Group and corroborated by PwnDefend)
• Unusual configuration backup exports to external IP addresses (Sophos detection signature: PD-FORTINET-FORTIGATE-SYSTEM-CONFIG-DOWNLOAD-EXTERNAL-IP-1)
• Outbound connections from FortiGate management interfaces to unexpected external hosts

Behavioral Indicators

• diagnose sniffer packet command execution outside of change-window periods or by unexpected administrator accounts
• Administrator logins from unexpected source IPs or at unusual hours
• Kerberos or NTLM authentication anomalies in Active Directory logs following FortiGate compromise
• DFS share access or bulk file enumeration shortly after firewall authentication events

Credential Hygiene Indicators

• FortiOS version below 7.2.11, 7.4.8, or 7.6.1 (SHA-256 hash storage confirmed)
• Administrators who have not logged in since upgrading to PBKDF2-capable firmware (SHA-256 hash persists in old-password field)
• login-lockout-upon-weaker-encryption not enabled on FortiOS 7.2.x or 7.4.x (legacy hash not purged)

Huntress cross-referenced the FortiBleed dataset against its own telemetry and identified 845 partner organizations specifically present in the exposed credential catalog.

Attribution

Security researcher Volodymyr "Bob" Diachenko, who first discovered the exposed threat actor server on June 13, 2026, attributed the campaign to a Russian-speaking multi-operator threat group. SOCRadar's Threat Research Unit assessed the operator as a financially motivated initial access broker, with tooling comments written in the Cyrillic alphabet. Recorded Future's Insikt Group corroborated Russian-speaking attribution and linked campaign activity to IP address 85.11.187.8. SpyCloud assessed the operators as a Russian-speaking IAB group using spray-and-pray techniques, with the Exploit Forum account SantaAd implying operational responsibility.

A second seller, "shinymontanna," operating under ShinyHunters branding on Telegram, was assessed by Insikt Group as a low-credibility re-extortion actor capitalizing on the incident rather than an original participant.

No formal nation-state attribution has been made by any government agency. Recorded Future noted that Russian-speaking attribution combined with confirmed targeting of a NATO defense contractor raises the likelihood of espionage objectives alongside opportunistic financial access brokering. Full attribution remains uncertain across all research teams.

Primary Sources