A joint advisory from the FBI and the U.S. Secret Service, published Oct. 6, says the FortiBleed credential campaign is still running against internet-facing FortiGate firewalls and SSL VPN gateways. The agencies add two details that raise the stakes for defenders: some victims are being locked out of their own devices, and the access is being passed to ransomware affiliates.
What the advisory says
The FBI and USSS advisory describes FortiBleed as “an active, global credential-compromise campaign targeting internet-facing Fortinet FortiGate firewalls and secure socket layer (SSL) virtual private network (VPN) gateways.” It cites SOCRadar for the scale: more than 86,644 compromised devices across 194 countries. The agencies say the operation works by exploiting reused or leaked credentials and legacy SHA-256 password storage, which lets the operators harvest and crack authentication data at scale.
Fortinet described the same campaign on June 19. Its PSIRT blog says “This is not a new Fortinet vulnerability, and this activity is not related to any recent incident or advisory.” Fortinet attributes the activity to threat actors reusing credentials from earlier incidents (FG-IR-26-060 and FG-IR-25-647) and brute-forcing devices with weak password hygiene and no multi-factor authentication. In Fortinet’s account, the firmware version is not the deciding factor. Password hygiene and MFA are.
How the operation ran
The advisory says the operators’ workflow became visible only after they unintentionally exposed their own backend server through an open directory. From the artifacts left there, the agencies summarize the progression in six steps:
- Automated scripts scanned the internet for exposed FortiGate SSL VPN portals.
- Operators collected credentials through credential stuffing and password spraying, drawing on earlier Fortinet leak dumps and infostealer logs.
- Password hashes taken from compromised devices went to a GPU-accelerated cracking cluster, with Hashcat and Hashtopolis distributing the jobs.
- Cracked credentials were validated and sorted, with scripts filtering out honeypots and ranking targets by revenue and network structure.
- With working credentials, the operators created new administrative accounts on the firewall for persistence, then enumerated Active Directory and sprayed passwords to find privileged accounts.
- The group packaged working VPN configurations and target lists for sale, which the advisory describes as the role of an initial-access broker.
The ransomware link is stated directly. The advisory reports that brokers using the FortiBleed chain “have provided further access to ransomware affiliates, currently including INC/Lynx ransomware and Payload ransomware.”
The lockout problem
The new element in this advisory is lockout. The advisory’s own wording is: “Affected organizations may find themselves locked out of their systems if threat actors disable accounts or change passwords, requiring remediation steps beyond standard patching and password resets.” The advisory says intruders create accounts that were not on the device before and, in some cases, delete existing accounts to keep administrators out while they attempt lateral movement.
It also lists account names seen on victim systems after intrusion, including adminin, forticloud-sync, fgtsecure, support_fortinet and adminsslvpn, and asks defenders to check every Fortinet account for legitimacy. Its table of observed attacker IP addresses covers activity from June 18 to July 23, so log review should reach back to June, not to the advisory date.
What the agencies and Fortinet tell defenders to do
The two sets of guidance overlap closely. The advisory’s key actions are to restrict or remove internet-facing management, terminate all administrative and VPN sessions and reset credentials, and require phishing-resistant MFA on remote access and administrative accounts. It adds that organizations should validate configuration against a known-good baseline, review firewall, VPN, authentication and domain controller logs, and confirm that administrator credentials are stored with PBKDF2 instead of weaker legacy hashes. It also asks defenders to review every REST API key on the device, remove unknown ones and refresh the rest. Fortinet’s post points to versions 7.4, 7.6 and 8.0 as the releases that support PBKDF2 hashing of administrator credentials.
On management exposure, the advisory ranks three options: trusted hosts (good), a local-in policy (better), and no internet administration at all (best). If the configuration shows unapproved changes, Fortinet says to treat the device as compromised and, where Active Directory or LDAP integration is configured, to treat that service account as compromised too.
What it means for the security leader
Our read: a firmware upgrade does not remove a credential the attacker already holds. The order of operations matters. Ending sessions and rotating credentials comes first, and moving to PBKDF2 matters because it makes stored hashes expensive to crack the next time they leak. An exposure inventory, the practice argued in An Exposure Inventory Decides Your First Hour After an Advisory, should include every firewall management interface that answers on the internet, because that is the list the scanners are working from.
The lockout detail changes the recovery plan. If the only path to a firewall is the account an attacker can delete, recovery needs an out-of-band route such as console access and a documented break-glass procedure, tested before an incident. The argument for replacing an exploited edge device instead of trusting it again, made in Replace an Exploited Edge Appliance Before You Trust It Again, applies here when a device may have carried attacker-created accounts. Separately, an exploitation warning for Fortinet’s FortiMail product is covered in Fortinet Warns of an Exploited FortiMail Flaw With Patches Pending. That flaw is unrelated to this credential campaign.
Actions for this week
- Find every FortiGate whose administrative or SSL VPN interface is reachable from the internet and apply the trusted-hosts or local-in restriction.
- Terminate sessions, reset all administrator and VPN passwords, and enforce phishing-resistant MFA.
- Compare each configuration with a known-good baseline and look for the account names in the advisory.
- Search authentication and domain controller logs from June onward for the observed addresses, vetting the indicators before blocking them, as the agencies advise.
- Review and rotate REST API keys, and confirm PBKDF2 for administrator credentials.
- Write down how you would reach a firewall if its administrator accounts were deleted.
