FortiBleed: FortiGate Hardening Guide After the 86,644-Device Compromise

FortiBleed is a large-scale credential harvesting campaign that compromised 86,644 internet-facing Fortinet FortiGate firewalls across 194 countries, making it the largest industrialized credential theft operation ever documented against Fortinet infrastructure. A FortiGate appliance is a next-generation firewall and VPN concentrator manufactured by Fortinet that serves as the network perimeter for millions of enterprises worldwide. When one is compromised, attackers gain a direct line into the corporate network it protects.

The campaign surfaced publicly on June 13, 2026, when security researcher Volodymyr Diachenko and the SOCRadar threat intelligence team discovered an exposed threat actor server hosting a continuously updated database of validated FortiGate administrator and VPN credentials. By June 19, CISA had issued an emergency advisory, the UK National Cyber Security Centre had published a global warning, and Fortinet's Product Security Incident Response Team had confirmed the credential exposure in an official blog post. All three advisories landed within a six-day window.

What happened: the campaign scope and attack chain

The threat actors behind FortiBleed are assessed by researchers at Thriven NextGen and Hudson Rock as a Russian-speaking cybercriminal syndicate operating at industrial scale. Their infrastructure was not opportunistic; it was purpose-built for credential logistics: devices were catalogued by country, industry sector, and organizational revenue, suggesting downstream sale or targeted ransomware deployment rather than immediate broad exploitation.

The attack chain ran in four stages:

• Stage 1: Internet-wide scanning identified FortiGate devices with publicly accessible management interfaces or SSL VPN endpoints exposed to the internet.
• Stage 2: Configuration file exfiltration retrieved device backup files. These files contain hashed administrator and local user passwords alongside the full running configuration. On unpatched FortiOS versions, passwords are stored as SHA-256 hashes: a fast, crackable algorithm.
• Stage 3: Offline password cracking used rented GPU infrastructure to recover plaintext credentials from the SHA-256 hashes. Fortinet did not introduce PBKDF2 hashing (resistant to GPU cracking) until FortiOS 7.2.11, 7.4.8, and 7.6.1, versions many organizations had not yet deployed.
• Stage 4: Listening post deployment. Attackers used recovered credentials to authenticate to compromised devices and configured them as passive interceptors. SSL VPN traffic passing through the appliance was monitored, and additional VPN user credentials were harvested, feeding back into the scanning loop and compounding the breach automatically.

The result: roughly half of all internet-reachable Fortinet perimeter devices confirmed compromised, with credentials validated and organized for sale or weaponization.

How attackers got in: the credential hygiene problem

Generic admin accounts were the most common entry point at 35% of compromised devices. Built-in Fortinet system accounts (such as forticloud, fortiuser, fortinet-support, and fortinet-tech-support) accounted for 28.3%. Organization-specific accounts made up the remaining 36.7%.

Three credential hygiene failures created this attack surface. First, many organizations never renamed or disabled the default admin account or the built-in Fortinet service accounts that ship with FortiOS. These accounts have predictable names and, in older configurations, predictable or blank passwords. Second, organizations failed to rotate credentials after previous Fortinet-related data exposures or after infostealer malware campaigns that had already extracted local credentials. Third, MFA was not enforced on administrative access, meaning a single credential pair was sufficient to authenticate without any second factor.

The service account problem in FortiBleed mirrors the broader non-human identity crisis in enterprise security. Organizations routinely create accounts for monitoring, automation, and vendor support with no expiry, no rotation schedule, and no MFA. For a deeper look at why service and machine accounts are a systemic vulnerability, see Non-Human Identities: The Hidden Attack Surface in AI and Enterprise Security.

What was taken and what came next

SOCRadar confirmed over 30,791 validated working device login credentials in the initial data set, with the full FortiBleed corpus estimated at 86,644 unique compromised devices by June 19. Data in the exposed threat actor database included: administrator credentials organized by geography and sector, SSL VPN user credentials captured via the listening post stage, device configuration files containing the full network topology, firewall rules, routing tables, and VPN tunnel configurations.

Once inside a device with valid administrator credentials, the documented post-compromise path involved creating persistent backdoor accounts outside normal IT workflows, modifying logging settings to reduce detection coverage, establishing outbound encrypted tunnels to attacker-controlled infrastructure, and pivoting laterally by using the firewall's privileged network position to reach internal hosts that otherwise had no direct internet exposure.

This lateral movement pattern is why perimeter compromise is categorically different from endpoint compromise. A firewall sits at the network boundary with trusted access to every segment it routes. The classic answer to containing this blast radius is zero trust: eliminating implicit network trust so that a compromised perimeter device cannot automatically reach internal resources. If your team has not yet evaluated this architecture, Zero Trust Network Access vs VPN: Complete Guide for 2026 walks through the practical transition.

How to audit your FortiGate now

Treat any internet-facing FortiGate as potentially compromised until you have completed the following checks. Start from the CLI (SSH or console) rather than the web GUI, since an attacker who modified GUI access controls will not have changed SSH access unless they also touched the management interface settings.

Step 1: Review all administrator accounts

# List all administrator accounts and their access profiles
get system admin

# Review each account for:
# - Unrecognized usernames (forticloud, fortiuser, fortinet-support, fortinet-tech-support)
# - Accounts with no trusted-hosts restriction
# - Accounts with super_admin profile that should not have it

Step 2: Check active and recent sessions

# Show currently active administrator sessions
get system performance status

# Review admin login logs for unexpected sources
execute log filter category 1
execute log filter field logid 0100032001
execute log display

Step 3: Verify password hash type

# Check your FortiOS version
get system status

# If below 7.2.11, 7.4.8, or 7.6.1: upgrade first
# After upgrade, each admin must log in once to trigger PBKDF2 hash migration

# On FortiOS 7.2.x and 7.4.x, enable this to block legacy SHA-256 logins:
config system password-policy
    set login-lockout-upon-weaker-encryption enable
end

Step 4: Check for unexpected configuration changes

# Compare current config against your last known-good backup
# Export current configuration
execute backup config ftp <ftp-server> <filename>

# Check for unexpected administrator accounts
show system admin

# Check for unexpected VPN users
show vpn ssl settings
show user local

Step 5: Check for outbound tunnels and unexpected routes

# Review active tunnels
diagnose vpn tunnel list

# Check for unexpected static routes pointing to external IPs
get router info routing-table all

# Review firewall policies for unexpected allow rules
show firewall policy

Fortinet hardening checklist

Once you have completed the audit, apply these controls. Treat each as mandatory, not optional:

• Disable or rename the default admin account. Never leave the built-in "admin" account active with its default name in production.
• Disable or delete all built-in Fortinet service accounts. Check for forticloud, fortiuser, fortinet-support, fortinet-tech-support, and any account whose creation you cannot trace to a specific change ticket.
• Enforce trusted hosts on every administrator account. Limit administrative access to a maximum of ten trusted IP addresses per account. Any IP outside those ranges cannot authenticate regardless of credential validity.
• Enable FortiToken or third-party TOTP MFA on all administrator accounts. A stolen credential pair alone is not sufficient to authenticate when MFA is enforced.
• Disable HTTP and Telnet management access. Only allow HTTPS and SSH. Telnet transmits credentials in cleartext; HTTP offers no transport security.
• Remove the management interface from public-facing interfaces. Place management access on a dedicated out-of-band interface or a trusted internal VLAN, never on the WAN interface exposed to the internet.
• Upgrade to FortiOS 7.2.11, 7.4.8, 7.6.1, or 8.0+ and require all administrators to log in post-upgrade. The upgrade alone does not migrate existing SHA-256 hashes to PBKDF2; per-administrator login is required.
• Enable login-lockout-upon-weaker-encryption in system password-policy on 7.2.x and 7.4.x to block legacy hash logins after migration.
• Enable strong crypto globally: config system global > set strong-crypto enable. This enforces TLS 1.2+ and disables weak cipher suites for management traffic.
• Rotate all administrator and VPN user credentials immediately. Do not reuse any credential from before June 2026 on an internet-facing FortiGate.

Detecting compromise indicators

FortiBleed does not leave file-based IoCs that antivirus can detect; it operates via legitimate FortiOS mechanisms. Detection requires log analysis focused on behavioral anomalies:

• Configuration exports directed to external IP addresses: legitimate backups go to internal FTP/SFTP servers or TFTP servers on your management network. Any export to an external IP is a high-confidence indicator.
• Administrator logins from unexpected geographies or IP ranges outside your trusted hosts list, particularly from residential IP ranges or VPN exit nodes.
• Newly created administrator accounts with super_admin profile that were not created through your change management process.
• Unexpected changes to logging configuration, particularly disabling log forwarding to your SIEM or reducing log verbosity on authentication events.
• Persistent outbound encrypted tunnels to IP addresses not present in your approved VPN peer list.
• VPN logins showing geographic impossibilities: a user authenticated from London two minutes after a session from Singapore indicates credential theft, not travel.

Forward FortiOS logs to your SIEM immediately if you are not already doing so. The Fortinet-recommended log categories for this investigation are event logs (administrative logins), traffic logs (unexpected outbound connections), and system logs (configuration changes). If you do not have a SIEM, forward to a syslog server and retain at least 90 days of logs before you begin your investigation.

Key takeaway

FortiBleed is not a story about a zero-day vulnerability. It is a story about credential hygiene failures at industrial scale. The attack chain required no novel exploitation technique: it used legitimate FortiOS backup functionality, cracked weak password hashes, and authenticated with recovered credentials. Every single control in the hardening checklist above would have prevented or significantly limited the impact.

If you have internet-facing FortiGate appliances, the question is not whether to act but how quickly. Audit administrator accounts today, disable unused built-in accounts, enforce trusted hosts and MFA, and upgrade to a version with PBKDF2 hashing. Rotate all credentials as if they are already compromised, because for 86,644 organizations, they were.