FortiBleed Campaign Still Active: FBI and Secret Service Warn Fortinet SSL VPN Exploitation Is Driving Lockouts and Ransomware — Detection and Remediation Guide

The FBI and U.S. Secret Service have issued a fresh warning to Fortinet customers: FortiBleed, the SSL VPN exploitation campaign first publicly uncovered this past summer, remains an active, ongoing threat. This is not a rehash of an old advisory — federal investigators are telling us, in plain language, that threat actors are still successfully compromising Fortinet edge devices, and the downstream impact is severe: attackers can lock legitimate users and administrators out of their own environments, and the access gained is being converted into encryption-based attacks — i.e., ransomware.

If you operate FortiGate firewalls with SSL VPN exposed to the internet — and most mid-market and enterprise environments do — you should treat this as an active intrusion scenario, not a patching reminder. In my experience leading ransomware IR engagements, edge-device compromise followed by deliberate account lockout is a hallmark of mature intrusion teams: they take the keys, change the locks, and then begin staging encryption. Organizations that discover the lockout phase are often hours — not days — from detonation.

This post breaks down what defenders need to know, how to hunt for this activity in your environment today, and exactly what to do about it.

What Is at Risk

• Affected products: Fortinet FortiGate next-generation firewalls running FortiOS with the SSL VPN service enabled and reachable from the internet. FortiManager and FortiAnalyzer appliances in management roles should also be reviewed, as they are frequent secondary targets once edge access is obtained.
• Affected organizations: Any organization with unpatched, end-of-support, or externally exposed FortiGate SSL VPN interfaces. Sectors repeatedly hit in these campaigns include healthcare, manufacturing, financial services, local government, and managed service providers — the classic ransomware target profile.
• Impact: Theft of VPN authentication material, unauthorized administrative access to the firewall, creation of rogue admin accounts, disabling or locking out of legitimate administrative access, internal reconnaissance, lateral movement, and ultimately domain-wide encryption and data extortion.

The federal warning's emphasis on user lockout deserves attention. When an attacker with administrative control of your edge device changes passwords, disables accounts, or modifies authentication policies, they are buying dwell time and degrading your ability to respond. In several ransomware cases I have worked, the first ticket in the queue was "VPN admins locked out" — and the encryption started the same weekend.

Technical Analysis: How the Attack Chain Unfolds

While the federal alert does not assign a new vulnerability identifier to this campaign, the FortiBleed tradecraft follows a well-established pattern against Fortinet SSL VPN infrastructure that every defender should understand from an observability standpoint.

Stage 1 — Initial Access via the SSL VPN Attack Surface

FortiGate SSL VPN has been one of the most heavily exploited enterprise attack surfaces of the past several years, precisely because it sits at the perimeter, terminates authentication, and is frequently under-patched due to the operational risk and downtime anxiety associated with firewall firmware upgrades. Threat actors scan the internet at scale for exposed SSL VPN portals (typically TCP/443 with the /remote/login path) and target known, previously disclosed FortiOS vulnerabilities — particularly in devices running firmware trains that have reached end of engineering support and will never receive fixes.

Stage 2 — Credential and Session Material Theft

The defining behavior of the FortiBleed campaign is the extraction of authentication material from the device itself. Successful exploitation of the SSL VPN component can allow an unauthenticated attacker to read system files from the appliance — including files containing VPN session data and credentials. With valid session tokens or cleartext credentials in hand, the attacker no longer needs the vulnerability: they simply log in as a legitimate user. This is why patching alone is insufficient for any device that was exposed and unpatched for a period of time — you must assume credentials were harvested and rotate everything.

Stage 3 — Persistence and Administrative Control

Post-exploitation tradecraft consistently observed in Fortinet edge-device intrusions includes:

• Creation of rogue local administrator accounts on the FortiGate (often with bland, legitimate-looking names such as admin1, support, svc_backup, or names mimicking existing admins with a character changed).
• Modification of authentication settings — pointing the device at attacker-influenced LDAP/RADIUS, or disabling MFA enforcement on VPN portal settings.
• Lockout of legitimate administrators — changing passwords on existing admin accounts or deleting them outright, which is the specific behavior called out in the federal warning.
• Configuration tampering — adding firewall policies permitting inbound access from attacker infrastructure, creating new VPN users, and in some cases planting malicious firmware implants or scripts that survive reboots.

Stage 4 — Internal Operations and Encryption

From the firewall, attackers pivot inward. Typical post-compromise behavior we hunt for in IR engagements:

• RDP/SMB lateral movement using harvested domain credentials.
• Enumeration of domain admins, backup infrastructure (Veeam servers are a priority target), and virtualization management planes.
• Deletion of Volume Shadow Copies and backup catalog tampering immediately before encryption.
• Mass deployment of a ransomware payload via GPO, PsExec, or the compromised management plane.

Exploitation Status

This is confirmed, ongoing, in-the-wild exploitation — that is the entire point of the FBI/Secret Service warning. This is not a theoretical or proof-of-concept scenario. Treat any internet-exposed FortiGate running outdated firmware as potentially already compromised until proven otherwise through forensic review.

Detection & Response

The detections below are built around the observable behaviors of this campaign: shadow copy destruction and backup tampering preceding encryption, rogue local account creation on endpoints after lateral movement, anomalous FortiGate SSL VPN and administrative log activity, and the mass account lockout behavior highlighted in the federal alert.

Sigma Rules

---
title: Volume Shadow Copy Deletion - Ransomware Staging
description: Detects deletion or resizing of Volume Shadow Copies via vssadmin, wmic, diskshadow, or PowerShell, a consistent precursor to ransomware encryption observed in FortiBleed-linked intrusions after initial Fortinet edge compromise.
references:
  - https://cyberscoop.com/fortibleed-fortinet-vpn-ransomware-fbi-warning/
  - https://attack.mitre.org/techniques/T1490/
author: Security Arsenal
date: 2026/02/11
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\vssadmin.exe'
      - '\wmic.exe'
      - '\diskshadow.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_cli:
    CommandLine|contains:
      - 'delete shadows'
      - 'shadowcopy delete'
      - 'shadowstorage'
      - 'Delete-WmiObject win32_shadowcopy'
      - 'Remove-WmiObject win32_shadowcopy'
      - 'Get-WmiObject Win32_Shadowcopy'
  condition: selection_img and selection_cli
falsepositives:
  - Legitimate backup administrators performing shadow storage maintenance (rare; whitelist specific admin hosts)
level: high
---
title: Local Administrator Account Creation via Command Line
description: Detects creation of local user accounts and addition to the local Administrators group via net.exe or PowerShell, matching the rogue-account persistence behavior observed after Fortinet edge device compromise and lateral movement.
references:
  - https://cyberscoop.com/fortibleed-fortinet-vpn-ransomware-fbi-warning/
  - https://attack.mitre.org/techniques/T1136/001/
author: Security Arsenal
date: 2026/02/11
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection_net:
    Image|endswith:
      - '\net.exe'
      - '\net1.exe'
    CommandLine|contains:
      - ' user '
      - ' localgroup '
    CommandLine|contains:
      - ' /add'
  selection_ps:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains:
      - 'New-LocalUser'
      - 'Add-LocalGroupMember'
  filter_admin_workstations:
    User|contains:
      - 'SCCM'
      - 'svc_software'
  condition: (selection_net or selection_ps) and not filter_admin_workstations
falsepositives:
  - Provisioning and imaging tooling creating accounts; whitelist known deployment service accounts and management hosts
level: high
---
title: BCDEdit Boot Configuration Tampering - Recovery Disablement
description: Detects use of bcdedit to disable recovery mode or ignore boot failures, a common ransomware pre-encryption step following initial access via compromised edge VPN infrastructure.
references:
  - https://cyberscoop.com/fortibleed-fortinet-vpn-ransomware-fbi-warning/
  - https://attack.mitre.org/techniques/T1490/
author: Security Arsenal
date: 2026/02/11
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\bcdedit.exe'
    CommandLine|contains:
      - 'recoveryenabled'
      - 'ignoreallfailures'
      - 'bootstatuspolicy'
  condition: selection
falsepositives:
  - Rare; some hardening or kiosk build scripts modify boot policy
level: high

KQL — Microsoft Sentinel / Defender

The first query hunts your FortiGate syslog/CEF telemetry (ingested via the Fortinet data connector into CommonSecurityLog) for the highest-signal edge indicators: SSL VPN logins from source IPs never seen in the prior 30 days, failed-login bursts consistent with brute force or lockout events, and administrative/configuration activity — including the rogue admin account creation and lockout behavior emphasized in the federal alert. The second query hunts endpoint telemetry for the ransomware staging behaviors that follow a successful edge compromise.

// Hunt 1: FortiGate SSL VPN anomalies and admin tampering (Fortinet CEF/Syslog via CommonSecurityLog)
let lookback = 30d;
let window = 24h;
let known_vpn_sources =
    CommonSecurityLog
    | where TimeGenerated between (ago(lookback + window) .. ago(window))
    | where DeviceVendor == "Fortinet"
    | where DeviceEventClassID in ("sslvpn_login", "32000", "32001") or Message has_any ("sslvpn", "SSL VPN")
    | summarize by SourceIP;
CommonSecurityLog
| where TimeGenerated > ago(window)
| where DeviceVendor == "Fortinet"
| extend Action = coalesce(Activity, DeviceAction)
| extend Detail = coalesce(Message, AdditionalExtensions)
| extend NewVpnSource =
    case(
        Detail has_any ("sslvpn", "tunnel-up", "SSL VPN") and SourceIP !in (known_vpn_sources) and isnotempty(SourceIP), "VPN login from never-before-seen source IP",
        Detail has_any ("admin login", "Administrator login", "gui login") and SourceIP !in (known_vpn_sources) and isnotempty(SourceIP), "Admin GUI login from new source IP",
        Detail has_any ("Add", "add") and Detail has_any ("user", "admin", "administrator"), "Possible rogue admin/user account created",
        Detail has_any ("edit", "delete") and Detail has_any ("system admin", "administrator"), "Admin account modified or deleted - possible lockout",
        Detail has_any ("config", "configuration") and Action has_any ("edit", "change"), "Firewall configuration changed",
        Action =~ "login failed" or Detail has "login failed", "Failed login",
        "other"
    )
| where NewVpnSource != "other"
| summarize EventCount = count(), DistinctSources = dcount(SourceIP), DistinctUsers = dcount(SourceUserName), SampleDetail = take_any(Detail)
    by NewVpnSource, SourceIP, SourceUserName, DestinationHostName, bin(TimeGenerated, 1h)
| order by TimeGenerated desc;
// Hunt 2: Endpoint ransomware staging after edge compromise - shadow deletion, recovery disablement, rogue local admins
union
(DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where (FileName in~ ("vssadmin.exe","wmic.exe","diskshadow.exe","bcdedit.exe")
    and ProcessCommandLine has_any ("delete shadows","shadowcopy delete","shadowstorage","recoveryenabled no","ignoreallfailures","bootstatuspolicy"))
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine),
(DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where FileName in~ ("net.exe","net1.exe","powershell.exe","pwsh.exe")
    and ProcessCommandLine has_any ("localgroup administrators","New-LocalUser","Add-LocalGroupMember") and ProcessCommandLine has "add"
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine)
| order by TimeGenerated desc;

Velociraptor VQL

This hunt sweeps endpoints for live evidence of the post-compromise staging chain: shadow-copy destruction processes, net.exe/net1.exe account creation, and suspicious processes executing from user-writable or staging directories — the latter being where ransomware payloads and tooling are commonly dropped after VPN-sourced lateral movement.

-- Hunt: FortiBleed post-compromise staging - shadow deletion, rogue account creation, staging-directory execution
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE
  (
    Name =~ '(?i)vssadmin|wmic|diskshadow|bcdedit'
    AND CommandLine =~ '(?i)delete shadows|shadowcopy|shadowstorage|recoveryenabled|ignoreallfailures|bootstatuspolicy'
  )
  OR
  (
    Name =~ '(?i)^net(1)?\.exe$'
    AND CommandLine =~ '(?i)(user|localgroup).*(/add|administrators)'
  )
  OR
  (
    Exe =~ '(?i)(\\users\\public\\|\\programdata\\[^\\]+\.exe$|\\appdata\\local\\temp\\|\\windows\\temp\\)'
    AND NOT Name =~ '(?i)teams|onedrive|chrome|edge|spotify|slack'
  )

Remediation & Verification Script

Run the following verification and hardening commands directly on each FortiGate (via SSH/console) and from a management host. The script inventories firmware version, enumerates all local admin and VPN user accounts for unauthorized entries, checks for unexpected configuration changes, and confirms SSL VPN exposure. Review every account and every set line that differs from your known-good configuration baseline — in edge-device intrusions, the rogue admin account is the smoking gun.

#!/bin/bash
# FortiBleed verification & hardening checklist - run commands on each FortiGate via SSH
# Usage: ssh admin@<fortigate_ip> and paste/execute each section, or use an expect wrapper in a controlled maintenance window.

set -euo pipefail

FW="${1:?Usage: $0 <fortigate_ip>}"
ADMIN_USER="${2:-audit_admin}"

echo "=== [1] Firmware version and build - compare against current Fortinet PSIRT fixed-release table ==="
ssh "${ADMIN_USER}@${FW}" 'get system status | grep -E "Version|Build|Serial"'

echo "=== [2] Enumerate ALL local administrator accounts - flag anything not in your approved inventory ==="
ssh "${ADMIN_USER}@${FW}" 'show system admin | grep -E "edit |set accprofile|set trusthost|set password"'

echo "=== [3] Enumerate local VPN users - flag unexpected accounts (svc_, backup, support, admin1, etc.) ==="
ssh "${ADMIN_USER}@${FW}" 'show user local | grep -E "edit |set type|set status"'

echo "=== [4] Check for admin trusthost restrictions - unrestricted (0.0.0.0/0) admin access is a red flag ==="
ssh "${ADMIN_USER}@${FW}" 'show system admin | grep -E "trusthost"'

echo "=== [5] Review recent admin login and config-change events from device memory ==="
ssh "${ADMIN_USER}@${FW}" 'execute log filter category event; execute log filter field subtype system; execute log display' | tail -n 100

echo "=== [6] Confirm SSL VPN status and listening interfaces ==="
ssh "${ADMIN_USER}@${FW}" 'show vpn ssl settings | grep -E "set status|set port|set source-interface|set servercert"'

echo "=== [7] Check for unexpected firewall policies permitting inbound access (attacker-added rules) ==="
ssh "${ADMIN_USER}@${FW}" 'show firewall policy | grep -E "edit |set srcintf|set dstintf|set srcaddr|set dstaddr|set action|set status"'

echo "=== [8] Verify auto-install / firmware integrity and check for unexpected scheduled scripts (implant persistence) ==="
ssh "${ADMIN_USER}@${FW}" 'show system auto-script; diagnose sys flash list 2>/dev/null | head -n 20'

echo ""
echo "=== MANUAL ACTIONS REQUIRED ==="
echo "1. If firmware is not on a currently supported, patched FortiOS train: schedule emergency upgrade per Fortinet PSIRT advisories."
echo "2. Rotate ALL credentials that ever transited this device: VPN user passwords, LDAP binds, admin passwords, RADIUS secrets, API keys."
echo "3. Enforce MFA on all SSL VPN logins (FortiToken or SAML/IdP with MFA) - do not rely on password-only VPN auth."
echo "4. Restrict admin GUI access to dedicated management subnets via trusthosts and local-in policies; never expose admin GUI to the internet."
echo "5. If the device was exposed AND unpatched for any period: treat as compromised - full config audit, credential rotation, and consider factory reset + clean rebuild from a known-good config."
echo "6. Disable SSL VPN entirely if migrating to IPsec or ZTNA; remove the attack surface rather than maintaining it."

Remediation

Prioritize these actions in order. The first two are urgent for every Fortinet customer; the remainder are for organizations that find evidence of exposure or compromise.

1. Patch every FortiGate to a currently supported, fixed FortiOS release immediately. Consult the Fortinet PSIRT advisories for the fixed-release table applicable to your firmware train. Devices running firmware trains that have reached end of engineering support will never receive fixes — these must be upgraded or replaced. Pay particular attention to Fortinet's standing guidance to upgrade rather than attempt to live indefinitely on patched-but-aging branches.

2. Rotate all credentials that have ever transited the device — regardless of whether you find evidence of compromise. FortiBleed's core behavior is theft of authentication material from the appliance. Patching closes the hole; it does not invalidate credentials the attacker already stole. Rotate VPN user passwords, all local and remote admin passwords, LDAP/RADIUS bind accounts and shared secrets, SNMP strings, and any API tokens. Enforce a password change for all VPN users at the directory level.

3. Audit for persistence and lockout indicators. Enumerate every local admin and VPN user account against an approved inventory. Review configuration change logs for unauthorized edits. Check firewall policies for rules you did not create. If legitimate admin accounts were disabled or had passwords changed (the lockout behavior called out in the federal alert), treat the device as compromised and escalate to full IR.

4. If compromise is confirmed or suspected: rebuild, do not clean. Edge-device implants can survive reboots and partial remediation. The defensible path is factory reset, firmware re-flash to a fixed release, and restoration from a known-good configuration taken before the exposure window — followed by the credential rotation in step 2.

5. Reduce the attack surface permanently. Enforce MFA on all SSL VPN logins without exception. Restrict administrative GUI access to management subnets via trusthost settings and local-in policies — the admin GUI must never be internet-reachable. Disable SSL VPN entirely where IPsec or a ZTNA solution can replace it. Apply the principle that your perimeter device is the first thing an attacker touches and the last thing you can afford to leave unpatched.

6. Report and engage. If you identify evidence of FortiBleed-related compromise, report to the FBI via your local field office or IC3.gov, and engage your IR retainer immediately — particularly given the campaign's demonstrated path to ransomware deployment. The window between edge compromise and domain-wide encryption in these intrusions is frequently measured in days.

The Bottom Line

Federal agencies do not re-issue warnings about campaigns that have burned out. The FortiBleed alert is a signal that exploitation is succeeding in the field right now — against organizations that assumed an old, familiar patch cycle had covered them. If your FortiGates are running anything other than a current, fixed FortiOS release, if SSL VPN is internet-exposed without MFA, or if you have not rotated edge-device credentials since this campaign surfaced last summer, you have work to do this week — not this quarter.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub