What changed

The attacker can keep access while the owner loses it

In a 6 October advisory, the FBI and U.S. Secret Service say the FortiBleed campaign is still targeting internet-facing FortiGate firewalls and SSL VPN gateways. Attackers have used previously exposed credentials, password spraying and offline cracking. On some compromised devices, they have created new administrator accounts, then changed or deleted legitimate accounts. That can leave the organisation locked out of the very gateway it needs to investigate.

Do not call this a new Fortinet zero-day

Fortinet says its analysis points to credential reuse and brute-force activity, not a newly disclosed Fortinet vulnerability. The October advisory adds detail about continuing access, lockouts and downstream risk. A firmware update matters, but it cannot by itself remove an intruder-created account or invalidate a stolen password.

What the number means

A large campaign is not proof that every listed network was breached

The agencies cite SOCRadar's finding of more than 86,644 compromised device records across 194 countries. That is a research figure repeated in the advisory, not a count of confirmed ransomware victims or proof that all those organisations suffered internal-network compromise. The agencies also report that access brokers using this chain have supplied access to ransomware affiliates. The distinction is important: exposure, successful gateway login and movement beyond the gateway are different findings.

Defender workflow

Establish what changed before declaring the device clean

  1. 1

    Identify exposed gateways. Find every FortiGate management interface and SSL VPN reachable from outside, including standby and branch devices. Restrict internet administration through trusted hosts or local-in policies; remove it entirely where possible.

  2. 2

    Preserve an evidence window. Collect firewall, VPN, authentication and domain-controller logs, plus a current configuration copy. Compare users, policies and settings with a known-good baseline before disruptive recovery work erases useful context.

  3. 3

    Look for persistence. Check for newly created or altered administrator and VPN accounts, unexpected sessions, suspicious configuration changes and unfamiliar REST API keys. The advisory's usernames and IPs are leads, not a self-sufficient verdict.

  4. 4

    Evict access as one plan. Where compromise is suspected, coordinate isolation, session termination, password resets, API-key review and phishing-resistant MFA with incident response. Follow Fortinet's current recovery guidance for a modified device, and examine any connected AD or LDAP account.

Defender note

A successful password reset is not an investigation result

  • Check whether older administrator password hashes remain after an upgrade; the agencies point to Fortinet's PBKDF2 guidance, but a stronger hash cannot undo an already stolen password.
  • Correlate gateway activity with identity and domain-controller records to test for movement into the internal network.
  • Interpret historical IP indicators in their observed time window. Shared infrastructure may later be reassigned, so do not block or accuse solely on a stale match.

The useful closure statement is specific: which gateways were exposed, which accounts and keys were verified, whether configuration drift was found, and whether there is evidence of access beyond the device. “Patched” alone answers none of those questions.

This topic was surfaced by The Cyber Security Hub newsletter. Threat Field Notes reviewed the agencies' advisory and Fortinet's original guidance independently and wrote this defender-focused note in original language.