01Am I exposed?

You are in scope for this checklist if any of the following is true of an internet-facing FortiGate:

  • HTTPS/SSH administrative access or SSL-VPN is reachable from the internet.
  • Local admin or VPN accounts use legacy password hashing (pre-PBKDF2) or passwords that have not been rotated recently.
  • MFA is not enforced on administrator and/or VPN accounts.

The steps below are ordered so the highest-impact, fastest actions come first.

02Terminate sessions & reset credentials

Assume any credential that could have been in a harvested config is compromised. Terminate all active administrative sessions, then reset every Fortinet VPN and administrative password — especially on internet-facing systems — and enforce a strong password policy. 

# See who is currently logged in, then reset the passwords that may have leaked
get system admin list                     # active admin sessions
config system admin
    edit "admin"
        set password <new-strong-secret>
    next
end
# Enforce a strong password policy for all local accounts
config system password-policy
    set status enable
    set min-lower-case-letter 1
    set min-upper-case-letter 1
    set min-number 1
    set min-non-alphanumeric 1
    set minimum-length 14
end

Reset VPN (local user) passwords the same way under config user local.

03Enforce MFA everywhere

A cracked password is only useful without a second factor. Enable multi-factor authentication on every administrator and VPN user account (FortiToken, or an email/SMS token where appropriate). This single control neutralises the core of the FortiBleed technique. See Fortinet's Administrator account options.

04Upgrade & enforce PBKDF2

Upgrade to the latest 7.4, 7.6, or 8.0 release. These support PBKDF2 hashing of administrator credentials — a slow hash that makes offline cracking impractical. Then remove the older, weaker legacy password settings so the device won't fall back to them. Fortinet documents this via login-lockout-upon-weaker-encryption (FortiOS 7.2.11 and later) — see the enforcing-PBKDF2 technical tip. 

# Lock out any login that would fall back to a weaker password hash, forcing PBKDF2
config system global
    set login-lockout-upon-weaker-encryption enable
end
Note: exact command availability/placement varies by FortiOS version (7.2.11+).
Confirm against your build, and re-set admin passwords after enabling so the
new PBKDF2 hashes are written.

05Validate the configuration

Review firewall and VPN users and the rest of the configuration for unauthorized changes — preferably by comparing against a known-good configuration. Pay particular attention to unrecognised accounts, e.g. unexpected additions named FortiCloud, FortiUser, fortinet-support, fortinet-tech-support, or similar. 

# Enumerate accounts and admin profiles; compare to your baseline
show system admin                         # administrator accounts + trusthosts
show user local                           # local (VPN) users
show system accprofile                    # admin permission profiles
diff <(show full-configuration)  known-good.conf   # from a management host with both configs

06Check your logs

Look for unexpected administrator access from unknown IPs, and review domain-controller logs for lateral movement, unusual access, suspicious accounts, or unauthorized configuration changes. 

# Recent admin logins and config changes on the FortiGate
execute log filter category event
execute log display                       # look for logid admin login / configuration change events
# On Windows AD: review 4624/4625 (logon), 4720 (account created), 4728/4732 (group add)

07Reduce the attack surface

Lock down management access. In increasing order of safety: restrict external management via trusted hosts (good), enforce a local-in policy (better), or remove internet administration altogether (best). 

# Good — bind each admin to trusted source networks only
config system admin
    edit "admin"
        set trusthost1 10.0.0.0 255.255.255.0        # placeholder: internal management subnet
        set trusthost2 10.10.10.10 255.255.255.255   # placeholder: admin jump host
    next
end

# Best — stop exposing management/VPN on the WAN interface entirely
config system interface
    edit "wan1"
        unset allowaccess                 # or: set allowaccess ping  (no https/ssh from the internet)
    next
end

For the "better" tier, use a local-in policy to filter traffic destined to the FortiGate itself. See Fortinet's Administrator access best practices and Hardening guides.

08If you find evidence of compromise

If there is any sign of unapproved configuration changes or other indicators of compromise (IoCs), escalate from hardening to incident response:

  • Treat the device as compromised and follow Fortinet's recommended recovery steps.
  • Hunt for lateral-movement signals: creation of VPN users, unexpected password resets, or VPN logins from unexpected locations — any of which may indicate the actor moved into the internal network.
  • If AD/LDAP integration is configured, treat that service account as compromised: monitor AD for its use to authenticate elsewhere or to create additional accounts, and watch the network for lateral movement.
  • Notify your regional CERT for tracking purposes, and engage Fortinet Advanced Support if you have concerns.

09References