If your business relies on Fortinet firewalls or SSL VPN gateways, the FortiBleed campaign deserves your attention. Unlike a typical vulnerability that a quick firmware update resolves, FortiBleed is a different kind of problem, and patching alone does not close it.
If Spot On Tech manages your firewall, you are already covered. We reviewed every FortiGate we manage, confirmed none are affected, and the protections that stop FortiBleed have been in place on our managed devices all along. The rest of this guide explains what FortiBleed is, how to check your own exposure, what to do about it, and exactly what we did on the firewalls we manage.
Why patching is not enough
According to threat-intelligence reporting from Kudelski Security, FortiBleed is not a fresh software bug with a one-click fix. It is a large-scale credential-harvesting and credential-abuse campaign. Attackers have collected or verified working credentials for tens of thousands of internet-facing FortiGate devices. Some were captured by brute force, and others trace back to older Fortinet vulnerabilities and previously exposed configurations.
The takeaway is simple. Upgrading FortiOS does nothing if valid administrator or VPN credentials are already sitting in an attacker's dataset. They do not need to exploit a bug when they can log in through the front door.
How to check whether your FortiGate is affected
If you manage your own Fortinet hardware, work through this quick assessment. Government advisories, including CISA's alert on hardening Fortinet devices and guidance from the Cyber Security Agency of Singapore, recommend auditing FortiGate access-control settings, rotating credentials, and investigating for unauthorized access.
- Check your exposure with a free tool. SOCRadar's free FortiBleed checker tells you whether your firewall appears in the exposed dataset.
- Is the admin GUI or SSH reachable from the public internet? Anything internet-facing was a target.
- Is SSL VPN enabled and exposed to the internet? Those accounts are the primary focus of the campaign.
- Review admin and VPN login history for logins from unfamiliar IP addresses or countries, especially a success that follows repeated failures.
- Inspect the configuration for changes you did not make: new administrator accounts, new API tokens, unfamiliar automation stitches, altered firewall policies, changed SSO settings, or scheduled scripts.
- Check whether your device's configuration or credentials appeared in any of the published FortiGate credential dumps.
If any of these raise a flag, assume the credentials on that device are compromised and move to remediation right away.
What to do now
If you run internet-facing FortiGate hardware, work through this checklist without delay.
- Rotate all administrator passwords, including local admin accounts that are rarely used.
- Reset every SSL VPN user password that authenticates directly against the FortiGate.
- Rotate embedded service credentials, including LDAP bind accounts, RADIUS secrets, API accounts, automation credentials, and any reused passwords.
- Enforce multi-factor authentication on every administrative and remote-access account you can.
- Lock down management access. Remove WAN access to the admin GUI and SSH, and restrict administration to an IP allowlist or a dedicated management VPN.
- Disable unused SSL VPN access and review every active VPN account.
- Upgrade FortiOS fully. This does not undo stolen credentials, but it closes the older vulnerabilities that fed the theft in the first place.
- Review the configuration for unauthorized changes, including new admins, API users, automation stitches, firewall policies, VPN users, SSO settings, and scheduled scripts.
A few additional precautions are worth taking while you are in there:
- Rotate IPsec VPN pre-shared keys and replace the device's local and SSL certificates, since keys stored in the configuration may be exposed.
- Set per-administrator trusted-host restrictions so an admin login only works from known management IPs, even if a password leaks.
- Terminate all active admin and VPN sessions after rotating credentials, so any live attacker session is cut off.
- Threat-hunt against published FortiBleed indicators of compromise and Fortinet's advisories.
- If you confirm or strongly suspect compromise, treat the device as fully compromised and rebuild its configuration from a known-good baseline rather than trusting the running config, since attackers hide persistence in scripts and automation.
- Re-secure any external authentication the FortiGate trusts, including LDAP, RADIUS, and SAML or SSO, so a stolen bind account cannot pivot into your directory.
What Spot On Tech has already done on the firewalls we manage
Every recommendation above maps to something already handled on the FortiGates in our care. Here is the fix, and what we did to achieve it.
| Status | Recommended fix | What Spot On Tech did on the firewalls we manage |
|---|---|---|
| Rotate all administrator passwords | We rotated every administrator password on the FortiGates we manage, including rarely used local admins. | |
| Reset all SSL VPN user passwords |
Not applicable. We do not use SSL VPN. Remote access runs through Zero Trust Network Access instead.
ZTNA Active |
|
| Rotate embedded service credentials (LDAP, RADIUS, API, automation) | We rotated the service credentials stored in the device configurations. | |
| Enforce multi-factor authentication | MFA has always been enabled on administrative and remote-access accounts. | |
| Remove WAN access to the admin GUI and SSH; restrict to an allowlist | Public WAN access to management has never been enabled. Administration is locked to specific internal IP addresses. | |
| Disable unused SSL VPN and review active VPN accounts | SSL VPN is not in use on any device we manage. | |
| Upgrade FortiOS fully | We keep FortiOS current as part of routine, ongoing patching. | |
| Review the configuration for unauthorized changes | We monitor configuration continuously and have alerts set up for any login or change. |
The short version: the front door FortiBleed relies on was never open on the firewalls we manage. There is no internet-facing SSL VPN to harvest, no public management interface to brute force, MFA is on everywhere, and a monitoring layer flags any login or change the moment it happens.
How we catch credential abuse
Because attackers log in with valid credentials, catching them takes behavioral monitoring, not just default firewall alerts. On the environments we manage, FortiGate event logs stream to a central monitoring platform with explicit alerts for the behavior that signals credential abuse.
| Event | Priority | Why it matters |
|---|---|---|
| Admin login from a new public IP | Critical | Signals possible administrative hijacking. |
| Multiple failed logins followed by a success | Critical | The classic signature of a successful brute-force attack. |
| New administrator account created | Critical | Attackers establishing persistent backdoor access. |
| Admin password or permissions changed | Critical | Unauthorized privilege escalation or an attempted lockout. |
| Configuration export or download | Critical | Active reconnaissance or data exfiltration. |
| New API token generated | Critical | A programmatic backdoor that bypasses GUI monitoring. |
| Logging or security controls disabled | Critical | An attempt to blind the defenders. |
| Unexpected configuration change | High | Any unmapped change to a firewall or routing rule. |
Why FortiBleed did not affect our clients
A while back we made a deliberate architectural decision and moved the clients we manage off SSL VPN entirely. We wrote about it in Beyond the Perimeter: Why SSL VPNs Are Failing and the Shift to ZTNA. Because remote access runs through Zero Trust Network Access, there is no public SSL VPN gateway for a credential-harvesting campaign like FortiBleed to target. Combined with MFA, internal-only management access, rotated credentials, and continuous monitoring, that is why FortiBleed does not affect the businesses we protect.
Not sure where your firewall stands?
If you are not certain whether your Fortinet devices are exposed, we can help. Contact Spot On Tech for a review of your firewall configuration, remote-access setup, and monitoring, or learn more about our cybersecurity services and our Single Point Of Tech™ approach.
