FortiBleed: FortiGate Credential Exposure Checklist

FortiBleed is a credential-compromise campaign affecting internet-facing FortiGate firewalls and VPN gateways. It is not a newly disclosed FortiOS vulnerability with one patch that closes the incident. The UK National Cyber Security Centre reported that a threat actor leaked a credential database after brute-force, dictionary, and credential-stuffing attempts. Fortinet separately said its initial analysis pointed to credentials reused from earlier incidents and brute-force activity against devices with weak password hygiene and no multi-factor authentication.

That distinction changes the response. Updating FortiOS is necessary, but it does not revoke credentials that may already be known to an attacker or remove persistence from a device that was compromised. The safe sequence is to identify exposed devices, preserve evidence, terminate active sessions, rotate credentials, enforce MFA and stronger hashing, restrict management access, validate configuration, and investigate downstream systems when evidence warrants it.

What FortiBleed Does—and Does Not—Prove

The campaign shows that valid credentials can outlive the event that exposed them. A current, supported firewall can still accept a stolen password until that password is changed or the account is disabled. Likewise, an active administrative or VPN session may survive a password change unless responders terminate it explicitly.

The public advisories do not prove that every internet-facing FortiGate was compromised, that every credential in circulation came from the same source, or that every affected device contains persistence. They do establish enough risk to require rapid scoping. Treat an exposure-check result as a lead, not a forensic conclusion, and treat a clean checker result as one data point rather than an all-clear.

The FortiGate Credential-Exposure Checklist

1. Build the complete device and access inventory

List every FortiGate, management address, SSL VPN or IPsec entry point, FortiManager relationship, local administrator, VPN account, API token, pre-shared key, and external identity dependency. Include branch offices, standby appliances, inherited equipment, lab devices, and systems managed by a third party. Record which interfaces were reachable from the internet and during what dates.

2. Preserve evidence before resetting or rebuilding

Export the current configuration, administrator and VPN logs, event and traffic logs, authentication records, and relevant FortiAnalyzer or SIEM data to protected storage. Preserve perimeter, identity-provider, RADIUS, LDAP, DNS, EDR, and Active Directory evidence for the same time window. Record collection time, time zone, device serial number, firmware build, and hashes for exported artifacts where practical.

3. Terminate sessions, then rotate credentials

End active administrator and VPN sessions before changing passwords. Reset every FortiGate administrator and VPN credential in scope, replace exposed API tokens and pre-shared keys, and rotate any credential reused elsewhere. If the device integrates with LDAP, RADIUS, SAML, or FortiCloud, review and rotate the associated privileged service credentials based on evidence and exposure.

4. Enforce MFA and PBKDF2 correctly

Fortinet recommends MFA for administrator and VPN users and current supported FortiOS versions in the 7.4, 7.6, or 8.0 families. Its response notes that these versions support PBKDF2 hashing for administrator credentials and points administrators to the legacy-password control set login-lockout-upon-weaker-encryption. The UK NCSC advises enabling PBKDF2 and requiring administrators to sign in again. Follow the exact Fortinet guidance for your supported release and verify the resulting state; do not assume that installing firmware alone migrated every stored credential.

5. Remove public management and validate configuration

Fortinet ranks trusted hosts as good, a local-in policy as better, and removing internet administration as best. Review administrator accounts, VPN users, policies, routes, certificates, automation, logging destinations, and management settings against a known-good configuration. Pay special attention to unfamiliar accounts and to settings that could preserve access or suppress visibility.

6. Hunt for use of the access—not just possession of a password

Correlate unexpected administrator logins, VPN sessions, new accounts, password resets, policy changes, and unusual source locations with identity and endpoint telemetry. If the device connects to Active Directory or LDAP, inspect those systems for suspicious authentication, added accounts, privilege changes, and lateral movement. ITECS endpoint detection and response and network monitoring services can correlate those layers when firewall evidence alone is incomplete.

When Should You Isolate or Rebuild?

What Leaders Should Ask Their IT Provider

• Which Fortinet devices and portals were internet-facing, and for what time window?
• Were active administrator and VPN sessions terminated before credentials were rotated?
• Is MFA enforced for every administrator and remote-access user, including break-glass accounts?
• Was PBKDF2 enablement and administrator reauthentication verified on each supported release?
• What logs and configurations were preserved, and what findings would trigger isolation or rebuild?
• Were LDAP, RADIUS, SAML, Active Directory, endpoints, and backup systems included in the scope decision?

The governing principle is simple: close the code risk, revoke the access, and prove that the device and the systems behind it remain trustworthy. ITECS managed firewall services and cybersecurity consulting help Dallas businesses carry that process from external exposure review through evidence-led recovery.

Sources

• Fortinet PSIRT — Analysis of Reported Credential Compromise of FortiGate Devices
• UK NCSC — Advice Following Global Targeting of Fortinet Firewalls and VPN Gateways
• Ireland NCSC — Global Targeting of Fortinet Firewalls and VPN Gateways