FortiBleed Is Now a Ransomware Pipeline: How FortigateSniffer Turns Your Firewall Into an INC and Lynx Feeder
For six months, roughly half of every internet-facing FortiGate has been quietly forwarding its authentication traffic to a Russian initial access broker, and this week we finally learned who was on the other end. SOCRadar's Threat Research Unit tracked 659 harvest cycles running continuously through mid-June against more than 430,000 FortiGate firewalls, and on July 2 they published the piece we at BlueTeamAutomation had been waiting for: an operator with a live session on one of FortiBleed's staging servers was also logged into the negotiation panels of both INC Ransom and Lynx, running two extortion conversations against organizations whose credentials had rolled through the campaign's sniffer weeks earlier (SOCRadar, The Hacker News). The delay between a stolen VPN login and an encryption event on those campaigns runs 30 to 60 days, so if your FortiGate was reachable from the internet in the first half of 2026, you are inside that window right now.
What FortigateSniffer is quietly doing on your firewall
FortigateSniffer (also seen as fg_sniffer) is a small Go binary for Linux and Windows that does not exploit anything on the FortiGate. It logs in as admin with a credential the campaign already had and invokes a command every Fortinet engineer has typed a hundred times: diagnose sniffer packet, FortiOS's built-in packet capture utility (Fortinet docs). Point it at an interface with a broad filter and verbosity three or four and it dumps every packet, headers and payload, to the SSH terminal in cleartext.
fg_sniffer scripts that command against the WAN and internal interfaces, catches the terminal stream in a Go buffer, and hands it to what SOCRadar named the SNIFTRAN engine, which reassembles the bytes into valid pcapng. A PCAP Deep Analysis Toolkit v5.0 pipeline then pulls credentials from twenty-four authentication protocols in one pass: Kerberos AS-REP and TGS tickets, NTLMv2 challenge responses, RADIUS Access-Requests, LDAP simple binds, MSSQL logins, RDP handshakes, SMB session setups, plus FTP, Telnet, WinRM, and a dozen others (BleepingComputer). The sniffer catches so much because SSL VPN traffic terminates on the firewall itself, so plaintext of every downstream auth attempt is briefly in the clear on the FortiGate's internal segments. Two evasion touches then hide the whole thing: fg_sniffer only runs between 07:00 and 18:00 Moscow Time (04:00 to 15:00 UTC), and it carries a binary-search-indexed ipgeo.csv that skips capture on geographies the operators do not care about, keeping the SSH transcript small enough to dodge naive session-size anomaly rules.
How the operator handed himself over
Initial access is unglamorous. SOCRadar attributes the intrusions to credential reuse (SOCRadar): the operators seeded their scanner with older FortiGate breach dumps and infostealer logs and tested those against every internet-facing FortiGate SSL VPN around the clock. The loop was self-sustaining, since credentials fg_sniffer captured through a compromised firewall fed straight back into the scanner and pried open new appliances the next day. Where a credential was not enough, older FortiOS bugs like CVE-2022-42475, CVE-2023-27997, and CVE-2024-21762 sat waiting on unpatched perimeters (CCCS advisory).
The link to INC and Lynx came out of an exposed staging server, one of about 200 SOCRadar has now enumerated. Researchers pulled logs, target lists, and browser session material off it, and inside those artifacts sat an authenticated session cookie for the same operator on both ransomware panels, running two extortion conversations on the same day against victims whose FortiGate credentials had rolled through fg_sniffer weeks earlier (SecurityWeek, BleepingComputer). The ledger so far: 11,250 scanned portals, 409 admin-access targets, 354 full domain compromises, and at least 12 ransomware deployments.
The CVE-2026-35616 accelerator sitting on your FortiClient EMS
The other half of the campaign hits the management plane. CVE-2026-35616 is an improper-access-control flaw in FortiClient Enterprise Management Server 7.4.5 and 7.4.6, patched in 7.4.7, with the 7.2.x line unaffected. Certain administrative API endpoints on EMS accept requests without checking authorization at all, so any unauthenticated attacker who can reach the console behaves as if signed in as an admin.
Arctic Wolf's exploited-in-the-wild analysis shows the operators using that bypass to suppress firmware upgrade prompts via the remind_upgrade_after config, rewrite the Remote Access Profile, and inject a malicious script block into the endpoint policy (Arctic Wolf). Once the policy replicates, EMS pushes FortiEndpoint_Patch.exe (hosted as p.exe on the C2) down the FortiClient channel and runs it: EKZ Infostealer, a MinGW-compiled Windows credential stealer that lifts Chromium and Firefox password stores, cookies, and saved cards. In a fleet where EMS is trusted to push policy silently, that looks like a routine update and ends in a domain-wide harvest.
Why the traffic looked normal to every control you own
Every step of this fits inside the trust envelope you already granted the vendor, which is why your SOC has probably not paged on it. The SSH admin session is a legitimate maintenance channel most SIEM correlators roll up as noise, and diagnose sniffer packet is a documented troubleshooting utility that appears on no default watchlist we have seen. Only reconstructed credential text and hashes leave the firewall, wrapped in the same TLS used for vendor updates. On EMS, unauthenticated calls return 200 OK because the code path never asked the authorization layer, and the endpoint policy that lands on the workstation is signed by a management server your EDR trusts implicitly. There is no exploit signature to alert on and fg_sniffer never touches disk on the FortiGate; the only footprint is behavioural, spread across three systems most teams monitor in isolation.
What to hunt for on FortiGate, EMS, and inside the domain
Move on three planes in parallel. On the FortiGate, pull admin session logs from FortiAnalyzer and flag admin logins from IP ranges you did not authorize, especially anything resolving to a VPS provider. Grep the CLI accounting log for diagnose sniffer packet with an unlimited count, verbosity three or four, or an unusually wide filter (none, any, or a bare interface). Any admin session that ran the sniffer for more than a couple of minutes without an open support ticket is anomalous, and cross-checking against 04:00 to 15:00 UTC sharpens the signal.
On EMS, check every version banner for 7.4.5 or 7.4.6, then audit the last month of remind_upgrade_after changes, Remote Access Profile edits, and endpoint policy modifications for any that lack an admin login trail. Any policy push authored by "the API" with no console session behind it is your event, and diffing the deployed policy against a known-good backup will surface unexpected script blocks.
Inside the domain, hunt the downstream story: unusual NTLMv2 relay from workstations, Kerberos ticket use where client IP does not match the account's normal source, session cookies replayed across geographies within minutes, and RADIUS successes followed by admin-tier logons. That maps to MITRE ATT&CK T1040, T1552, T1550.002, T1550.003, and T1078; CVE-2026-35616 adds T1190 into T1105 when EKZ lands.
Patch, rotate, and verify before the ransomware clock burns down
Three moves, none of them optional if you were exposed. Upgrade FortiClient EMS to 7.4.7 or newer and verify by replaying the known unauthenticated administrative calls against a lab instance until they return 401 instead of 200. Bring every internet-exposed FortiGate to the latest FortiOS release and close CVE-2022-42475, CVE-2023-27997, and CVE-2024-21762 while you are there. Then rotate every credential that has passed through an internet-facing FortiGate SSL VPN in the last six months: domain accounts, service accounts, RADIUS shared secrets, LDAP bind DNs, and every session cookie your IdP will let you invalidate. Do not skip the RADIUS pre-shared keys; they were in the plaintext transcript too.
What this looks like as a BASzy loop
This is exactly the workflow BASzy automates end to end for us and our customers: continuously simulate a FortigateSniffer-style admin session and a replayed CVE-2026-35616 call against a shadow FortiGate and EMS lab, watch whether the detections you just tuned actually fire in SIEM and EDR, and let SOAR trigger the credential-rotation runbook the moment they do. Proof that a fix held becomes continuous rather than a one-time scramble the week after the story breaks.
Automate the FortiBleed response loop
BASzy runs continuous breach and attack simulation against your perimeter, correlates with your SIEM and EDR, and drives SOAR playbooks when a detection fires. Local-first, on hardware you control.
Explore BASzy →