FortiBleed: The Leak That Turned 73,000 Firewalls Into a Targeting Database

Background of FortiBleed

The FortiBleed campaign was first identified when an exposed threat-actor server hosting a growing, validated database of FortiGate administrator and VPN credentials was publicly disclosed, revealing a credential harvesting campaign already operating at scale.

The confirmed device count has reached approximately 86,644 unique devices across 194 countries, representing roughly half of all internet-facing Fortinet firewalls. The campaign has impacted organizations across numerous sectors, with telecom, government, and education emerging as the top three impacted industries. Geographically, the most affected countries include India, the United States, Mexico, Colombia, and Thailand.

Fortinet has responded by referencing internal advisories FG-IR-26-060 and FG-IR-25-647. The company's position is that the activity involves credential reuse from prior incidents combined with brute-force attacks against devices that lack strong password hygiene and multi-factor authentication. Fortinet characterized it as "not related to any recent incident or advisory."

Active credential abuse at a documented scale is confirmed. The campaign is assessed to be the work of a financially motivated Initial Access Broker (IAB), with tooling comments in Cyrillic pointing to a likely Russian origin. The threat actor has also been observed scanning for other remote-access tools, including RDP, SMB, MSSQL, Synology DiskStation Manager, and Sophos SSL-VPN portals.

Campaign Methodology

The campaign does not exploit a newly disclosed vulnerability. Instead, it leverages a combination of exposed internet-facing services, credential exposure, legacy password storage mechanisms, and credential abuse. The attack follows a structured six-stage process:

Stage 1: Reconnaissance

• Attackers conduct internet-wide scanning to identify FortiGate devices with publicly reachable management interfaces or SSL VPN endpoints. These exposed services provide potential entry points for administrative access and remote user connectivity.

Stage 2: Configuration Acquisition

• Researchers investigating the campaign reported that attackers obtained FortiGate configuration files containing authentication-related information and stored password hashes.
• Configuration file exports to external IP addresses have been documented during victim investigations, providing a potential detection opportunity for organizations reviewing FortiGate audit logs.

Stage 3: Offline Credential Cracking

• The acquired configuration data is processed using dedicated offline password-cracking infrastructure. Reporting associated with the campaign identified the use of Hashcat, Hashtopolis, and rented GPU resources, reportedly scaling to as many as 45 GPUs.
• The campaign primarily targets legacy salted SHA-256 password hashes. Although FortiOS 7.2.11, 7.4.8, and 7.6.1 introduced PBKDF2 hashing for newer authentications, existing administrator credentials may remain stored as SHA-256 hashes until the corresponding administrator logs in after the upgrade.
• For some FortiOS versions, legacy SHA-256 hashes may remain preserved in an internal "old-password" setting for backward compatibility. Fully migrating away from SHA-256 requires both upgrading and administrator reauthentication, along with enabling login-lockout-upon-weaker-encryption on supported versions.

Stage 4: Credential Abuse (Valid Authentication)

• After recovering credentials, attackers authenticate to targeted devices using legitimate administrator or VPN accounts. Authentication succeeds because the credentials are valid.
• No exploit payload, shellcode, or malware execution is required for this stage. The activity closely resembles legitimate administrative access, making detection significantly more challenging.

Stage 5: Credential Harvesting and Collection

• Researchers observed evidence of large-scale credential collection involving administrator and VPN account data associated with internet-facing Fortinet deployments.
• The campaign appears focused on continuously expanding and validating credential datasets that can be leveraged for future access operations.

Stage 6: Campaign Expansion

• Credentials obtained during earlier compromises are leveraged to identify and access additional targets, allowing the campaign to grow over time.
• The combination of credential exposure, password cracking, and credential reuse enables continued expansion without reliance on a newly disclosed software vulnerability.

Visual Attack Flow

Indicators of Compromise (IOCs)

Attacker Infrastructure & Tooling

• Exposed Server: A server containing the attacker's tools, databases, and SSH keys was left publicly exposed.
• Cracking Infrastructure: Hashtopolis & Hashcat with rented GPU capacity (up to 45 GPUs).
• Automation Tool: CyberStrike (open-source agentic penetration tool).
• Sniffer Tool: Passive sniffer deployed on compromised devices to capture VPN traffic.

Behavioral Indicators (Log Events to Hunt For)

• Configuration file export events with an external destination IP address.
• Administrator authentication from geographic locations or IP ranges outside normal management access patterns.
• New administrator accounts created outside normal provisioning workflows.
• Changes to logging configuration, authentication settings, or interface permissions outside documented change control windows.
• Outbound connections from the device to unrecognized external IP addresses, particularly persistent or recurring tunneling traffic.
• SSL VPN authentication events for known users from unexpected geographic locations or at unexpected times.

MITRE ATT&CK Mapping

Mitigation

There is no patch that closes this exposure. The following actions are required to mitigate the risk:

1. Identify Exposure: Determine whether your FortiGate management interface or SSL VPN endpoint is reachable from the public internet. Audit your software inventory for devices running builds older than 7.2.11, 7.4.8, or 7.6.1.
2. Restrict Management Access (Immediate): Remove direct public internet reachability for management interfaces and SSL VPN endpoints. Restrict access to internal IP ranges, trusted jump hosts, or VPN-only access. This is the single highest-impact mitigation.
3. Rotate Credentials (Immediate): Rotate all administrator, local user, and SSL VPN credentials immediately. Do not wait until after patching. Treat credentials on any internet-facing FortiGate as potentially compromised.
4. Enforce MFA (Immediate): Implement phishing-resistant MFA on all external gateways, VPNs, and administrative interfaces. This is a critical control to prevent credential reuse.
5. Upgrade and Migrate Hashes: Upgrade to FortiOS 7.2.11, 7.4.8, or 7.6.1 or later. After upgrading, each administrator must log in to replace their individual legacy SHA-256 hash with a PBKDF2 hash. On 7.2.x and 7.4.x, enable the login-lockout-upon-weaker-encryption setting to fully purge remaining SHA-256 hashes.
6. Assess for Prior Compromise: Review FortiGate logs for the behavioral indicators listed above. The absence of matching entries does not confirm no compromise occurred, as compromised devices may have had logging configuration modified.
7. Establish Ongoing Monitoring: Monitor for administrator authentication attempts from external IP addresses, VPN authentication events showing geographic impossibility, and configuration change events in the audit log.