An update on the FortiGate exploitation story I have been watching this year, because the picture has changed shape. What began, back in February, as reports of an AI-assisted threat actor mass-scanning FortiGate devices — and a subsequent CISA warning to Fortinet customers — has now been pulled apart in full by SOCRadar's Threat Research team in a report titled, aptly, Dismantling FortiBleed. The numbers are large and the technique is worth understanding, because it turns a comfortable assumption — that the firewall is the thing protecting you — on its head. Board-level read first, then the technical detail.

Board-level analysis

Your firewall was turned into the wiretap. This is the part to sit with. The attackers did not just get past the FortiGate; on devices they compromised, they used the firewall's own built-in diagnostic features to quietly listen to the traffic flowing through it and skim the usernames and passwords out of it. The device whose entire job is to guard the perimeter was repurposed into a listening post inside it. There is no dramatic outage to alert you — a tap is silent by design.

This is mostly about credentials, not a single exotic bug. The campaign runs on mass scanning, brute-forcing weak or reused logins, and then harvesting more credentials from the captured traffic. That matters for how you respond. You cannot patch your way out of a stolen password. The defences that count are multi-factor authentication, getting management interfaces off the public internet, and rotating credentials on the assumption they have already been taken.

The damage does not stop at the firewall. SOCRadar's reconstruction puts the haul at over 110 million credentials, which the actor then cracks and reuses against Active Directory, databases and other services. The blast radius is everywhere your people reused a password that ever passed through an affected gateway. One harvested VPN login becomes a foothold in the domain.

If your IT is outsourced, this is still your problem. The operation focuses heavily on small and medium businesses and, deliberately, on IT-services providers — because compromising a managed provider opens a path into all of its customers. If a third party runs a FortiGate on your behalf, their exposure is your exposure. That is a supply-chain question for the board, not a technical footnote for someone else.

It is run like a business, with automation doing the heavy lifting. The actor ranks targets by economic value before spending effort on them, runs the operation during Moscow office hours, geofences its activity, and — per the reporting — appears to lean on AI-native offensive tooling to assemble parts of the workflow. Validation pipelines were hitting success rates near 90%. The cost of running an industrial credential-harvesting operation has fallen, and this is what that looks like.

The questions for management: is any FortiGate of ours — or our provider's — exposed to the internet for administration or VPN; is MFA enforced on every remote login; and have we rotated the credentials that could have crossed one and assumed reuse elsewhere?

Technical analysis

The operation

FortiBleed is attributed to a Russian-speaking, financially motivated initial access broker, active since February 2026, and it is not Fortinet-only. The same actor has been running automated brute-forcing against Synology NAS, Sophos firewalls, RDWeb portals, Citrix SSL-VPNs and MS-SQL servers in parallel — FortiGate is simply the most productive seam. SOCRadar counts more than 430,000 FortiGate firewalls targeted and, across roughly 659 credential-harvesting pipelines run around 31 May and 15 June, over 110 million credentials identified: some 14.8 million RADIUS credentials, 924,000 NTLM hashes, 130,000 Kerberos hashes, and 89 million MySQL authentication tokens. Targeting skews to SMBs under 200 staff, with notable concentration in the United States and India and a clear preference for the IT-services sector, precisely because compromised providers yield downstream access into their customers.

The five-stage chain

The attack chain is methodical rather than clever, which is the point — it is built for scale.

First, reconnaissance: Masscan and Shodan to find internet-facing FortiGate devices, with bespoke utilities (FortiProbe-fast, GeoSplit) to filter and group targets by country. Second, access: a credential checker called forticheck and a brute-forcer (mpbrute2) thrown at the administrative panel and SSL-VPN portal, plus SSH access via credential stuffing and dictionary attacks. Third — and this is the heart of it — once SSH admin access exists, the actor deploys a Go-based tool, FortigateSniffer, that abuses FortiOS's legitimate built-in diagnose sniffer packet diagnostic to passively intercept authentication traffic across 24 protocols (TACACS+, Kerberos, RPC, SMB, LDAP, RDP, WinRM, MS-SQL, MySQL, PostgreSQL, RADIUS and more), parsing out cleartext credentials and password hashes. Fourth, cracking: harvested hashes are run through cracking tooling orchestrated, with a certain dark humour, by a Telegram bot named HASHBOT. Fifth, monetisation of access: lateral movement and Active Directory enumeration, exfiltration of data from network shares, and stolen session cookies reused to keep authenticated access alive.

The elegance — if you can call it that — is in stage three. Abusing a native diagnostic command means there is no conventional malware dropper to detect on the appliance and the collection is passive: the firewall keeps doing its job while copying every credential that crosses it. This is living-off-the-land moved onto the security device itself.

The toolkit, and a note of irony

SOCRadar's teardown of the operator's own tooling is instructive. A management Agent binary listens on port 7777 and exposes a handful of HTTP routes, including an /exec endpoint that turns each compromised host into an arbitrary command-execution point for the operator — authenticated by nothing more than a single static token in an HTTP header, with no MFA, no session rotation and no command scoping, listening on all interfaces rather than loopback. The same crew industrialising other people's credential hygiene runs infrastructure you could fingerprint by scanning for an open 7777. SOCRadar also found identical username/password pairs repeated across thousands of distinct IPs, consistent with the attacker planting backdoor credentials for later re-entry. And on the access-broker market, a Russian-speaking seller calling itself "SantaAd" advertised access to thousands of Fortinet devices, opening at $30,000 and doubling to $60,000 within hours — a reminder that harvested access is a commodity with a live price.

The AI angle, briefly

The reporting suspects the operators drew on an open-source, AI-native offensive-security framework to assist parts of the workflow, and ties a related framework to an earlier mass-scanning campaign against FortiGate that Amazon's threat intelligence team exposed earlier in the year. I will not amplify the tooling by name or link, but the trend matters: when assembling and operating a multi-stage, multi-vendor brute-force-and-harvest pipeline can be partly automated by AI assistants, the labour cost of running one of these operations drops, and you should expect more of them, run more cheaply, against more targets. The 90%-ish validation rates SOCRadar observed in early cycles are what efficiency at scale looks like from the attacker's side.

What to actually do

This is a credential and exposure problem, so the response is too. SOCRadar's own guidance for any organisation in the dataset is the right starting point, and I would treat it as applying to anyone running an exposed FortiGate whether or not you have been notified: rotate all credentials tied to Fortinet VPN and administrative interfaces; enforce multi-factor authentication; remove FortiGate management interfaces from direct internet exposure; and review gateway and authentication logs for suspicious activity.

Extend that with the wider blast radius in mind. Assume any credential that could have transited an affected gateway is compromised, which includes RADIUS, service accounts and domain credentials, not just the VPN logins — and in Active Directory that means resetting affected accounts and, where domain authentication may have been captured, the usual krbtgt double-reset and a hard look at admin tiering. Hunt on the appliances themselves: unexpected administrative SSH sessions, configuration or sniffer activity that no one authorised, unknown admin accounts, and any host answering on port 7777. Watch for the planted-credential pattern — the same login working across estate that should not share one. Treat egress monitoring and session-cookie invalidation as part of the clean-up, not an afterthought. And put the supply-chain question to anyone who manages network kit for you: what is your FortiGate exposure, is your management plane off the internet, and is MFA on every remote path.

The uncomfortable through-line is the one in the board section. We are used to thinking of the firewall as the thing standing between us and the internet. FortiBleed is a working demonstration that an internet-exposed, weakly-authenticated security appliance is not a wall — it is a high-value computer sitting at the most sensitive point in your network, and if someone else gets administrative control of it, every credential you send through it is theirs to read. The fix is not exotic. It is MFA, no management plane on the public internet, and the assumption — built into how you operate, not bolted on after an incident — that the passwords already left the building.