What Actually Happened, and What You Should Do About It

There has been a lot of noise around “FortiBleed,” so I wanted to put together a straight-forward explanation of what it is, what it is not, and what you should actually do if you run FortiGate firewalls.

The short version: FortiBleed is not a new Fortinet vulnerability. This is mainly a credential problem. Threat actors are using previously exposed credentials, weak passwords, brute-force attempts, and internet-exposed management or VPN portals to get into devices.

That distinction matters.

It does not mean “ignore it.” It means the fix is not just “patch and move on.” You need to treat this like a credential-harvesting and access-control issue.

What is FortiBleed?

FortiBleed is the name being used for a credential-harvesting campaign targeting Fortinet devices, mostly FortiGate firewalls and VPN-facing systems.

In plain English, attackers are trying to log in with credentials they already have, credentials they cracked, or credentials they can guess/brute force. In some cases, those credentials may have come from older incidents or older exposed configurations. In other cases, it is likely just bad password hygiene and exposed management access being abused at scale.

This is not some magic new exploit where a fully patched FortiGate just falls over because someone looked at it wrong.

This is attackers doing what attackers do:

• Find internet-facing targets
• Try old or leaked credentials
• Try weak credentials
• Abuse systems that do not have MFA
• Look for management access exposed directly to the internet
• Move laterally if those firewall/VPN credentials also touch LDAP, AD, or other internal systems

That is why this is serious. If a firewall admin account or VPN account gets compromised, the firewall is not just another server. It is the front door, the routing point, the VPN headend, and often one of the most trusted devices in the environment.

Did Fortinet cause this?

Based on Fortinet’s public write-up, no, this is not being described as a new Fortinet vulnerability or a new product defect.

That does not mean there were never Fortinet CVEs in the past. Of course there were. Every major security vendor has had CVEs. The important part here is that FortiBleed, as currently described, is about credential reuse, credential harvesting, weak password hygiene, brute force, and exposed access.

So the better question is not, “Is Fortinet broken?”

The better question is, “Do I have old credentials, weak credentials, exposed admin access, no MFA, or old configs floating around?”

Because that is where the real risk is.

Why credential harvesting is such a big deal

Credential harvesting is ugly because it bypasses a lot of the things people assume will save them.

If the attacker has a valid username and password, they are not “hacking” in the movie sense. They are logging in.

If there is no MFA, they may get right in.

If admin access is open to the internet, they have a place to try. (FortiGate admin access opened to the Internet with no restricted host or Local-In policy)

If old local admin accounts still exist, they have more chances.

If VPN users are local firewall users with weak passwords, same problem.

If LDAP bind accounts or service accounts are reused elsewhere, now this can become an internal network problem.

That is why rotating passwords matters. That is why MFA matters. That is why locking down management access matters. And that is why just saying “we patched” is not enough if the password was already stolen six months ago.

What you should do now

Here is the practical list. Some of these might apply, others might not.

1. Reset FortiGate admin and VPN credentials

Do not overthink this one. Reset local admin passwords and local VPN user passwords, especially on anything internet-facing.

If a credential was harvested, patching does not magically make that password safe again.

2. Kill active admin and VPN sessions

Terminate active sessions so a bad login does not stay alive while you are cleaning things up.

3. Turn on MFA

MFA should be enabled for administrator accounts and VPN users wherever possible.

A stolen password without MFA is a door key.

A stolen password with MFA is still a problem, but it is a much harder problem for the attacker.

4. Stop exposing firewall management to the internet

This is the big one.

Do not leave HTTPS or SSH admin access open to the world on the WAN interface. If you absolutely must allow remote administration, restrict it:

• Use a dedicated management network
• Use VPN first, then manage the firewall
• Use trusted hosts
• Use local-in policies
• Geo-restrict only as an extra layer, not as your only layer
• Log the attempts

Changing the admin port is not real security by itself. It can reduce noise, but it does not replace access control.

5. Review admin accounts

Look for accounts that should not exist.

Pay special attention to accounts that look like support accounts, fake Fortinet accounts, or anything that was not created by your team.

If you find an account you cannot explain, treat that seriously.

6. Review VPN users

Check for unexpected local users, password resets, or changes to user groups.

Also check whether any VPN user account has more access than it should. A VPN account should not automatically mean “flat access to everything.”

7. Check logs

Look for:

• Admin logins from unknown IPs
• Logins from countries you do not operate in
• Failed login storms
• Successful logins after many failed attempts
• New admin accounts
• Config changes
• VPN logins at strange times
• LDAP/AD authentication from odd sources

If your FortiGate logs are not going to FortiAnalyzer or a SIEM, this is a good reminder to fix that.

8. Upgrade FortiOS

Stay on a supported release and follow Fortinet’s upgrade guidance.

Current FortiOS versions also support stronger administrator credential hashing with PBKDF2. If you are on older code, you should review Fortinet’s guidance around password hashing and legacy password settings.

9. Protect configuration backups

FortiGate configuration files can contain very sensitive information. Do not leave old backups sitting in random file shares, ticket attachments, MSP portals, or email chains.

Encrypt them. Store them somewhere appropriate. Delete old copies you no longer need. If you need to share a config for troubleshooting, sanitize it first.

10. If you see signs of compromise, treat it like a compromise

If you find unauthorized config changes, unknown users, suspicious admin logins, or signs of lateral movement, do not treat this like a normal maintenance task.

Open a support case, preserve logs, compare against a known-good backup, and start incident response.

My take

FortiBleed is a good reminder that firewalls are not magic boxes you can put on the internet and forget about.

The firewall is usually one of the most important security devices in the environment, but it still needs normal security hygiene:

• Patch it
• Lock down management
• Use MFA
• Rotate credentials
• Watch the logs
• Protect backups
• Remove old accounts
• Do not expose admin access unless you absolutely have to

This is not just a Fortinet lesson. This applies to every firewall, VPN concentrator, remote access platform, and security appliance.

Attackers love edge devices because they are exposed, trusted, and often under-managed.

Do not make it easy for them.

Official Fortinet references

• Fortinet PSIRT: Analysis of Reported Credential Compromise of FortiGate Devices
  https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices
• FortiGate / FortiOS Best Practices: Administrator Access
  https://docs.fortinet.com/document/fortigate/7.6.0/best-practices/587085/administrator-access
• FortiGate / FortiOS Best Practices: Hardening
  https://docs.fortinet.com/document/fortigate/7.6.0/best-practices/555436/hardening
• FortiGate Administrator Account Options: MFA and Trusted Hosts
  https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/014906/administrator-account-options
• Fortinet Community: Enforcing PBKDF2 for Administrator Accounts
  https://community.fortinet.com/fortigate-3/technical-tip-enforcing-pbkdf2-as-hash-function-for-administrator-accounts-in-fortios-v7-2-11-and-later-220652
• Fortinet Community: Recommended Steps in Case of a Compromised Host
  https://community.fortinet.com/fortigate-3/technical-tip-recommended-steps-to-execute-in-case-of-a-compromised-host-118585

Example of a local-in-policy

config firewall addrgrp
    edit "AllowedCountries"
        set member "USA" "Canada" "UK" "Germany" "Netherlands" "France" "Belgium" "Switzerland" "Austria" "Denmark" "Sweden" "Norway" "Finland" "Spain" "Italy" "Portugal" "Japan" "Singapore" "South Korea" "Ireland" "Australia" "New Zealand"
    next
end

config firewall local-in-policy
    edit 4
        set intf "JLG_Internet"
        set srcaddr "AllowedCountries"
        set srcaddr-negate enable
        set dstaddr "all"
        set service "ALL"
        set schedule "always"
    next
end

This local-in policy is a geo-restriction on the FortiGate’s public interface. Because srcaddr-negate is enabled on a deny policy, it denies local-in traffic from any source not in the AllowedCountries group. In practical terms, only sources from the listed countries are allowed to reach FortiGate-local services such as management, VPN listeners, ping, etc., assuming those services are enabled and no other local-in policy blocks them. This protects the FortiGate itself, not traffic passing through the firewall. You can modify this in any way to suit your needs.