by datastudy.nl

Field notes for teams tracking critical CVEs and major incidents

Engineering

FortiBleed credential theft reaches the firewall edge

FortiBleed credential theft turns compromised FortiGate firewalls into sniffers. Rotate secrets and hunt traffic capture now.

FortiBleed credential theft scale showing 430,000 FortiGate firewalls targeted, 86,644 compromised devices, and 22,405 unique domains.
FortiBleed credential theft scale: 430,000 FortiGate firewalls targeted, 86,644 compromised devices, and 22,405 unique domains. Source: SOCRadar and BleepingComputer. Data Today benchmark.

FortiBleed credential theft has moved from leaked VPN passwords to a nastier question: what if the firewall you trust to mediate access is also watching credentials flow past it?

The operator risk is simple: patching the box is table stakes, but secret rotation and sniffer hunting decide whether the compromise keeps paying rent.

On June 22, 2026, BleepingComputer reported that SOCRadar found a custom FortiGate sniffer in the FortiBleed campaign, with the operation targeting more than 430,000 FortiGate firewalls worldwide and running since at least February 2026. SOCRadar separately says its FortiBleed dataset contains 86,644 compromised Fortinet devices across 194 countries, more than 80,000 unique IPs, and 22,405 unique domains.

That is the shift to care about. FortiBleed was already a credential exposure story. The new reporting makes it an edge collection story. Attackers reportedly used valid access, SSH, FortiOS diagnostics, packet capture, PCAP reconstruction, parsing, and offline cracking to turn compromised firewalls into credential harvesters.

If you run production systems behind FortiGate, your next move should look less like a patch ticket and more like an incident response sprint.

What did SOCRadar say attackers actually built?

The key tool is FortigateSniffer, a reported Golang-based framework that uses FortiOS diagnostic packet capture after the attacker gets administrative access. BleepingComputer says SOCRadar found the tool abusing the built-in diagnose sniffer packet function to monitor authentication traffic, then extract secrets from protocols including RADIUS, NTLM, Kerberos, and LDAP.

This matters because the diagnostic command is legitimate. It belongs on the appliance. Your detection problem is therefore behavioral, not purely file-based. A firewall running packet capture during a real outage is normal. A firewall running targeted authentication sniffing after an odd SSH admin login from an unknown IP is a five-alarm audit.

The reported pipeline is straightforward and ugly:

  • Compromise FortiGate access through credential stuffing, brute force, or previously exposed credentials.
  • Connect over SSH and launch FortiOS packet capture.
  • Capture authentication traffic across remote access, identity, email, database, and legacy protocols.
  • Reconstruct packet data into PCAP files through a component called SNIFTRAN.
  • Parse the PCAPs with a Python toolkit for cleartext credentials, password hashes, Kerberos tickets, NTLM material, and database secrets.
  • Feed hashes into cracking infrastructure.

BleepingComputer says the sniffer was configured for 24 protocols, including Kerberos, LDAP, SMB, RADIUS, RDP, WinRM, Microsoft SQL Server, MySQL, PostgreSQL, SMTP, IMAP, POP3, FTP, and Telnet. That protocol list is a map of the accidental secrets that still cross too many networks.

SOCRadar's broader FortiBleed FAQ says the campaign uses a two-stage approach: first credential reuse against internet-facing FortiGate devices, then passive harvesting from compromised devices. In the same analysis, SOCRadar says the database has 86,644 compromised devices, and that the attacker verified credentials before recording them.

The chart below shows why operators should avoid treating this as a single leaked-password cleanup. The reported population is large enough to make manual, one-device triage risky, and the compromised count is high enough to assume copycat use of the data.

Horizontal bar chart for FortiBleed credential theft showing 430,000 FortiGate firewalls targeted, 86,644 compromised devices, and 22,405 unique domains.
FortiBleed exposure and compromise counts: 430,000 FortiGate firewalls targeted, 86,644 compromised devices, and 22,405 unique domains. Source: SOCRadar and BleepingComputer. Data Today benchmark.

The important shape is the gap between exposure and confirmed compromise. 430,000 targeted firewalls creates a scanning economy. 86,644 compromised devices creates an access economy. 22,405 unique domains creates a victim-filtering economy. Once a dataset can be sorted by domain, sector, and likely value, an initial access broker has inventory.

Why does credential theft at the firewall change your response?

A firewall sits at a cruelly convenient point in the network. It sees VPN logins, admin flows, identity handshakes, service connections, and a surprising amount of legacy protocol traffic that teams forgot was still there. If an attacker owns that vantage point, rotating only the FortiGate admin password may leave stolen downstream secrets untouched.

Fortinet's June 19, 2026 PSIRT post says the company believes the activity involves credentials from previous incidents and brute-force techniques, and Fortinet recommends terminating admin and VPN sessions, resetting credentials, enforcing MFA, upgrading to FortiOS 7.4, 7.6, or 8.0, validating configuration, reviewing logs, and restricting external management access. That statement is useful because it frames recovery around credentials and configuration, not just firmware.

The sniffer reporting raises the bar again. You should rotate secrets that could have crossed the device during the compromise window, especially if you still have any cleartext or weakly protected authentication on paths through the firewall. RADIUS shared secrets, LDAP bind accounts, service accounts used by monitoring tools, database credentials, and email protocol passwords deserve the same urgency as VPN credentials.

There is a business consequence here. A FortiGate compromise can become a credential broker for the rest of the company. That means the blast radius includes your IAM backlog, your service account hygiene, your SIEM retention, and your ability to prove which flows crossed the appliance during the suspected window.

If you already started from our Fortinet credential reset plan, keep going, but add packet-capture hunting and downstream secret inventory. The reset plan handles the exposed keys. The sniffer angle asks whether the attackers minted new keys while they were inside.

For builders, the lesson lands in three places:

  • Codebase: remove plaintext auth and legacy protocol dependencies from paths that cross perimeter gear.
  • Roadmap: prioritize service account rotation automation over another dashboard nobody opens at 2 a.m.
  • Moat: treat network-edge hardening as reliability work, because stolen admin access can become customer-facing downtime without touching your app code.

The uncomfortable part is that FortiGate may have done exactly what an administrator asked it to do. The wrong administrator asked.

How should you hunt for FortiGate sniffers this week?

Start with a time box. BleepingComputer says SOCRadar reported activity since at least February 2026, so use February 1, 2026 as a practical lower bound unless your own exposure data points earlier. Pull FortiGate admin logs, SSH access logs, configuration changes, CLI command logs where available, VPN events, and domain controller authentication logs for that window.

Your first pass should look for evidence of packet capture and odd administrative use:

  • Unexpected SSH logins to FortiGate appliances.
  • Admin sessions from IPs outside known jump hosts, MSP networks, or break-glass ranges.
  • Use of diagnose sniffer packet outside approved maintenance tickets.
  • Large or repeated packet capture output, PCAP staging, or outbound transfers from management networks.
  • New or renamed administrator accounts.
  • Configuration changes involving local users, VPN users, trusted hosts, local-in policy, logging, or remote management.
  • Authentication spikes against LDAP, RADIUS, Kerberos, NTLM, SMB, RDP, WinRM, SQL, SMTP, IMAP, POP3, FTP, or Telnet.

Fortinet specifically tells impacted customers to compare configuration against a known-good baseline and pay attention to unrecognized accounts such as forticloud, fortiuser, fortinet-support, and fortinet-tech-support. If your baseline process cannot answer that comparison quickly, that is a production weakness, not a paperwork problem.

Next, split your response into two lanes.

Lane one is appliance containment. Terminate active admin and VPN sessions. Remove public admin exposure. Restrict management to trusted hosts or a local-in policy. Upgrade supported FortiOS versions. Preserve logs before rebooting or rebuilding. If you see unauthorized configuration changes, treat the appliance as compromised and rebuild from a validated baseline.

Lane two is secret containment. Rotate FortiGate admin passwords, VPN passwords, FortiCloud credentials tied to management, RADIUS shared secrets, LDAP bind passwords, privileged service accounts, database credentials seen from segments behind the firewall, and any credentials used by MSP or monitoring tooling. Prioritize secrets that are reusable, privileged, or long-lived.

CISA's internet exposure guidance tells organizations to change default passwords, keep exposed systems patched, use jump hosts, monitor ingress and egress traffic, and implement MFA for internet-accessible assets. That advice is broad, but FortiBleed makes it painfully specific: public management plus reused credentials gives attackers an appliance with a front-row seat.

Do not wait for a perfect IOC list. Lists age fast. Behavior ages slower.

What should you rotate, and what can wait?

Use a blast-radius order, not an org-chart order. The team that owns the firewall may not own the secrets the firewall saw.

First 24 hours:

  • FortiGate local admin accounts.
  • SSL VPN user passwords and sessions.
  • FortiCloud and FortiManager credentials connected to the affected estate.
  • RADIUS shared secrets and LDAP bind accounts.
  • Any break-glass account used for edge administration.
  • MSP, contractor, or monitoring accounts with remote access.

Next 72 hours:

  • Service accounts authenticating across segments that traverse FortiGate.
  • Database accounts for Microsoft SQL Server, MySQL, and PostgreSQL flows visible at the edge.
  • Email protocol credentials for SMTP, IMAP, and POP3 where still in use.
  • Windows remote administration credentials tied to RDP or WinRM.
  • Kerberos and NTLM exposure paths, with special attention to weak service account passwords.

After that, kill the conditions that made the theft useful. Disable Telnet and FTP. Replace legacy email auth. Move admin access behind a hardened jump host. Make MFA mandatory for admin and VPN accounts. Reduce long-lived shared secrets. Give network devices the same secret rotation discipline you expect from cloud infrastructure.

The cost argument is obvious: this is annoying and disruptive. The counterargument is stronger: a stolen service account can outlive an appliance rebuild by months. If attackers captured hashes and cracked them offline, your clean firewall can still sit behind dirty credentials.

Kevin Beaumont's analysis, as summarized by BleepingComputer, says attackers may also have downloaded FortiGate configuration files and cracked extracted hashes with 36 enterprise-class GPUs. You do not need to validate that exact path in your environment to act on the implication. Configuration files are sensitive material. Treat them like credential stores.

What should you watch next?

Watch for three signals.

First, look for criminal reuse. SOCRadar says the FortiBleed dataset is organized by country, sector, and organization revenue, which is the sort of structure that makes access easier to sell or route to ransomware crews. If leaked FortiGate credentials begin appearing in broader breach forums or access markets, organizations that delayed rotation will lose the time advantage they still have.

Second, watch for copycat tooling. The technique relies on legitimate FortiOS diagnostics, so defenders should assume other actors can reproduce the idea. The specific FortigateSniffer implementation matters less than the pattern: valid admin access plus packet capture plus credential parsing.

Third, watch your own management plane. If FortiGate admin access is still exposed to the internet on June 23, 2026, the fix is no longer a future architecture project. Remove it or put it behind controlled access. Public edge admin is operational debt with a countdown timer.

This is also a useful moment to check adjacent Fortinet exposure. FortiBleed follows earlier Fortinet credential and edge-device incidents, and attackers love estates where one appliance family has been treated as a static box instead of a living production system. Inventory matters. Log retention matters. Config diffing matters. Secret rotation matters most.

The bet to make: assume credential reuse will remain a profitable attacker workflow through 2026, especially against network edge devices with public management surfaces.

The bet to avoid: assuming a vendor patch or a single password reset closes the incident. FortiBleed's reported sniffer behavior means the thing stolen from the firewall may be credentials for systems the firewall merely watched.

The edge is no longer just a gate

A compromised firewall is a privileged observer. FortiBleed turns that observer into a collector.

That is the practical lesson for operators. Secure the FortiGate, then chase every credential that passed through it. The attacker does not need your whole network if your edge device quietly hands them the next password.

Sources