Maritime Cyber Threat Briefing:
#Special Edition
This special edition briefing takes a more practical and operational perspective than previous articles in this series. The intention is not to demonstrate “how to hack a vessel,” but to clearly illustrate [using documented research and real-world findings] how maritime cyber attacks actually unfold in practice. Understanding these pathways is essential for evaluating risk, challenging assumptions, and implementing effective controls.
A note on methodology and intent: This special edition departs deliberately from the analytical format of the regular briefing series. It is written for maritime industry professionals & ship owners, technical superintendents, fleet managers, and security officers. Those who need to understand not just that vessel cyber attacks occur, but specifically how they occur and what they look like in practice. The methodology described here draws exclusively on published, authorised penetration testing research conducted by professional security firms on operational vessels with the explicit permission of owners and manufacturers. Understanding attack methodology at this level of detail is the prerequisite for making informed decisions about vessel security investment, evaluating the claims of security providers, and asking the right questions during audits and assessments. It is published in this spirit and for this purpose.
There is a conversation that happens regularly in boardrooms, on bridges, and in fleet management offices around the world. It usually begins with a question about whether a particular vessel, fleet, or organisation has been protected against cyber attack. The answer that comes back is some variation of “we have antivirus, our bridge systems are separate, our IT is managed”. It also reflects a profound misunderstanding of the actual attack surface of a modern commercial vessel.
This article does not deal in theory. Everything described here & every scenario, every technique, every outcome has been documented in published security research, disclosed by authorized penetration testing teams, or confirmed in incident investigations. The question is not whether these attacks are possible. They have been performed. The question is whether the operator knows it.
The Attacker Starts Before You Expect
Most maritime cyber security thinking begins at the vessel boundary: the VSAT antenna, the USB port, the crew laptop. But a sophisticated attacker begins considerably further back, from the comfort of their own workstation, using tools that are freely and legally available to anyone.
The first tool is Shodan: a search engine that indexes internet-connected devices globally, including satellite communication terminals aboard vessels at sea. The search query “SAILOR 900” referencing the Cobham Satcom SAILOR 900 VSAT [one of the most widely deployed satellite terminal platforms in commercial shipping] returns hundreds of results. Each result includes the terminal’s IP address, the organisation operating it, the port it is listening on, and in many cases the firmware version it is running.
[Following Screenshot]: Shodan reconnaissance simulation — what the attacker actually sees.
[Following Screenshot]: What Shodan Exposed without any authentication:
By combining Shodan data with publicly available AIS position data, it is possible to build a clickable map of potentially vulnerable ships with their real-time positions. Simply by correlating the firmware version running on a vessel’s satellite terminal with its identity and current location.
The reconstruction above shows exactly what this looks like in practice. Within seven minutes, the documented timeframe from real research: an attacker has identified a specific vessel, confirmed its VSAT terminal is exposed on the public internet, noted the outdated firmware version, cross-referenced the terminal’s GNSS coordinates against AIS data to identify the vessel by name, and established that its cargo type and ETA at the next port are publicly broadcast. No vessel system has been touched. No crew member has received a suspicious message. The operator has no indication that any of this has occurred.
Search for “html:commbox” on Shodan and a collection of KVH CommBox terminals appears, missing TLS on the login, with the vessel name visible in the page footer before authentication. Requesting “/rest.php?action=QCgetActiveUsers” returns a list of all crew members currently online, their names, and enough information to build a targeted phishing profile.
The crew member identified in Pen Test Partners’ documented research: a deck cadet [whose CommBox terminal exposed his name and activity] had his Facebook profile located within moments. His vessel was in the Malacca Strait heading for Brazil. His personal details were visible. He was, in the researchers’ words, “ripe for phishing.”
This is reconnaissance. It costs nothing. It requires relatively modest technical skill and can be performed with publicly available tools and documentation. And it produces a complete intelligence picture of a vessel, its crew, its cargo, and its technical vulnerabilities before a single attack packet has been sent.
The Entry Points: Four Documented Pathways to the Bridge
Once reconnaissance is complete, the attacker has multiple validated pathways to initial access. Each has been demonstrated in controlled conditions by authorised security researchers. None of them require the attacker to be physically near the vessel.
Pathway 1: Default VSAT credentials
Using the username “admin” and the password “1234”, a security researcher was able to access the communication centre of a ship as it made its way through South American waters. The satellite communication provider at the centre of this access was Cobham Satcom and the default credentials for their SAILOR 900 VSAT are publicly documented in the vendor manual, available to download from the internet.
[Following Screenshot]: Now the VSAT admin panel: what the attacker sees after typing admin/1234:
The VSAT admin panel reconstruction above shows what full administrative access looks like once those credentials are accepted. The attacker can view the vessel’s real-time GNSS position, see every crew account and their last login time, access the network configuration, enumerate all devices on the internal network [including the IP address of the ECDIS] upload custom firmware, modify routing rules, enable FTP access, and launch a remote shell. The vessel’s crew has no indication that a third party is now on their network with the same access level as the system administrator.
In a documented real-world test conducted outside a controlled demo environment, a vessel belonging to a very large multinational corporation was located in seven minutes. It had the default username and password still in effect on the VSAT system. The VSAT modem was then accessed using default SSH credentials, with publicly available usernames and passwords, achieving command-line access and allowing direct alteration of the system configuration.
This is not a theoretical vulnerability. It is a documented real-world outcome. And it continues to occur because service providers [some managing thousands of vessels] still employ engineers who fail to remove default credentials on installation.
Pathway 2: Phishing the captain
Naval Dome’s security team [led by the former Head of the Israeli Naval C4I and Cyber Defense Unit] demonstrated penetration of a vessel’s ECDIS simply by sending an email to the captain’s computer. The attacking file was transferred to the ECDIS in the first chart update. The attacking file identified the USB device used for updates and installed itself on the ECDIS automatically.
The attack vector exploited the routine nature of chart updates. ECDIS systems require weekly updates to electronic navigational chart data. Those updates arrive via USB drive or network connection. The captain performs this task routinely, without suspecting that the update file might carry a payload. The malware installed silently on the ECDIS. The system continued to function normally. The Officer of the Watch saw nothing unusual on the navigation display.
The crew member targeted by phishing does not need to be the captain. The CommBox research identified deck cadets, engineers, and officers as equally viable targets. 83% of phishing emails targeting multinational crews are now AI-generated, written in native languages and tailored to cultural nuances: making them significantly harder to identify as malicious compared to the grammatically imperfect phishing emails of earlier years.
Pathway 3: The infected USB drive
The USB drive is the most persistent and least glamorous attack vector in maritime cyber security. Chart updates, software patches, and data transfers between systems aboard vessels routinely use removable media. The bridge workstation that receives the ECDIS chart update USB may also be connected to the vessel’s internal network. The ECDIS itself may have exposed USB ports physically accessible to any crew member or visiting technician.
In December 2025, a Remote Access Trojan was discovered on the ferry Fantastic after a crew member [acting on external instructions] inserted a malware-laden USB drive directly into a bridge workstation. By exploiting vulnerabilities including outdated operating systems such as “Windows XP” and inadequate network segmentation, this attack can manipulate ECDIS chart data or remotely take over key engineering systems, creating a pathway toward manipulation of navigation or engineering systems, particularly where outdated operating systems and weak segmentation are present.
The Fantastic case was assessed as a suspected organized attack linked to foreign power interests, with two sailors accused of attempting to deploy trojans or specialized hardware directly onto the ship’s closed-loop navigation systems. Specialists noted this marks a shift toward physical-access-based cyber-espionage against European maritime assets.
Pathway 4: Vendor remote access
Every equipment manufacturer that has supplied systems to a vessel: ECDIS, radar, engine management, power systems, ballast controls, typically maintains a remote access pathway for diagnostics and maintenance. These pathways are not always documented by the operator. They are not always managed with the same rigour as other remote access systems. And they are not always closed between maintenance sessions.
The remote access communications protocols embedded in OT equipment electronics used by OEM troubleshooting teams to remotely diagnose errors and make changes, remain a persistent vulnerability. If a threat actor were able to abuse these pathways to alter engine, ballast, or control-system parameters, the operational consequences could be severe.
The vendor pathway is particularly dangerous because it carries implicit trust. Traffic from a known OEM IP range, authenticating with credentials that the vendor has legitimately used before, accessing systems that vendor is authorized to reach, this does not look like an attack. It looks like a maintenance session.
What Happens Once the Attacker Is Inside: Three Forensically Documented Scenarios
The following scenarios are not drawn from imagination. They are reconstructed from published penetration testing findings conducted by Naval Dome, Pen Test Partners, and other authorised security research teams on operational vessels with the knowledge and permission of owners and manufacturers.
Scenario A: The position that was not where the chart said it was
Naval Dome’s team designed an attack to alter the vessel’s position at a critical point during an intended voyage, during night-time passage through a narrow canal. During the attack, the system display looked completely normal, but it was deceiving the Officer of the Watch. The vessel’s crucial parameters: position, heading, depth, and speed were manipulated in a way that the navigation picture made sense and did not arouse suspicion. This type of attack can easily penetrate the antivirus and firewalls typically used in the maritime sector.
The NMEA injection reconstruction above shows exactly how this works at the protocol level. “NMEA 0183” the standard protocol used to carry navigational data between GPS receivers, autopilots, ECDIS systems, and the dozens of other instruments on a modern bridge: transmits in plain text with no authentication, no encryption, and no integrity checking. The checksum at the end of each sentence is a simple XOR calculation, trivially forged by any attacker already on the network.
[Following Screenshot]: The attacker is assessed to have pivoted from the VSAT terminal onto the vessel’s internal network via the unsegmented LAN. They locate the GPS receiver and the serial-to-IP converter bridging navigation data to the autopilot. NMEA 0183 sentences carry positional data in plain text with no authentication.
The injected sentence in the reconstruction shifts the vessel’s apparent position by approximately 1.4 nautical miles to the northwest. The depth displayed on ECDIS reflects the chart data at the false position 18.4 meters, while the actual depth beneath the keel at the real position is 14.1 meters. The safety contour alarm does not trigger. The system reports GPS active and no alarms. The Officer of the Watch has no reason to question the display.
This can occur through interception [man-in-the-middle attack] and modification of data in transit within the vessel network. This is not GPS spoofing, which is well known and relatively detectable. This is injecting small errors to slowly and insidiously force a ship off course.
Scenario B: The radar that showed a clear picture with ships deleted
The radar is widely considered by many seafarers to be the most reliable, most independent, and least hackable system on the bridge. It transmits and receives physical radio pulses. It does not depend on satellite signals. It cannot be spoofed from the other side of the world. These beliefs are largely correct, until the radar is connected to a network.
Naval Dome’s team used the local Ethernet Switch Interface which connects the radar to the ECDIS, Bridge Alert System, and Voyage Data Recorder to access the radar system. They succeeded in eliminating radar targets, simply deleting them from the screen. At the same time, the system display showed that the radar was working perfectly, including detection thresholds, which were presented on the radar as completely normal.
The bridge team watching that display saw a clear radar picture with normal detection parameters showing. The vessels they could not see on radar were present. The system gave them no indication that what they were looking at was incomplete. The radar appeared to be functioning correctly. It was not.
Pen Test Partners tested over 20 different ECDIS units and found security flaws across all of them. Most ran old operating systems, including one popular in the military that still runs Windows NT. One example had a poorly protected configuration interface that allowed them to jump the vessel by spoofing the position of the GPS receiver on the ship. Then the ECDIS was reconfigured to make the ship appear to be approximately one kilometer square to all nearby vessels’ AIS systems, triggering collision alerts on every ship in the vicinity of a busy shipping lane.
Scenario C: The machinery that started doing something different
A third controlled attack was performed on the Machinery Control System using an infected USB stick. Once connected to the vessel’s MCS, the virus file ran itself and started to change the functionality of auxiliary systems. The attack resulted in machinery being disabled, signals to fuel and ballast pumps being overridden, and steering gear controls manipulated.
The pathway to machinery control from a network-level compromise is through the serial-to-IP converters that translate legacy OT protocols into network communications. These converters translate serial OT protocols [used by engine control, steering gear, and ballast pump systems] into network-addressable communications. A compromised serial-to-IP converter can allow an attacker to intercept, alter, or inject serial communications destined for engine, steering, or ballast systems. “CVE-2016-9361” allowed recovery of the admin password from these devices even after it had been changed from the factory default. Vessels running unpatched firmware on serial converters remain exposed to this class of attack today.
The manipulation does not have to be dramatic. An attacker who understands the vessel’s operational context can introduce incremental changes: a slight reduction in ballast pump throughput, a gradual reduction in fuel flow, a minor heading bias in the steering, that are within the range of normal operational variation and unlikely to trigger alarms immediately.
What Is Being Sold: The Commercial Ecosystem Around Vessel Compromise
The dark web marketplace reconstruction below reflects a documented and active commercial ecosystem around maritime data and access. This is not theoretical criminal activity, it is an established market with pricing conventions, escrow mechanisms, and specialist sellers.
[Following Screenshot]: dark web data marketplace — what vessel data looks like once it is stolen and sold.
Illicit items found for sale online include voyage logs, cargo manifests, ship design schematics, and the personal information of crew. One common ransomware attack involves encrypting the ship’s Planned Maintenance System, forcing the operator to pay in order to recover the voyage’s logs.
A threat actor on a dark web based forum claimed to possess one terabyte of internal data allegedly stolen from a major European defense contractor specializing in submarines and naval vessels, including source code for classified command and management systems, network metadata, technical documents, virtual machines with navy simulators, and confidential internal communications.
Other documented incidents involve the theft of technical manuals, NMEA telegrams used for engine control systems, SSL certificates, private keys, firewall licences, and login credentials. Ship blueprints have been exfiltrated by ransomware groups, creating potential national security implications.
The third dark web post in the reconstruction: a buyer seeking active VSAT shells on vessels transiting specific geographic corridors, directly mirrors the pattern documented in published research connecting cyber collection to kinetic targeting. The intended use of this data is neither questioned nor disclosed.
The Detection Problem: Why This Goes Unnoticed
During the Naval Dome attack, the system’s display looked normal, but it was deceiving the Officer of the Watch. This sentence is the essential summary of why maritime bridge OT attacks are so dangerous and so difficult to detect.
Standard IT security monitoring [antivirus, intrusion detection systems, network traffic analysis] is calibrated for IT threat models. It looks for unusual process execution, unexpected network connections, known malware signatures, and anomalous file system activity. It does not understand NMEA sentences. It does not baseline the normal pattern of position updates flowing from a GPS receiver to an ECDIS. It does not alert when a radar target is deleted from a display. It does not detect an injected autopilot command that is syntactically valid and falls within the normal operational range.
The air gap theory: the idea that critical shipboard systems were safe because they were not directly connected to the internet, is now a dangerous myth. The convergence of IT and OT has created a vast, porous attack surface. Systems like ECDIS often run on outdated operating systems such as Windows 7 or even Windows XP, that no longer receive security patches.
The consequence is an attacker who can remain inside a vessel’s network for weeks or months, reading position data, monitoring cargo information, learning operational patterns before taking any active action. Or taking no active action at all, and simply selling the access to a third party who has a different use for it.
Twelve Things That Close the Door
The vulnerabilities described in this article are not new. The fixes are available. The cost of implementing them is a fraction of the cost of a single maritime cyber incident. What follows is not a generic checklist, it is a direct response to the specific attack pathways and demonstrated techniques documented above.
- Change every default credential on every VSAT terminal in the fleet today. Not this quarter. Not at the next port call. Today. The “admin” user’s “1234” password that is still active on a vessel’s satellite terminal is a documented, exploitable vulnerability that requires no technical knowledge to abuse.
- Remove VSAT management interfaces from public internet exposure. There is no operational reason for a satellite terminal’s administrative interface to be reachable from the global internet. Firewall rules should restrict access to specific, authorized IP ranges only.
- Treat firmware currency as a safety-critical maintenance task. Unpatched firmware on VSAT terminals and serial-to-IP converters is not an IT housekeeping matter. It is a direct safety vulnerability with documented exploits. Patch cycles must be defined, tracked, and enforced.
- Segment the vessel network so that VSAT and crew internet cannot reach bridge OT systems. The absence of segmentation is the single most consequential structural vulnerability in vessel cyber security. A separate, dedicated network for navigation and bridge OT systems [with no direct connection to crew internet or VSAT management traffic] limits the blast radius of any initial compromise.
- Implement a formal chart update procedure that eliminates unscanned USB media. Every USB drive that is inserted into a bridge workstation or ECDIS is a potential delivery mechanism for malware. Chart updates should arrive through an isolated, “air-gapped” scanning station before any connection to navigation systems. Crew smartphone charging from ECDIS USB ports must be prohibited.
- Audit vendor remote access pathways. Compile a complete list of every OEM with remote access to vessel systems. Assess the access mechanism, authentication method, and whether access is session-based or standing. Standing always-on connections to OT systems must be replaced with explicitly authorized, time-limited sessions.
- Implement multi-source position cross-validation as a watch-keeping standard. ECDIS-derived position must be cross-checked against radar, echo sounder, and visual observation at defined intervals. When sources disagree, the discrepancy must be investigated, not dismissed. This is the primary detection mechanism for NMEA injection and GPS spoofing.
- Train bridge officers to interrogate system discrepancies, not normalize them. The Officer of the Watch who encounters a position that does not match radar-derived bearing and distance should not assume the radar is wrong. Cross-validation is a professional skill that must be explicitly taught and regularly exercised.
- Conduct regular GPS-denied and NMEA-degraded navigation drills. Bridge teams must be able to navigate confidently without ECDIS-derived position data. These skills atrophy rapidly in environments where digital navigation is always available and always trusted.
- Implement OT-specific monitoring that understands bridge protocol behavior. Generic IT security tools do not provide meaningful protection for maritime OT environments. Dedicated maritime OT monitoring that baselines normal NMEA traffic patterns, normal alarm frequencies, and normal autopilot command sequences can detect deviations that would be completely invisible to standard network monitoring.
- Assess and manage the security of every VSAT and connectivity service provider. The service provider is not a utility. They are a vendor with privileged access to the network fabric of your fleet. Their security posture, specifically their access control to customer vessel management interfaces, is directly relevant to your vessel’s exposure.
- Treat cyber incidents as potential safety events, not just IT events. Every anomaly on the bridge [an unexpected position jump, a radar display that looks different, an autopilot behavior that feels unusual] should be assessed for the possibility of cyber-induced corruption. The bridge team that applies only operational explanations to technical anomalies will not detect a sophisticated bridge OT compromise.
The Honest Conclusion
The researchers who have spent years testing vessel systems have reached a consistent conclusion. Ken Munro of Pen Test Partners put it plainly: “The advent of always-on satellite connections has exposed shipping to hacking attacks. What we’ve only seen in the movies will quickly become reality.”
Naval Dome’s CTO [the former Head of the Israeli Naval C4I and Cyber Defense Unit] was more specific: “The vessel’s crucial parameters were manipulated in a way that the navigation picture made sense and did not arouse suspicion. This type of attack is capable of bypassing many conventional IT security controls commonly relied upon in maritime environments.”
The scenarios reconstructed in this article: the seven-minute Shodan reconnaissance, the admin panel accessed with factory credentials, the NMEA sentence injected to shift a vessel’s apparent position, the maritime data sold on dark web forums, are not constructed from imagination. They are documented, sourced, and reproducible.
The gap between what the maritime industry believes about its cyber security posture and what security researchers have repeatedly demonstrated in practice is not a gap that requires years of investment to close. It requires a change in attitude about what level of exposure is acceptable, combined with immediate action on the most basic controls that have been available and ignored for years.
- Default credentials changed. Management interfaces firewalled. Firmware patched. Networks segmented. Bridge teams trained.
- None of that is complicated. None of it is expensive relative to the consequences of not doing it. All of it is overdue.
The purpose of this briefing is not to expose techniques, but to demonstrate how existing exposure translates into operational risk.
Maritime Cyber Threat Briefing is a series covering evolving cyber risks in the global shipping industry. This special edition draws on published penetration testing research, open-source vulnerability intelligence, documented incident data, and authorised security research. All scenarios are reconstructions based on real published findings. No live vessel systems were accessed in the production of this article. It is intended to support maritime industry awareness and operational decision-making.
Key sources: Pen Test Partners maritime security research; Naval Dome penetration testing findings; CYTUR 2026 Maritime Cyber Threat White Paper; Cyble threat intelligence; Smart Maritime Network reporting; Maritime Executive incident coverage.
The firms cited in this article are referenced as sources of published research only. No commercial relationship exists between the author and any organization named herein.