FortiBleed Attackers Locking Victims Out of Fortinet Devices

1. Executive summary

The FortiBleed campaign, active since June 2026, is compromising internet-facing Fortinet FortiGate firewalls and SSL VPN gateways at scale, and operators are now locking legitimate administrators out by changing passwords and deleting accounts on the devices they hold. SOCRadar reports 86,644 confirmed-compromised devices across 194 countries, and the FBI and US Secret Service have issued a joint advisory confirming the lockout behaviour and the persistence motive behind it. No CVE is associated with this campaign in the source material: initial access is via previously compromised credentials, credential material harvested from infostealer logs and prior dumps, offline cracking of stored hashes, and brute force against poorly protected devices. EMEA financial services firms running internet-exposed FortiGate or Fortinet SSL VPN are in scope, and the operational risk is not only intrusion but loss of administrative control over perimeter security infrastructure, which removes the ability to contain the incident from the device itself.

2. Regulatory framing

No DORA article on testing or concentration risk is engaged by the facts in this item, and no UK NIS 2018 duty is triggered by anything in the source material beyond the general OES/RDSP obligations that apply to any incident of this kind.

3. Technical analysis & attack chain

Confirmed steps, drawn from the FBI/US Secret Service joint advisory as reported and from SOCRadar's findings:

1. Attackers scan for internet-exposed Fortinet SSL VPN portals and FortiGate management interfaces.
2. They harvest credentials from infostealer logs and from previous credential dumps, and crack stored credential hashes offline.
3. They map the attack surface to avoid honeypots before committing to a target.
4. They authenticate with verified working credentials, or brute force poorly protected devices, and take over the device.
5. On compromised devices they change the password on original accounts and delete existing accounts, which blocks the legitimate organisation from accessing the device and maintains the attacker's persistence while they attempt lateral movement into the environment.
6. Working VPN configurations and target lists are sold to other threat actors.

The credential material is the whole campaign. Arctic Wolf's mid-June 2026 assessment, reported by DataBreaches.net, describes systematic extraction of configuration files from internet-facing FortiGate devices followed by offline cracking of the stored credential hashes, yielding verified working administrator credentials for between 30,000 and 75,000 devices at that point. SOCRadar's later figure of 86,644 confirmed-compromised devices in 194 countries is a count of confirmed compromises, not an exposure estimate, and SOCRadar notes that devices breached months ago remain in the actors' validated inventory. That distinction matters for remediation: a device that shows no current attacker activity may still be in someone's working credential set.

Dark Reading reports a Golang-based sniffer built to target 430,000 FortiGate firewalls and identify 110 million credentials. BleepingComputer, citing SOCRadar, describes custom sniffers used to harvest authentication secrets from compromised firewalls. The two accounts describe the same tooling class; the 430,000 and 110 million figures are single-sourced to Dark Reading and should be treated as that vendor's measurement rather than an independently corroborated count.

Attribution is split and should be treated as unconfirmed. SecurityWeek reports that a Russian initial access broker was blamed for the campaign within a week of the June activity. Cybersecurity Dive describes an initial access broker working with various ransomware groups. BleepingComputer links the campaign to the INC and Lynx ransomware operations, indicating the stolen Fortinet credentials were intended to fuel future network intrusions. No MITRE ATT&CK profile is available in the verified reference data for any actor named here, so no attribution to a specific tracked group is confirmed. The consistent thread across sources is a broker model: credentials and access are harvested and sold, and ransomware affiliates are the downstream consumers.

The lockout behaviour is the newest confirmed development and comes from the joint FBI/USSS advisory: "Some victims may get locked out of their Fortinet devices if the threat actor either deletes or changes the password for original accounts on the system. In certain cases, threat actors delete existing accounts to block organizations from accessing affected devices and to maintain persistence on the system while attempting lateral movement within the environment."

4. Mitigation & containment

The joint advisory's recommended sequence is identify, scope, evict, harden, report. The steps below follow that order and are prioritised by how directly they address the lockout and the credential reuse that enables it.

P1 within 24 hours

• Inventory every internet-facing FortiGate firewall and Fortinet SSL VPN gateway, and record which ones have management or VPN access exposed to the internet. Restrict management access to a dedicated management network or a tightly scoped allowlist; this is the single change that removes the campaign's initial access path.
• Reset all Fortinet VPN and administrative passwords. Do this on every device in the estate, not only on devices with evidence of compromise, because SOCRadar's validated inventory includes devices breached months ago.
• Before resetting, confirm you still hold working administrative access. If an account has been deleted or its password changed by someone else, treat the device as compromised and recover it through out-of-band console access rather than assuming a reset will succeed.
• Enable phishing-resistant MFA on all Fortinet administrative and VPN accounts. The advisory names this specifically; password resets alone do not close the credential-reuse path.
• Review all firewall and VPN user accounts and remove any that are unrecognised, unused, or were created outside your change process. New accounts created by an attacker are the persistence mechanism described in the advisory.
• Review and validate API keys on the devices, and rotate any that cannot be accounted for.

P2 within 72 hours

• Review device logs for suspicious authentication activity, account creation and account deletion, going back far enough to cover the June onset of the campaign. Where log retention is shorter than that, record the gap explicitly as a scoping limitation.
• Scope the intrusion beyond the FortiGate itself. The advisory states attackers attempt lateral movement within the environment after establishing persistence on the device, so treat any confirmed device compromise as a network intrusion and hunt for follow-on access.
• Confirm credentials are stored securely across the estate, and check whether any Fortinet credentials appear in infostealer log datasets or prior breach dumps. The campaign's supply of working credentials comes from exactly those sources.
• Evict the attacker: remove unauthorised accounts, revoke sessions and VPN configurations issued to attacker-controlled accounts, and rotate any credential the device could have exposed.

P3 within 7 days

• Report the intrusion through your normal incident process and, where the classification thresholds are met, to your competent authority under DORA Art. 19.
• Review the Fortinet estate against your third-party risk framework under DORA Art. 28 and NIS2 Art. 21(2)(d), covering who holds administrative credentials, how they are protected, and how the exposure is monitored.
• Where a device cannot be shown to be clean, rebuild it from a known-good configuration rather than cleaning in place.

5. Indicators of compromise

No atomic indicators (hashes, domains, IP addresses, file paths, registry keys) are present in the source material. The sources describe campaign scale, tooling class and behaviour, but publish no machine-pivotable values.

Behavioural indicators:

6. Detection

The sources give no file hashes, filenames, command-line flags, mutex names or registry keys. What they do give is a distinctive behavioural pattern on FortiGate devices: account creation and account deletion by an actor who is not the legitimate administrator, and authentication succeeding after credential material has been sourced externally. That is log-shaped, so a Sigma rule is the right instrument. No YARA rule is emitted: there are no file-level artefacts in the source material, and a rule built from product names or campaign names would detect reporting about the threat rather than the threat.

title: FortiGate Administrative Account Created or Deleted Outside Change Process
id: 7f3c1a92-4b6e-4d21-9c8a-2e5f0b7d1a44
status: experimental
description: Detects creation or deletion of FortiGate administrative or VPN accounts, the persistence and lockout behaviour described in the FBI/US Secret Service joint advisory on the FortiBleed campaign.
author: Adverse Trace
date: 2026-10-08
references:

  - https://www.securityweek.com/fortibleed-attackers-locking-victims-out-of-fortinet-devices/
  - https://www.helpnetsecurity.com/2026/10/07/fortinet-fortibleed-campaign-fbi-advisory/
logsource:
  product: fortinet
  service: fortigate
detection:
  selection_account_change:
    action:

      - "add"
      - "delete"
      - "edit"
    logdesc|contains:

      - "Admin user"
      - "User"
  selection_remote:
    srcip|exists: true
  filter_known_admin:
    user|contains:

      - "automation"
      - "svc_"
  condition: selection_account_change and selection_remote and not filter_known_admin
falsepositives:

  - Planned administrative changes performed by authorised staff from a known management network
  - Automation accounts performing scheduled user lifecycle operations
level: high

Tune the filter_known_admin list to your own service and automation account naming before deployment, and correlate hits against your change management records. A hit is only meaningful if no corresponding change ticket exists.

7. Sources

• SecurityWeek, "FortiBleed Attackers Locking Victims Out of Fortinet Devices", https://www.securityweek.com/fortibleed-attackers-locking-victims-out-of-fortinet-devices/, 2026-10-08
• Help Net Security, "FortiBleed is still active, with attackers locking admins out of Fortinet firewalls", https://www.helpnetsecurity.com/2026/10/07/fortinet-fortibleed-campaign-fbi-advisory/, 2026-10-07
• Cybersecurity Dive, "FBI warns that FortiBleed credential-harvesting attacks are locking out firewall users", https://www.cybersecuritydive.com/news/fbi-fortibleed-credential-harvesting-attacks/832366/
• DataBreaches.net, "Active FortiBleed Campaign Impacting Fortinet Devices Across 194 Countries" (citing Arctic Wolf), https://databreaches.net/2026/06/18/active-fortibleed-campaign-impacting-fortinet-devices-across-194-countries/, 2026-06-18
• Dark Reading, "FortiBleed Attackers Turn Firewalls Into Credential Stealers as Heists Persist", https://www.darkreading.com/cyberattacks-data-breaches/fortibleed-attackers-firewalls-credentials-stealers
• BleepingComputer, "FortiBleed credential-theft campaign linked to Lynx ransomware", https://www.bleepingcomputer.com/news/security/fortibleed-credential-theft-campaign-linked-to-lynx-ransomware/
• BleepingComputer, "FortiBleed campaign used custom FortiGate sniffer to steal credentials", https://www.bleepingcomputer.com/news/security/fortibleed-campaign-used-custom-fortigate-sniffer-to-steal-credentials/

8. Adverse Trace position

Adverse Trace assesses this as a high-impact, ongoing campaign against perimeter security infrastructure, with the lockout behaviour raising the operational severity above a straightforward credential compromise: a firm that loses administrative access to its own FortiGate cannot contain the intrusion from that device, and the FBI/USSS advisory confirms attackers delete accounts specifically to prevent that. The 86,644-device figure is SOCRadar's confirmed-compromise count and is the most defensible number available; the 430,000-target and 110 million-credential figures are single-sourced to Dark Reading and we do not treat them as corroborated. Attribution to a Russian initial access broker is reported by SecurityWeek and the ransomware-group links to INC and Lynx are reported by BleepingComputer, but no MITRE ATT&CK profile exists in our reference data for any named actor, so we treat all attribution here as unconfirmed and advise clients not to act on it. We will track the joint advisory's guidance as it is operationalised, watch for any CVE assignment or vendor patch that changes the remediation path, and update this advisory if SOCRadar or the FBI publish device-level indicators that would allow enforcement. Clients running internet-exposed FortiGate or Fortinet SSL VPN should treat the P1 steps in §4 as this week's work, and should confirm they still hold administrative access to every device before assuming a password reset will be sufficient.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.