FortiBleed: 110M Credentials and the IAB Behind the Mass Harvesting
Has anyone else dug into the details on the FortiBleed operation? The stats coming out of this 110-million-credential haul are terrifying. We’re looking at a Russian-speaking IAB that’s been hammering over 430,000 FortiGate firewalls since February 2026.
It sounds like they aren't relying on a single zero-day but rather a mix of credential lists, scanning for exposed services, and brute-forcing accessible systems. If you have management interfaces or VPN ports listening on the WAN, you're likely in the crosshairs.
I've been hunting for signs of this activity in our environment. The report mentions bespoke tooling for the follow-on exploitation, but the initial access vector seems to be good old-fashioned credential stuffing. I whipped up a quick Python script to check our logs against common leaked credential patterns:
import re
def check_fortinet_logs(log_file):
failed_pattern = re.compile(r'Action=.*Login.*Status=failed')
with open(log_file, 'r') as f:
for line in f:
if failed_pattern.search(line):
print(f"[!] Detected failed login attempt: {line.strip()}")
check_fortinet_logs('fortigate_system.log')
The scale here is wild—110 million credentials. It implies they are combing through leaks and testing them against every exposed FortiGate they can find.
Are you guys strictly limiting admin access to specific IPs, or are you relying on MFA to save you here? Given the automation level of these IABs, I'm wondering if standard Geo-IP blocking is even effective anymore.
Geo-IP blocking is basically a speed bump at this point. These IABs have massive residential proxy networks (like the NetNut stuff we saw last month) to bypass that.
We found success by strictly enforcing 'Local In' policies on the FortiGate. Deny everything to the management interface from WAN, then allow only specific subnets. You can do it via CLI:
config system interface
edit "port1"
set allowaccess ping https ssh
set type physical
next
end
config firewall local-in-policy
edit 1
set intf "port1"
set srcaddr "Admin_Subnet"
set dstaddr "FortiGate_Local"
set action accept
set schedule "always"
set service "ALL"
next
edit 2
set intf "port1"
set srcaddr "all"
set dstaddr "FortiGate_Local"
set action deny
set schedule "always"
set service "ALL"
next
end
If you leave 443 open to the world, you will get bit eventually.
From a SOC perspective, the noise from these scans is unreal. We were drowning in 'admin login failed' alerts before we tuned the correlation rules.
One thing to add: check your SSL-VPN logs specifically. The report mentioned 'exposed services,' and SSL-VPN is the top target. We wrote a Sigma rule to look for >50 failed auth attempts from a single source IP within 10 minutes. It drastically cut down the investigation time. Even if they have creds, the lockout policies (if configured right) usually stop the brute-force phase before the bespoke deployment phase.
I'm an MSP, and this is a nightmare. We have clients running older FortiOS versions that are EOL. The credential harvesting is one thing, but if they start dropping custom payloads, we're toast.
For those on legacy hardware that can't upgrade: turn off the management interface on the WAN entirely. Use the out-of-band port or a dedicated jump host. If you can't patch, you have to reduce the attack surface physically. Also, rotate your VPN credentials immediately—if they are harvesting, they might already have your keys.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access