Two days ago I wrote something about FortiBleed:
Fortinet told media orgs the data was from prior breaches and bruteforcing. That isn’t true — or at least, not the full story. We’ll get into that in this blog. I’ve been working with impacted organisations to help them remediate — they’ve given me logs in return.
CloudSEK has a really good look inside the threat actor infrastructure here, it’s well worth a look if you’re a breach nerd:
CloudSEK’s blog is great but there’s around certain areas I’d like to add context to. For example, the reason certain password credentials are repeated across victims is because a ransomware group was backdooring devices a while ago — using the same passwords. In fact, from looking into this — a staggering amount of Fortigate customers are already backdoored essentially via dormant admin accounts, waiting for future breaches.
I disagree on their conclusion — yes, only about a thousand orgs were definitely compromised internally by this attacker based on the opendir evidence, however they performed logins at scale, performed full config exports and cracked credentials at scale across tens of thousands of Fortigate devices. They are currently trying to resell these credentials. Also, a thousand orgs getting pwned in itself is.. not fun. Let’s get into my perspective.
How they did it
The attacker made an big error and put parts of their attack infrastructure in an open directory anybody could access at 85.11.187.8 on port 9999. This gives much evidence about what they were up to.
The attacker essentially scanned the internet, discovered Fortigate boxes, logged in (it’s not quite clear exactly how this bit worked, but more likely prior unpatched vulnerabilities or prior backdoor admin accounts) and then exported the full Fortigate configuration. Then, offline, they cracked the password hashes to reveal plain text passwords of all users on the box. They are currently attempting to sell the credentials online on forums as FortiVPN client credentials. This will allow follow on breaches.
The password cracking was hosted at a GenAI company which rents GPU compute. The attacker rented 36 enterprise class GPUs — more than most large orgs have for internal AI efforts — and instead of using it for AI tasks, they used them for password cracking. Enterprise GPUs can crack passwords at scale very quickly.
This is a side impact of the drunk GenAI stupidity gripping organisations worldwide. Getting a 36 Nvidia GPU cluster a few years ago would have required talking to providers, getting racks and lots of setup. Now? Get a VISA card, rent by the hour and log in a few minutes later. All your irreversibly encrypted passwords aren’t looking so hot in the age of on demand compute at scale, where attackers who put things in open web directories can bruteforce large volumes of passwords at scale.
Press enter or click to view image in full size
Config dumping at scale
All of the orgs I’ve helped have experienced dumping of their Fortigate configs over the past month. Every one was a listed FortiBleed victim, and every one had their configs exported.
It is visible in Fortigate logs — go to System, Events, and filter Messages for config (or *config* depending on version of FortiOS). You will see messages saying the config has been exported, and list a user. You’ll see a mix of admins and REST API accounts doing the exports.
Here are IPs I have seen exporting device configs during the past month:
193.8.186.7
80.75.212.113
213.21.239.65
208.94.246.58
69.195.129.144
96.45.42.173 (yes, this one is Fortigate’s ASN and their SASE solution — no, I don’t know how this is happening).
These configs then had passwords cracked by the threat actor — giving them a large volume of new credentials.
I have published the full unredacted IP list of devices with known credentials and config dumps here — the victims, if you want to identify yourself:
http://owned.lab6.com/~gossi/research/public/fortibleed/some-fortibleed-ips.txt
GAYINT has published the victim domain list — to be clear, this is based on the Fortiguard license ID on the box, visible from the config dump:
https://blog.gayint.org/intel/fortibleed.txt
What the attacker did with access
The CloudSek report contains this: “The directory also contains at least one live SSL VPN configuration file pointing into a victim network, confirming that the operators held usable, active access, not merely a list of cracked passwords.”
Get Kevin Beaumont’s stories in your inbox
Join Medium for free to get updates from this writer.
From the organisations I’ve been helping, a few things have been seen:
- Multiple logins to legit staff accounts by the attacker
- Multiple exports of device configs by the attacker, these are automated and happen seconds after login
- Additions of new user admin accounts
- Additions of new firewall rules — for example, allowing SSH and RDP to allow NAT’d IPs
- Logins to IPsec VPN tunnels
From CloudSEK’s reporting, they appear to have specifically targeted telcos and MSPs which manage customer connectivity with Fortigate devices to gain access into internal networks. The directory contains direct evidence of access to internal Active Directory environments at a reasonable number of companies — the lateral movement playbook for ransomware and data extortion. The attacker has been rumbled early into their operation.
What to do if you use Fortigate firewalls
Check the some-fortibleed-IPs.txt list above for your internet facing Fortigate IP addresses, and fortibleed.txt for your domains. If you’re in either, there is a high probability your Fortigate device was already compromised.
I recommend this guide if in the lists above:
If the box is compromised, you may want to consider:
- Disconnect from the internet temporarily
- Rebuild the box from scratch
- If not possible, remove all admin accounts, and create new ones for each user who needs access, with MFA enabled on each account
- Make sure then box is on the very latest available firmware. If end of life and no firmware available, bin it
- Inspect all firewall rules for changes, including looking at the system logs
- Rotate IPsec site to site VPN tunnel keys or certs at both ends
Who is the attacker?
Unknown, but it fits the mold of an eCrime group. Also, many of the reused credentials come from one specific Russian ransomware group. The sloppy nature of the security around the attacker suggests less nation state and more Advanced Persistent Teenagers. There’s a financial motivation — you spend money on renting GPUs to crack passwords to make money from intrusions and blackmail of corporate victims.
Press enter or click to view image in full size
Some of my learnings from FortiBleed
- Organisations are constantly worrying about Generative AI threats — but this incident has tens of thousands of organisations without even multi-factor authentication setup on boxes providing VPNs still. There is a massive gap between what many cybersecurity people are talking about — Frontier AI — and what is happening at the organisations they manage.
- Generative AI craze has lowered the bar so Mr Bean can crack passwords quickly using his mums credit card. Thanks, Sam Altman.
- Fortinet need to invest in security more. They need to be on top of things like this. The statements to media around it being old breach data (not true — includes new passwords from cracking) and bruteforce tend to suggest Fortinet were on the backfoot. Which is fine, but they probably want to get more on the front foot longer term. My suggestion = add telemetry for config exports back to mothership, detections for large volumes of logins to unique devices from the same IP via Fortiguard telemetry, that sort of thing.
- Do you know which of your suppliers use Fortigate boxes for site-to-site VPNs? Are those threat actors inside your internal network now?
- There needs to be a better system for threat intelligence which isn’t private companies hoarding attacker data. There should be something public, not guided by profit. Hudson Rock have done a great job getting things out there on request, but I dunno.. it’s 2026, you know? I think active security threat data should be more openly shared. We’ve ended up with the Fortiguard ID domain list being hosted on GAYINT, and the impacted boxes IP list distributed by me on a webserver I set up in the year 2000 –26 years ago, which is still online to this day. (Fun fact, I went on to work in the office the box was hosted in two decades later).