Maritime Cyber Threat Briefing #12
Most maritime cyber incidents announce themselves. A ransomware note appears, an ECDIS position drifts, a booking portal goes dark. FortiBleed is different. It is a compromise that leaves no obvious mark on the victim, that touches devices which appear fully patched and operational, and that has already placed working administrative keys to hundreds of shipping and offshore networks into a criminal marketplace. For the maritime sector, it is one of the most consequential exposures of the year precisely because so many of the affected operators still do not know they are affected.
This briefing sets out what FortiBleed is, why it defeated organizations that believed they had done the right thing by patching, what maritime-specific research has uncovered about the industry’s exposure, and the concrete steps owners, managers, ports and vendors should take now. It builds directly on ground covered in Briefing #3 (SSL-VPN exploitation), Briefing #4 (VSAT and satcom vulnerabilities) and Briefing #11 (Volt Typhoon and the strategic pre-positioning of maritime infrastructure), because FortiBleed sits at the intersection of all three.
Background: the firewall is the front door
Fortinet‘s FortiGate firewalls and SSL-VPN gateways are among the most widely deployed perimeter security devices in the world, and the maritime sector is no exception. They guard the boundary between the public internet and the internal networks of shipping companies, ship managers, offshore contractors, yards and ports. On many vessels, a FortiGate also sits between the satellite link and the onboard network, making it the single most important gatekeeper between a ship and the shore.
That placement is exactly what makes these devices a strategic target. An attacker who holds valid administrator credentials for a perimeter firewall does not need an exotic exploit. They can modify firewall rules, read and redirect VPN traffic, create hidden accounts, disable logging, and use the device as a quiet foothold from which to move deeper into the network.
The firewall is the front door, and FortiBleed is, in effect, a set of copied keys.
The campaign takes its name from Heartbleed, but the comparison is only rhetorical. This is not a single dramatic software vulnerability. It is a large-scale credential theft and validation operation, first surfaced in mid-June 2026 by security researcher Volodymyr “Bob” Diachenko, who discovered an exposed attacker-controlled server, and independently verified by Kevin Beaumont and Hudson Rock. Multiple threat-intelligence firms, including SOCRadar® Extended Threat Intelligence, Arctic Wolf, Recorded Future‘s “Insikt Group” and Bitsight, have since analysed the dataset and the attacker toolchain.
The mechanism: why patched devices stayed exposed
The technical heart of FortiBleed is a credential-storage weakness that survived a security upgrade. It is worth understanding clearly, because the lesson generalises well beyond Fortinet.
For years, FortiGate devices stored administrator passwords as salted SHA-256 hashes. SHA-256 is fast to compute, which is a virtue for many uses and a liability for password storage. A modern graphics-processing cluster can test billions of guesses per second against it, so even long, complex passwords fall in hours. Fortinet addressed this by migrating to PBKDF2, a deliberately slow, cracking-resistant algorithm, across FortiOS versions 7.6.1, 7.2.11 and 7.4.8 released between late 2024 and mid-2025.
The migration carried a critical condition. When a device was upgraded, existing administrator passwords were not automatically re-hashed. They remained in the old, weak SHA-256 format until each administrator logged in again after the upgrade, which triggered the rehash. Worse, the older hash was retained in a hidden configuration field for backward compatibility even after a password was updated. The consequence is the defining feature of this incident: an organisation could apply the patch, believe the matter closed, and still be carrying crackable legacy hashes inside its live configuration.
According to Fortinet’s own analysis, this is not a new vulnerability but the reuse of credentials from prior incidents combined with aggressive brute-forcing against devices with weak password hygiene and no multi-factor authentication. That framing matters for the maritime reader in one specific way: because it is not classed as a formal vulnerability, there is no new CVE and no patch that “fixes” FortiBleed. The remediation is operational discipline, not a software update. A point returned to below.
The attack chain, and why it reads as an industrial operation
The value of FortiBleed to an attacker comes from the systematic way the operation converts exposure into verified, sellable access.
The publicly documented chain, reconstructed from the attackers’ own exposed tooling, runs roughly as follows.
Configuration files were exfiltrated from internet-facing FortiGate devices. The precise initial-access method is unconfirmed, but analysts have identified CVE-2026-24858, a critical FortiCloud single-sign-on authentication bypass added to Cybersecurity and Infrastructure Security Agency‘s Known Exploited Vulnerabilities catalogue earlier in 2026, as the leading candidate. Those configuration files contained the legacy password hashes, and in some cases plaintext credentials outright.
The hashes were then cracked offline on a dedicated 45-GPU cluster managed through Hashtopolis. Because the legacy SHA-256 storage is computationally cheap, this stage is fast and effective. In parallel, the operators replayed enormous volumes of previously leaked and infostealer-harvested credentials against exposed devices. Threat intelligence points to roughly 1.16 billion login attempts against more than 320,000 FortiGate targets, alongside billions more directed at database servers. The credential pools were curated specifically from earlier Fortinet leaks, including the near-500,000 VPN accounts exposed in 2021 and the Belsen Group configuration dump of 2022, meaning the attackers were testing passwords that had already proven valid on Fortinet devices.
Every successful login was verified against the live device and then profiled. This is the signature of an initial access broker: compromised access was catalogued by country, industry, company revenue and headcount, packaged for resale to ransomware syndicates and other buyers. On devices they controlled, the operators deployed an on-box packet-sniffing tool that captured SSL-VPN and other credentials directly from passing traffic as legitimate users signed in, feeding fresh logins back into the operation. From the firewall, the documented path continues into Active Directory and, where segmentation is weak, onward toward operational systems.
I have deliberately kept this at the analytical level rather than reproducing operational detail. The point for defenders is not how to run the attack but what it demonstrates: a mature, revenue-driven access economy is treating perimeter devices as an inventory to be harvested, verified and sold at scale.
Threat landscape: criminal operators, state-grade tooling
Diachenko attributed the operation to a multi-operator, Russian-speaking cybercriminal group, and its behavior. Corporate profiling, resale packaging, an access-broker economy, is consistent with financially motivated crime rather than espionage.
That should not be reassuring. Two factors complicate the picture.
- Verified compromises tied to the surrounding activity reportedly include full network intrusions across several countries and, in one case, the exfiltration of classified documents from a NATO defense contractor. That tells us the harvested access is not staying in low-level hands.
- Bitsight’s analysis of related exploitation identified state-associated tunneling tools, Chisel and Neo-reGeorg, in the toolkits. The same class of living-off-the-land tunneling infrastructure documented in the Volt Typhoon campaign covered in Briefing #11.
This is the strategic through-line. In Briefing #11 the concern was a state actor quietly pre-positioning inside maritime and adjacent infrastructure by living on edge devices. FortiBleed shows the commercial supply chain that feeds the same terrain: criminal brokers industrialise the harvesting of perimeter credentials, and both ransomware crews and state-aligned operators draw from the resulting pool. An exposed maritime firewall credential is therefore not a single risk but an option that can be exercised by very different actors with very different objectives.
Maritime exposure: what the sector-specific research found
The FortiBleed dataset is global, but the maritime slice of it is substantial and has been examined directly by maritime cybersecurity firm Cydome, whose threat-intelligence team cross-referenced the leaked data against the sector.
Cydome identified more than 250 individual maritime and energy organisations whose Fortinet credentials appear in the known dataset, the majority of them shipowners or ship managers. It also found 703 satellite-linked IP addresses associated with satcom service providers serving maritime operations. A figure that spans both vessels and shore sites, and one that connects this incident directly to the VSAT and satellite-link exposure examined in Briefing #4.
The distribution of affected maritime logins is telling. By Cydome’s breakdown, shipping and freight companies account for 41.5%, offshore contractors and service companies 31.2%, newbuild and repair yards 10.7%, and port authorities and logistics firms 6.7%. In the words of Cydome founder and chief executive Nir Ayalon, the pattern is consistent with FortiBleed reaching the operational core of maritime trade rather than only back-office IT.
Two findings from Cydome’s sampling underline how much exposure remains live. Around 87% of the Fortinet devices examined still had internet-facing management interfaces available, and roughly 63% of the harvested credentials related to default or built-in administrator accounts that had never been renamed. Broader analyses of the full dataset found a similar pattern: a clear majority of compromised accounts were either factory-default or used predictable generic names, meaning attackers could target them with high confidence before spending any effort on brute force. This is not, at root, an exotic technical failure. It is a configuration-hygiene failure repeated across thousands of production deployments.
Appearing in the dataset is an exposure indicator, not proof of full compromise. But because the harvest date cannot be known, any credential that has not been rotated since the exposure must be treated as live and exploitable. Cydome has published a free lookup at fortibleedcheck.cydome.io so operators can check whether their domain or IP appears. A matching enterprise-facing lookup is also available through Hudson Rock.
Operational impact: from a cracked firewall to the bridge
For a shipping organisation, the operational consequences track the attacker’s path through the network. On the shore side, a compromised perimeter firewall exposes fleet-management platforms, crewing and payroll systems, chartering and procurement, and the Active Directory environment that underpins all of them. The same category of back-office compromise that has driven recent NIS2-reportable incidents in the sector.
On the vessel side, the concern is more acute. Where a FortiGate sits between the satellite [FBB / VSAT / Starlink] link and the onboard network without clean separation between IT and OT, the documented lateral-movement path can reach toward bridge systems, cargo and ballast management, and the satellite communications equipment itself. A firewall turned into a passive listening post can harvest every VPN credential used for remote support of onboard systems. Precisely the remote-access pathways discussed in Briefing #3 and quietly extend the intrusion each time an engineer or vendor connects.
The realistic impact scenarios follow from there:
- Disruption or manipulation of navigation and cargo systems with direct safety implications
- Loss of confidentiality over commercially sensitive routing, cargo and chartering data
- Ransomware deployment staged from the trusted network edge
- For ports: Disruption to terminal operating systems and logistics flows of the kind examined in Briefing #10.
The financial, regulatory and reputational consequences compound each of these. Critically, none of this requires the attacker to have “hacked” anything in the visible sense. They logged in.
Mitigation: this is remediated by discipline, not a patch
Because FortiBleed is a credential and hygiene problem, the response is operational. The following consolidates the guidance issued by CISA and echoed by Fortinet and maritime specialists into a practical maritime sequence.
- Check exposure first. Use the available lookups to determine whether your domains and satcom-linked IP ranges [ashore and afloat] appear in the dataset. Absence is not a guarantee of safety, only of absence from the public dataset, so treat it as a starting point rather than an all-clear.
- Terminate and rotate. Following CISA’s guidance, terminate all active administrative and VPN sessions and reset every Fortinet VPN and administrator password on internet-facing systems. Do not reuse prior passwords regardless of their complexity, because complexity does not help if the password itself has already been harvested.
- Clear the legacy hashes. This is the step most operators miss. Upgrade FortiOS to a current release and ensure every administrator logs in afterward so the credential is re-hashed under PBKDF2. On FortiOS “7.2.x” and “7.4.x”, enable the password-policy setting that removes retained weaker-encryption hashes. Patching alone, without this step, leaves the weak hash in place.
- Enforce MFA everywhere. Multi-factor authentication on all administrative and remote-access accounts is the single control that most reliably breaks credential replay, and its widespread absence is a primary reason FortiBleed worked.
- Remove management from the public internet. Restrict management interfaces to trusted internal networks or a management VPN, and eliminate internet-facing administration wherever operationally possible. The finding that most affected devices still exposed management interfaces shows how much low-cost risk reduction remains available here.
- Hunt, don’t assume. Review logs for unfamiliar administrator logins, unexpected VPN users, configuration changes and new or oddly named accounts, and compare configurations against a known-good baseline. Because compromise is silent, active threat hunting [not the absence of alerts] is what tells you whether access has already been used.
For fleets, the durable lesson reinforces a theme running through this series: enforce genuine segmentation between vessel IT and OT so that a compromised shore-facing or satellite-facing firewall cannot become a route to the bridge, and extend credential rotation and MFA discipline to onboard devices and vendor remote-access accounts, which are too often left on defaults.
Regulatory and compliance considerations
FortiBleed arrives at a moment when maritime cyber accountability is no longer optional and perimeter hygiene is increasingly treated as a compliance issue, not just a technical one.
Under IMO Resolution MSC.428(98), cyber risk must be managed within the vessel’s safety management system, and an unremediated, internet-facing firewall with default credentials is difficult to reconcile with that obligation. The IACS unified requirements UR E26 and E27, applicable to vessels contracted for construction from 1 January 2024, address the cyber resilience of ships and of onboard systems and equipment respectively. E27’s expectations around the integrity and secure configuration of network devices speak directly to the newbuild and repair yards that make up more than a tenth of the affected maritime population, and to the supply-chain assurance concerns raised in Briefing #7. For operators within scope of the EU’s NIS2 Directive, credential exposure of this kind can trigger incident-notification duties and sits squarely within the risk-management and supply-chain security obligations the directive imposes on essential and important entities. In the United States, the Coast Guard’s maritime cybersecurity requirements for the Marine Transportation System place comparable expectations on access control, patching and network segmentation. Flag and port state regimes increasingly test the same ground.
The common thread is that these frameworks no longer treat perimeter hygiene as a technical detail. Default administrator accounts, absent MFA and exposed management interfaces are now compliance failures as much as security ones. And FortiBleed provides an unusually well-documented external record of which organizations were carrying them.
FortiBleed is not a story about a clever exploit. It is a story about the gap between believing you are secure and being secure.
About upgrades left one step short, default accounts never renamed, and management interfaces left facing the open internet. For a sector as connected and as edge-dependent as shipping, that gap is expensive, because the firewall FortiBleed targets is often the last line between a satellite link and a ship’s bridge.
The maritime findings should be read as a prompt, not a verdict. More than 250 maritime and energy organisations in the dataset, hundreds of satcom-linked addresses, and a clear majority of exposure traceable to default credentials all point to a problem that is broad but also, encouragingly, largely remediable with disciplined action already within every operator’s reach. The uncomfortable part is that appearing [or not appearing] in a public dataset tells you very little about whether your own keys have already been copied. The only reliable answer comes from rotating credentials, clearing legacy hashes, enforcing MFA, pulling management off the internet, and hunting for access that may already have been used.
The resilient operators in twelve months’ time will not be the ones who patched fastest in July 2026. They will be the ones who treated their perimeter as a living surface requiring continuous verification, and who assumed, until proven otherwise, that the keys were already out.
Maritime Cyber Threat Briefing is an independent series covering cyber threats, vulnerabilities, and risk management across the global maritime industry. It is published by Alexandros Engelen, a Cybersecurity Strategist, specializing in maritime cyber risk.
Sourcing disclosure: This briefing draws on the original FortiBleed disclosure by Volodymyr Diachenko and verification by Kevin Beaumont (DoublePulsar) and Hudson Rock; technical analyses by SOCRadar, Arctic Wolf, Recorded Future (Insikt Group), Bitsight and the Cloud Security Alliance; Fortinet’s PSIRT analysis and CISA guidance. And maritime-specific research published by Cydome. Maritime figures, the satcom-linked exposure count and the sector breakdown are as reported by Cydome. Attribution and victim details reflect the assessments of the cited researchers and firms; appearance in the dataset is an exposure indicator, not confirmation of compromise. No confidential or non-public information was used.
