Network firewalls exist to stop unauthorised traffic from entering a corporate environment. The FortiBleed campaign, active between February and June 2026, turned that assumption inside out. A financially motivated Russian-speaking threat actor gained access to more than 430,000 FortiGate devices and then used those devices to passively collect authentication data from the very traffic flowing through them. By the end of the operation, researchers had identified over 110 million harvested credentials. The tools used were not novel exploits. They were built into FortiOS from the start. Reporting published in June 2026 by The Hacker News brought the full scope of the campaign to public attention.
Most large-scale firewall attacks in recent years have centred on unpatched vulnerabilities. An advisory drops, organisations race to apply a patch, and the window for exploitation closes over a period of weeks. FortiBleed followed a different model entirely. There is no CVE associated with it. No vulnerability was exploited in the traditional sense. The campaign instead abused a legitimate FortiOS capability that any administrator with sufficient access could invoke: the built-in packet diagnostic interface.
This distinction changes how security teams need to think about perimeter defence. Patch compliance alone does not protect against a campaign that operates within the bounds of what the vendor ships. An organisation whose FortiGate devices are running fully current firmware, with no outstanding CVEs, could still have been a FortiBleed victim if its management interfaces were reachable and its administrative credentials were weak or previously compromised. The attack surface here was not software quality; it was access control and credential hygiene.
The implications extend beyond FortiGate specifically. Any network device that ships with diagnostic or monitoring capabilities accessible under administrator credentials presents this class of risk. The question is not only whether the device is patched against known vulnerabilities but whether the access controls protecting those diagnostic capabilities are sufficient to prevent an adversary from using them against you.
At the centre of the FortiBleed operation is a custom-built surveillance tool called FortigateSniffer. It is written in Golang, a choice that delivers two practical advantages for a threat actor: cross-platform compilation from a single codebase and the production of statically linked binaries that carry all their dependencies internally, without requiring any runtime libraries on the host system. Researchers identified both a Windows executable variant and a Unix ELF binary, allowing the tool to be deployed regardless of the underlying operating system configuration of the FortiGate device.
FortigateSniffer does not inject code into the FortiOS kernel or modify system binaries. Instead, it invokes diagnose sniffer packet, a diagnostic command that is a standard part of FortiOS and is used by network engineers to capture traffic on specific interfaces for troubleshooting. The command accepts parameters specifying which interface to monitor, what filter expression to apply, and what verbosity level to use for output. FortigateSniffer uses these parameters to configure passive capture sessions across 24 protocols, covering authentication traffic across a broad range of both cleartext and hashed credential exchange methods.
Capturing at the firewall is strategically superior to placing a sniffer elsewhere on the network. Traffic destined for internal segments, VPN authentication exchanges, and management protocol sessions all either pass through or terminate at the firewall. A sniffer at this position sees authentication events from across the network perimeter in a single capture stream. By the time a credential appears in the captured data, it has already been entered by the user and transmitted; no endpoint-based control could prevent its capture at this stage.
The 24 protocols monitored by FortigateSniffer span a range that includes both legacy protocols transmitting credentials in cleartext and modern protocols transmitting hashed or encrypted credentials. The inclusion of both categories reflects an operationally complete approach: cleartext credentials can be used directly without further processing, while hashed credentials are collected for offline cracking.
The proportion of cleartext versus hashed credentials in a given capture depends heavily on how the target organisation has configured its network. An environment still using LDAP without TLS for directory queries would produce cleartext captures at volume. One that has fully migrated to encrypted authentication protocols would still contribute hashed credentials, which can be subjected to dictionary attacks or brute-force cracking depending on the algorithm used. The FortiBleed actors invested in both capture infrastructure and offline cracking capability to process both categories at scale.
One of the most operationally striking details of the FortiBleed analysis is the pace of the campaign during its most intense phase. Researchers identified 659 separate credential harvesting pipelines launched between 31 May and 15 June 2026, a period of fifteen days. A pipeline, in this context, represents a configured FortigateSniffer deployment on a compromised device that is actively capturing and forwarding credential data to the actor's collection infrastructure.
Launching 659 of these in two weeks implies either a large team operating in parallel or a high degree of automation in the process of gaining access, deploying the tool, and routing collected data. The broader campaign ran from February 2026, which means the May-June burst was a late-stage intensification of an operation already running for three months. That earlier phase presumably covered initial access work, tool development and testing, and the gradual expansion of the victim pool before the final acceleration.
The threat actor behind FortiBleed has been characterised as a Russian-speaking initial access broker (IAB). IABs occupy a specific position in the cybercriminal ecosystem: they specialise in obtaining access to corporate networks and then selling that access to other actors, typically ransomware operators or espionage groups, rather than monetising it directly. The scale of the FortiBleed operation is consistent with a bulk-access model where the actors build inventory at high volume across a large portfolio of victims and then sell access wholesale.
This actor classification matters for threat response. If the organisation that compromised your FortiGate device has already sold that access, the threat is not contained by patching the firewall or removing FortigateSniffer. The purchaser of the access may be an entirely different actor with different capabilities and objectives. Credential rotation following any confirmed FortiBleed exposure must therefore be treated as an active incident response step, not a precautionary measure. The credentials may already be in active use by a downstream actor who purchased them weeks ago.
The campaign shows a concentrated focus on organisations with fewer than 200 employees, with the IT services sector being the most frequently targeted. Researchers identified the United States and India as the most affected regions by device count.
The focus on IT service providers is strategically deliberate. A managed service provider with 50 employees and 50 business clients falls within the sub-200-employee targeting profile while representing access to networks an order of magnitude larger than itself. Compromise a firewall at such a provider and you gain visibility into every client network the provider manages, every remote session it initiates, and every set of credentials used to administer those clients. For an IAB building a credential inventory to sell, one IT service provider can represent access to dozens of downstream organisations simultaneously.
FortiBleed, despite its name, was not a single-vendor operation. The same actor and infrastructure were responsible for automated credential harvesting against Synology NAS devices, Sophos firewalls, Citrix SSL-VPN gateways, Remote Desktop Web (RDWeb) portals, and Microsoft SQL Server instances, with automated brute-forcing of those systems underway since late February 2026.
Amazon Threat Intelligence had separately identified an automated mass scanning campaign targeting FortiGate devices earlier in 2026, attributing it to activity using CyberStrikeAI, an open-source offensive security platform. The timing and targeting overlap with FortiBleed suggests this scanning activity was part of the same actor's initial reconnaissance phase, preceding the credential harvesting operation. The connection implies a structured multi-phase campaign with distinct reconnaissance, access, and exploitation stages rather than an opportunistic operation.
For organisations assessing their attack surface, the multi-vendor scope is a critical data point. An environment that has secured its FortiGate estate but still exposes Citrix or RDWeb without strong authentication controls may face the same actor through a different device type using the same automated brute-forcing infrastructure.
The FortiBleed actors did not simply collect and archive credentials; they validated captured data against the services those credentials protected and cracked hashed passwords through offline processing. Once usable credentials were confirmed, they were applied against Active Directory domains and other exposed services on the same networks.
VPN credentials from a compromised FortiGate allow direct network access to internal segments without triggering perimeter controls, since the actor is authenticating through a legitimate channel. Active Directory credentials support lateral movement across the domain: access to file shares, email systems, internal applications, and eventually privileged accounts if the domain's tiering and separation model is inadequate. Service account credentials are particularly valuable because they tend to carry broad permissions and long lifetimes, making them durable access paths that outlast incident response actions focused on resetting individual user passwords.
Tracking how credentials from a campaign like FortiBleed move through the threat actor ecosystem and appear in downstream incidents is the core function of threat intelligence monitoring. A credential sold to a ransomware operator in July may not be used until October, well after an organisation believes the FortiBleed risk window has closed.
At the time the FortiBleed campaign was reported publicly in June 2026, credentials captured as far back as February were potentially still valid. Many organisations do not enforce mandatory password rotation at regular intervals, particularly for accounts associated with network infrastructure rather than end-user workstations. Service accounts on Active Directory are especially prone to having long password lifetimes because rotating them requires coordinated changes across every system that depends on them, creating operational friction that is routinely deferred.
An organisation that cannot determine whether its specific devices were part of the FortiBleed campaign faces a difficult decision: rotate credentials speculatively at significant operational cost, or accept the risk that previously captured credentials remain usable. Monitoring for compromised indicators of compromise in threat intelligence data that specifically references FortiBleed infrastructure or credential sets is what enables a targeted response rather than a blanket reset across all accounts.
The highest-priority action is auditing management interface exposure. If the FortiGate management interface is reachable from the public internet without VPN or IP allowlisting, it was a credible target during the FortiBleed initial access phase. Restricting management interface access to known administrative IP ranges and requiring multi-factor authentication on all administrative sessions addresses the primary access vector this campaign exploited.
Session logs from FortiGate management interfaces should be reviewed for connections from unfamiliar IP addresses during the February-June 2026 period. Within those sessions, the presence of diagnose sniffer packet commands outside scheduled maintenance windows is the primary indicator that FortigateSniffer was operating on the device. FortiOS logs commands executed during management sessions, and this log data is the most direct evidence for determining whether a specific device was used as a capture node.
Any device identified as potentially compromised should prompt immediate credential rotation covering all accounts whose authentication traffic passed through that firewall: VPN user accounts, Active Directory service accounts reachable via VPN, and any accounts used to authenticate to services the firewall was positioned to observe. Network segmentation that limits what any single perimeter device can observe, combined with encrypted authentication protocols that render cleartext capture irrelevant, reduces the structural exposure that made FortiBleed effective across such a large number of devices.
No. FortiBleed does not exploit a CVE or software defect in FortiOS. The campaign abused the diagnose sniffer packet command, a legitimate diagnostic capability present in all FortiOS versions, to passively capture network authentication traffic. Initial access was obtained through brute-force attacks on exposed management interfaces and through the reuse of previously stolen credentials. A fully patched FortiGate with an internet-exposed management interface and weak credentials remained a credible target.
Look for administrative login sessions from IP addresses not associated with your team, unexpected invocations of diagnose sniffer packet in session command history, new processes or binaries not placed there by FortiOS updates, and outbound connections to IP addresses outside your expected traffic baseline. FortiOS logs commands executed during management sessions, making command history review the most practical first diagnostic step.
Placing the management interface behind a VPN significantly reduces the initial access risk by removing the device from the pool of directly internet-reachable targets the FortiBleed actors scanned. However, if the VPN credentials themselves were previously compromised through another channel, or if the VPN lacks MFA, this architectural protection may not hold. Management interface restriction reduces risk substantially but must be combined with strong authentication to be fully effective.
Yes. The campaign specifically prioritised IT service providers within the sub-200-employee targeting profile. Your exposure includes the networks of every client whose traffic your FortiGate handled or whose credentials were transmitted through your network during the campaign period. A compromise of your firewall may represent the initial access stage for downstream attacks against your clients.
Not necessarily. The tool does not modify core OS files, and its primary evidence appears in command history logs rather than binary modifications. If log retention was limited or logs were not collected centrally, evidence may no longer be recoverable. For IT service providers with internet-exposed FortiGate management interfaces during the February-June 2026 window, treating the situation as potentially compromised and rotating credentials accordingly is the safer operational position.
Fortinet's security research team has published indicators associated with FortiBleed. Contacting Fortinet PSIRT with your device serial numbers and the relevant time period may allow cross-referencing against their data. This is a useful supplementary step, but your own log analysis is the most direct approach and should not wait for a vendor response.
Device replacement is rarely the appropriate response. FortiBleed exploited weak access controls and legitimate diagnostic capabilities, not a hardware defect unique to FortiGate. Replacing the hardware without addressing the access control and credential hygiene conditions that enabled the compromise would not prevent a recurrence. Restricting management interface access, enforcing MFA, rotating exposed credentials, and monitoring for post-compromise indicators are the meaningful mitigations.
FortiBleed illustrates a category of risk that sits outside the conventional vulnerability management model. When a vendor ships a diagnostic capability into a production network device, that capability is built for legitimate use: capturing traffic to diagnose dropped packets, connectivity failures, or protocol mismatches. The same capability, invoked by an adversary with administrative access, becomes a persistent surveillance instrument that operates identically to what a network engineer would see during a troubleshooting session. From the perspective of the device itself, nothing anomalous has occurred.
This is the structural challenge. Security teams invest heavily in detection systems designed to identify anomalous behaviour: traffic to unfamiliar IP addresses, processes not seen before, file modifications outside expected paths. None of those signatures fire on a threat actor running diagnose sniffer packet because the command is expected, the process is legitimate, and the output goes to standard diagnostic log paths. Detection requires a different approach: auditing who invoked the capability, from which IP address, in which session, and whether that session correlates to any scheduled maintenance or documented troubleshooting activity. When the diagnostic command appears in session logs at a time and from an address that cannot be attributed to a known administrative action, that is the anomaly worth investigating.
The lesson is not unique to FortiGate. Network devices from other vendors include equivalent diagnostic capabilities: packet capture interfaces, mirror port configurations, traffic analysis tools, and protocol inspection modes. The common thread is that all of them require only administrative credentials to invoke, and none of them, once invoked, announce themselves to monitoring systems in a form that differs from legitimate use. Building detection around command-level audit logging for privileged diagnostic operations, rather than relying solely on network or endpoint anomaly detection, addresses this gap more directly than any patch cycle can. Understanding the full attack surface of network infrastructure means accounting for what those devices can do, not only for what vulnerabilities they carry.
Attacks like this one rarely announce themselves through official channels first. New payloads, active infrastructure, and exploitation techniques circulate in closed forums and private channels well before any public research surfaces them. By the time an incident makes it into a threat report, organisations without early visibility are already behind.
Defendis gives your security team that early visibility. We monitor the dark web, underground forums, and threat actor channels so your team receives relevant intelligence before it becomes breaking news, with context about emerging threats matched against your organisation's exposure, without requiring your analysts to spend time in places they should not have to go.
