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.

You are right. Here is the updated paragraph **without** any citations or references:

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—specifically, credentials obtained through these earlier authentication bypass vulnerabilities—combined with brute-force attacks against devices that lack strong password hygiene and multi-factor authentication. Fortinet emphasized that this is not a new vulnerability and the activity is "not related to any recent incident or advisory", meaning the campaign exploits already-patched weaknesses rather than a newly discovered zero-day.

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.

Key Takeaway: This campaign does not exploit a software vulnerability – there is no patch that closes it. Remediation requires credential rotation, access restriction, and MFA enforcement.

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:

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.

2. Configuration Acquisition
Attackers obtain 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.

3. Offline Credential Cracking
The acquired configuration data is processed using dedicated offline password-cracking infrastructure, including 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.

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.

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.

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.

Key Observation: The detection problem is precisely that the abuse resembles legitimate administrative activity: valid credentials, valid usernames, successful authentication.

MITRE ATT&CK Mapping

Tactic	ATT&CK ID	Technique
Initial Access	T1078	Valid Accounts
Execution	T1059	Command and Scripting Interpreter
Persistence	T1098	Account Manipulation
Privilege Escalation	T1068	Exploitation for Privilege Escalation
Credential Access	T1003	OS Credential Dumping
Discovery	T1018	Remote System Discovery
Lateral Movement	T1021	Remote Services
Collection	T1005	Data from Local System
Exfiltration	T1041	Exfiltration Over C2 Channel

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
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
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
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.

Key Takeaway: Restrict management interface and VPN exposure from the public internet now, rotate all administrator and VPN credentials, and enforce multi-factor authentication on every admin and VPN account.

Instantly Fix Risks with Saner Patch Management

Saner patch management is a continuous, automated, and integrated software that instantly fixes risks exploited in the wild. The software supports major operating systems like Windows, Linux, and macOS, as well as 550+ third-party applications.

It also allows you to set up a safe testing area to test patches before deploying them in a primary production environment. Saner patch management additionally supports a patch rollback feature in case of patch failure or a system malfunction.

Experience the fastest and most accurate patching software here.