The Cryptographic Debt Fueling the FortiBleed Campaign

Perimeter security appliances are the modern enterprise's front door, which makes them the most heavily targeted real estate on the internet. When those doors are secured with legacy cryptography and default configurations, the result is not a series of isolated breaches, but an industrialized harvesting campaign.

This is the reality of FortiBleed, a sweeping credential-theft campaign that has compromised at least 86,644 Fortinet FortiGate devices globally. While initial reactions might point to a novel zero-day vulnerability, the technical reality is far more mundane—and far more instructive for systems engineers. The campaign, attributed to Russian-speaking threat actors, relies on a combination of brute-force credential stuffing and a critical operational blind spot: the gap between upgrading an operating system and actually migrating legacy cryptographic assets.

For SREs, network engineers, and security teams, FortiBleed is a stark reminder that security is an active operational state, not merely a software version number.

The Anatomy of the FortiBleed Pipeline

The FortiBleed campaign is characterized by its scale and automation. According to data from security researchers and CISA, the threat actors executed approximately 1.16 billion credential attempts against more than 320,000 FortiGate targets, alongside 2.1 billion brute-force attempts targeting over 160,000 MSSQL servers.

This was not a manual, targeted effort. The attackers built a self-sustaining, automated pipeline designed to find, exploit, and expand their footprint:

flowchart TD
    A[Mass Internet Scan] -->|Identify FortiGate Endpoints| B[Credential Stuffing / Brute Force]
    B -->|1.16B Attempts| C{Access Gained?}
    C -->|No| D[Log & Retry]
    C -->|Yes| E[Passive Traffic Monitoring]
    E -->|Intercept SSL VPN Auth| F[Extract Legacy SHA-256 Hashes]
    F -->|45-GPU Hashtopolis Cluster| G[Crack Hashes to Plaintext]
    G -->|Pivot| H[Internal Active Directory]

Once initial access is achieved, the attackers do not immediately make noise. Instead, they passively monitor network traffic traversing the compromised devices to harvest additional credentials. These credentials are then verified and compiled into a centralized database.

When security researcher Volodymyr "Bob" Diachenko discovered the attackers' command-and-control server, it contained verified, working credentials for tens of thousands of devices across 194 countries. The dataset did not just contain usernames and passwords; it was enriched with organizational metadata—including industry, revenue, and employee count—structured to help the actors prioritize high-value targets for downstream ransomware deployment or deep espionage.

The Cryptographic Debt: The Hashing Migration Gap

To understand why this campaign succeeded at such a scale, we must look at how FortiOS historically handled credential storage.

Historically, FortiGate appliances stored administrator credentials using a legacy SHA-256 with Salt hashing mechanism. In modern cryptography, simple salted SHA-256 is highly vulnerable to offline GPU-accelerated brute-forcing. To address this, Fortinet introduced Password-Based Key Derivation Function 2 (PBKDF2) hashing in the following firmware releases:

• FortiOS 7.2.11
• FortiOS 7.4.8
• FortiOS 7.6.1

PBKDF2 introduces a configurable iteration count (stretching), making offline cracking computationally expensive and rendering mass GPU clusters highly inefficient.

However, shipping a stronger hashing algorithm in a firmware update does not automatically secure existing installations. This is the hashing migration gap: when an organization upgrades a FortiGate appliance from an older version to a PBKDF2-compliant version, the existing administrator passwords remain stored as legacy SHA-256 hashes.

The upgrade process does not—and cryptographically cannot—automatically convert the old SHA-256 hashes into PBKDF2 hashes because the plaintext password is required to generate the new PBKDF2 key. The migration to the stronger hash only occurs when the corresponding administrator successfully logs in after the upgrade has been completed.

Advertisement

Serverless Inference by DigitalOcean 55+ models, every modality. One API key, one bill.

If an administrator account is rarely used, or if it is a legacy service account that authenticates via automated API tokens rather than interactive web logins, its hash remains stored in the weaker SHA-256 format. If attackers extract the configuration file or intercept the authentication exchange, they can easily feed these legacy hashes into a GPU cracking cluster—such as the 45-GPU Hashtopolis cluster utilized in this campaign—and recover the plaintext password.

Furthermore, the data shows a widespread failure of basic credential hygiene. According to analysis by SOCRadar, generic admin accounts (35%) and built-in system accounts (28.3%) made up the majority of the compromised credentials. This indicates that many organizations upgraded their firmware but never changed default factory credentials or renamed default administrative accounts.

The SRE and Network Engineer Playbook

If you run FortiGate appliances or manage infrastructure behind them, you must assume your perimeter has been mapped. Resolving this exposure requires moving beyond simple patching to active credential and cryptographic hygiene.

1. Terminate and Rotate (The Immediate Response)

Do not assume your credentials are safe because your firmware is updated. You must force a complete cryptographic reset:

• Terminate Sessions: Force-terminate all active SSL VPN and administrative sessions across all firewalls.
• Rotate All Credentials: Reset passwords for all administrative, system, and VPN accounts. This rotation is critical because it forces the FortiOS database to write the new credentials using the modern PBKDF2 algorithm, purging the legacy SHA-256 hashes from the configuration.
• Enforce Password Complexity: Ensure new passwords meet high-entropy standards to resist dictionary attacks.

2. Verify Hashing Algorithms

Ensure that your administrative accounts are actually using PBKDF2. You can verify the configuration state via the FortiOS Command Line Interface (CLI). Inspect the system admin configuration to ensure that legacy hashes are no longer present:

show system admin

Look at the password field format. If you see legacy hash formats or if you suspect accounts have not logged in since the last major firmware upgrade, force a password change programmatically to trigger the PBKDF2 migration.

3. Isolate the Management Interface

Under no circumstances should a firewall's management interface (HTTPS/SSH) be exposed to the public internet.

• Restrict Access: Bind administrative access to specific, trusted source IP addresses or internal management subnets.
• Disable WAN Admin: Ensure that administrative access is disabled on all external-facing (WAN) interfaces:

config system interface
    edit "wan1"
        set allowaccess ping # Remove 'https' and 'ssh'
    next
end

4. Implement Phishing-Resistant MFA

Enable multi-factor authentication (MFA) on all external gateways and administrative interfaces. Prioritize FIDO2/WebAuthn-based hardware tokens over SMS or standard TOTP push notifications, as the latter can still be bypassed via session-hijacking techniques if the underlying endpoint is compromised.

5. Audit Logs for Lateral Movement

Because the threat actors used valid credentials, standard intrusion detection systems (IDS) may not trigger alerts. You must hunt for anomalous behavior in your logs:

• Anomalous Logins: Look for administrative logins originating from unexpected geographic locations or hosting providers.
• Configuration Changes: Audit the FortiGate configuration log for unauthorized changes, particularly the creation of new local accounts or modifications to firewall policies.
• Active Directory Correlation: Cross-reference VPN login times with internal Active Directory domain controller logs to identify lateral movement patterns.

The Cost of Deferred Maintenance

FortiBleed is not a failure of Fortinet's engineering; it is a failure of operational execution. It highlights a recurring pattern in systems administration: treating software upgrades as a passive task.

When security teams treat an upgrade as completed the moment the system reboots into the new version, they ignore the underlying state of the data. Cryptographic upgrades often require human intervention—a password reset, a database migration script, or a configuration rewrite—to actually take effect. Until those steps are taken, the system remains wrapped in a modern shell while harboring legacy vulnerabilities inside.

In the face of automated, GPU-backed threat actors, leaving those legacy hashes in place is no longer an acceptable risk.