FortiBleed + INC/Lynx: When VPN Harvesting Fuels Ransomware
Saw the report linking FortiBleed directly to INC and Lynx operations. It confirms what many of us suspected: these mass FortiGate credential theft campaigns aren't just for reconnaissance—they are the primary entry point for follow-on ransomware deployment. The fact that an operator was found managing negotiation panels on the same infrastructure is a massive OPSEC fail, but it gives us solid attribution.
For those running FortiGate firewalls, the primary vector here appears to be the harvesting of valid SSL-VPN credentials. Once inside, the actors are bypassing the need for zero-days by using legitimate accounts. If you haven't already, you need to be hunting for anomalies in successful VPN logs, specifically looking for successful logins from impossible geolocations or successful authentications immediately preceded by failures.
Here is a quick KQL query for Sentinel/Defender to spot potential credential stuffing or successful brute force attempts on FortiGate SSL VPN endpoints:
DeviceEvents
| where ActionType == "LogonSuccess" and RemoteIP has_any ("")
| where DeviceName contains "Forti"
| project Timestamp, AccountName, RemoteIP, City, Country
| order by Timestamp desc
Additionally, check your FortiOS local logs for patterns indicating repeated failed attempts followed by a success:
diagnose log filter category 4 | grep "login=success"
Are we seeing MFA bypasses here, or is this purely a case of weak passwords/phished creds? curious how others are handling legacy VPN authentication in light of this.
From an SOC perspective, the 'negotiation panel' overlap is the gold here. It suggests the infrastructure isn't just compromised; it's operated by the core gang. We've started correlating successful VPN logins with subsequent PowerShell execution alerts on the internal network. If you see a VPN login and powershell.exe -enc within 10 minutes, assume ransomware prep.
It’s almost always weak passwords or reused creds from previous breaches in these cases. We’ve audited several clients where the 'ssl-vpn' account was still using a default or a weak 8-character password. If you can’t push hardware tokens immediately, force a password change and enforce complexity rules. The automation tools they use will brute force weak passwords in minutes.
We caught a similar attempt last week. The actor managed to get a valid credential but tripped our FSSO (Fortinet Single Sign-On) detection because the user was already logged in physically at a different site. The simultaneous sessions raised an alert. If you aren't using FSSO or SAML for your VPN, you're flying blind regarding context.
The OPSEC failure is indeed shocking, but it reinforces the need for aggressive patch management on edge devices. We often find legacy SSL-VPN portals spun up during the pandemic that have been forgotten. Beyond password audits, you should actively hunt for these orphaned instances. A quick Nmap scan can help identify outdated firmware targets:
nmap -p 443 --script fortigate-ssl-vpn-version
If you find endpoints on vulnerable versions, prioritize patching them immediately or enforce strict MFA as a compensating control while you work on the upgrade.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access