An update on FortiBleed — what’s happening with victim orgs

An update on FortiBleed — what’s happening with victim orgsTwo days ago I wrote something about FortiBleed:FortiBleed — 75k Fortinet firewalls have admin passwords crackedFortinet 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:Inside the FortiBleed Open Directory: A Technical Analysis of What the Attacker Left Behind | CloudSEKCloudSEK’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 itThe 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.pic from CloudSek, borrowed from the threat actorConfig dumping at scaleAll 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.780.75.212.113213.21.239.65208.94.246.5869.195.129.14496.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.txtGAYINT 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.txtWhat the attacker did with accessThe 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.”From the organisations I’ve been helping, a few things have been seen:Multiple logins to legit staff accounts by the attackerMultiple exports of device configs by the attacker, these are automated and happen seconds after loginAdditions of new user admin accountsAdditions of new firewall rules — for example, allowing SSH and RDP to allow NAT’d IPsLogins to IPsec VPN tunnelsFrom 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 firewallsCheck 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:AL26-014 - FortiBleed leak of thousands of compromised credentials impacting Fortinet devices - Canadian Centre for Cyber SecurityIf the box is compromised, you may want to consider:Disconnect from the internet temporarilyRebuild the box from scratchIf not possible, remove all admin accounts, and create new ones for each user who needs access, with MFA enabled on each accountMake sure then box is on the very latest available firmware. If end of life and no firmware available, bin itInspect all firewall rules for changes, including looking at the system logsRotate IPsec site to site VPN tunnel keys or certs at both endsWho 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.Fun fact — the biggest and most damaging security incidents I’ve dealt with over the past 26 years have all involved teenagers, not nation states.Some of my learnings from FortiBleedOrganisations 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).honey I’m oldI think because of those involved in publicising this — from Voldymyr Bob Diachenko to Hudson to CloudSEK — we’ve ended up helping disrupting eCrime people getting further into large volumes of networks. As always, it will be people who get organisations out of danger — you can take your AI agents and stick them up your bum when shit’s on fire.An update on FortiBleed — what’s happening with victim orgs was originally published in DoublePulsar on Medium, where people are continuing the conversation by highlighting and responding to this story.