How 430,000 FortiGates Became a Source of Compromised Credentials
The FortiBleed campaign, identified by SOCRadar's Threat Research Unit, is a financially motivated Initial Access Broker (IAB) operation that has targeted over 430,000 FortiGate firewalls globally. Specifically, more than 80,000 firewall URLs are tied to Fortinet VPN credentials.
SOCRadar has confirmed over 30,791 working login credentials. Other estimates, from researchers like Kevin Beaumont and Hudson Rock, place the affected device count closer to 75,000 – roughly 50% of all internet-facing Fortinet firewalls. This represents a broad, coordinated attack impacting organizations in 194 countries globally. Threat actors are building extensive databases of validated credentials, categorized by country, sector, and even organization revenue. The objective of the FortiBleed campaign is to build a massive inventory for future attacks, not just immediate access.
Exploiting FortiGate's Sniffer Functionality
Attackers initiate the compromise by gaining initial access. Attackers employ standard methods: credential stuffing, brute-force attacks, and credential harvesting. This often involves using credentials stolen from other breaches to gain entry to FortiGate devices. Once administrative access is achieved, typically over SSH, a custom Golang-based tool named FortigateSniffer is deployed.
While Fortinet initially suggested the incident was primarily a collection of previously compromised credentials, SOCRadar's findings reveal an active, ongoing FortiBleed campaign. This is not a zero-day exploit. FortigateSniffer abuses a built-in FortiOS command: diagnose sniffer packet. This command, intended for network troubleshooting, allows for capturing live network traffic.
Attackers use it to monitor a wide array of authentication protocols, including Kerberos, LDAP, SMB, RADIUS, RDP, WinRM, Microsoft SQL Server, MySQL, PostgreSQL, SMTP, IMAP, POP3, FTP, Telnet, and others, totaling 24 protocols monitored by the tool. Their objective is to extract credentials, password hashes, and authentication secrets from this traffic. This method aligns with MITRE ATT&CK techniques such as T1040 (Network Sniffing) and T1059.004 (Command and Scripting Interpreter: Unix Shell) for execution, following initial access methods like T1078 (Valid Accounts) and T1110 (Brute Force).
After FortigateSniffer captures the data, it undergoes a two-stage processing pipeline. Initially, a component named SNIFTRAN reconstructs the captured packet data into PCAP files. Subsequently, a Python-based toolkit parses these files. This toolkit extracts cleartext credentials, password hashes, Kerberos tickets, NTLM authentication material, and email/database credentials. It also generates Hashcat-ready files for NTLM and Kerberos hashes.
The scale of this FortiBleed operation is significant. Threat actors are using a distributed GPU cluster, specifically 36 enterprise-class GPUs hosted at a GenAI company renting GPU compute, to crack these hashes using Hashcat. This has resulted in over 110 million credentials exposed across 659 harvest cycles. The issue extends beyond weak passwords; it encompasses the sheer volume of harvested data and the dedicated infrastructure deployed to crack it.
Kevin Beaumont observed another method: downloading FortiGate configuration files from compromised devices. These files can contain hashed credentials, particularly in older FortiOS versions. Fortinet introduced PBKDF2-based password hashing in versions 7.2.11, 7.4.8, and 7.6.1, replacing older SHA-256. However, a critical detail emerges: if an upgrade occurred from an older version, existing admin passwords remained as SHA-256 hashes until a post-upgrade login. Even after a password update, previous SHA256 hashes can persist in a hidden old-password setting for backward compatibility. While not visible to a regular administrator, this old-password is present in a super_admin config backup. Consequently, even with PBKDF2 in use, a legacy hash may still be present.
Impact and Case Studies of FortiBleed
The practical impact of FortiBleed is clear: any organization with an internet-facing FortiGate device, particularly those lacking strong credential hygiene or MFA, is a target. Confirmed breaches include data exfiltration from a NATO-aligned defense contractor. The threat extends beyond losing VPN access; it provides initial access to internal networks, potentially leading to data theft, ransomware deployment, or further lateral movement.
Victims are not limited to large enterprises. The FortiBleed campaign is disproportionately affecting IT services and smaller organizations and SMBs under 200 employees. These organizations often have fewer resources for advanced security, making them more susceptible to credential reuse or less stringent MFA enforcement.
Mitigating FortiBleed: Essential Proactive Measures
Fortinet's adoption of PBKDF2 for admin credentials is a positive development, and they have provided methods to remove older SHA256 hashes, such as enabling login-lockout-upon-weaker-encryption in system password-policy for v7.2.x and v7.4.x. However, the FortiBleed campaign demonstrates that relying solely on vendor patches is insufficient.
Immediate, practical steps are required to address this threat. Organizations with internet-facing FortiGate devices should assume their credentials are compromised and rotate all administrator and VPN user credentials without delay, as a response to confirmed compromise vectors from the FortiBleed campaign.
Phishing-resistant MFA is non-negotiable for critical systems like firewalls and VPNs. While SMS-based MFA offers some protection, hardware tokens or FIDO2 keys provide a significantly stronger defense. MFA significantly enhances security by preventing unauthorized access even if an attacker obtains valid credentials.
Additionally, the FortiGate's management interface must not be directly exposed to the internet. Implementing a dedicated management VPN, IP whitelisting, or jump boxes can restrict access to only necessary IP ranges, thereby reducing the attack surface for management plane compromise.
Regular auditing of FortiGate configuration backups is also essential. Specifically, check for any lingering old-password settings, particularly after upgrading from older FortiOS versions, and ensure these legacy hashes are removed. Monitoring FortiGate logs for unusual or excessive use of the diagnose sniffer packet command, especially from administrative accounts, can provide early indicators of post-compromise activity related to the FortiBleed campaign.
Finally, the prevalence of credential reuse, often from other breaches, fuels campaigns like FortiBleed. Implementing enterprise password managers, enforcing unique, complex passwords across all services, and educating users on the risks of credential reuse are fundamental mitigations that collectively reduce the efficacy of credential stuffing and harvesting attacks.
The "no zero-day" narrative obscures the core issue. FortiBleed demonstrates that even without a novel vulnerability, a determined attacker can combine credential stuffing, a built-in diagnostic tool, and substantial cracking power to compromise tens of thousands of organizations. Proactive credential management, network segmentation, and vigilant monitoring are critical to defending against such persistent threats.
