🚨 Incident Analysis Beyond UR E26/E27 VSAT · GNSS · Navigation Attack Surface

Three 2025 Ship Incidents That UR E26/E27 Alone Would Not Have Stopped — Solong, Iran's VSAT Fleet Hack, and MSC Antonia

A collision that was blamed on hackers before anyone could prove otherwise. A fleet-wide satellite-terminal attack that came in through a service provider. A grounding caused by satellite signals that lied. None of them lived where the class rules look hardest. Here is what each case teaches — and why the answer is attack-surface minimisation, not just compliance.

Captain Paul
Captain Paul
Maritime Cybersecurity Consultant · IACS UR E26/E27 · Oct 14, 2026 · 14 min read
🎯 Key Message

Ship incidents in 2025 — including VSAT-based attacks and GNSS spoofing — exposed risks that sit beyond the scope of IACS UR E26/E27. Compliance builds the floor. A deliberate strategy to minimise the attack surface is what keeps a ship safe when the threat comes in through a door the rules never listed.

⚡ 2025 Incidents at a Glance
① Solong / Stena Immaculate ② Iranian Fleet VSAT Attack ③ MSC Antonia
Date Mar 10, 2025 Mar 2025 (claimed) · Aug 2025 (second wave) May 10, 2025
Location North Sea, off the Humber / Yorkshire coast Fleet-wide (ships at sea and in port) Red Sea, Eliza Shoals near Jeddah
Suspected Vector Navigation/steering "hack" (speculated) VSAT terminals via satcom service provider GNSS spoofing / jamming (RF)
Impact Collision, jet-fuel fire, 1 seafarer lost External comms lost on 116 (Mar) / 64 (Aug) ships — as claimed ~7,000 TEU boxship grounded
Cyber Verdict Not cyber — master convicted of gross-negligence manslaughter Cyber (claimed) — Lab Dookhtegan; not independently confirmed Cyber/EW (assessed) — Windward, Pole Star, MarineTraffic

Ⅰ. Case 1 — Solong vs Stena Immaculate: When "It Was Hacked" Cannot Be Ruled Out

On the morning of March 10, 2025, the Portuguese-flagged container ship Solong struck the US-flagged product tanker Stena Immaculate while the tanker lay at anchor off the Humber estuary. The tanker was carrying Jet A-1 fuel under the US government's Tanker Security Program. The impact breached a cargo tank; aviation fuel spilled onto Solong's bow, ignited, and set the boxship's containers alight. One Solong crew member, Able Seaman Mark Pernia, was lost and presumed dead.

Within a day, the story had a cyber angle. A senior White House official told the maritime outlet gCaptain that foul play had not been ruled out, and speculation followed that Solong might have been hacked by Russia or another hostile state. The UK government took a more cautious line: the transport minister told Parliament there was "no evidence" of foul play.

Stena Immaculate on fire after the collision with Solong, North Sea, March 2025
The Stena Immaculate burning after the collision, with tugs fighting the fire (inset). Image: news footage, March 2025.

The investigation pointed somewhere else entirely. The UK Marine Accident Investigation Branch (MAIB) interim report found that Solong struck the tanker at about 16 knots in patchy visibility (0.25–2.0 nm), with the master as the lone watchkeeper and no dedicated lookout on either ship's bridge. At trial at the Old Bailey, the master, Vladimir Motin, argued he had pressed the wrong control while trying to take the ship off autopilot. The jury rejected his account, convicting him of gross-negligence manslaughter in February 2026; he was sentenced to six years.

🔎 Analysis — Not a Cyber Incident, But a Cyber Lesson

The hacking hypothesis did not survive investigation. But look at what happened in the first 48 hours: a government official publicly declined to exclude a cyberattack on a ship carrying military fuel. In that window, nobody could quickly prove the bridge systems were clean.

That is the real takeaway. Following IACS UR E26 is meant to give a ship the ability to detect, respond and recover. In practice that means configuration baselines, integrity checks and security logs that let investigators say within hours, not months, whether autopilot, steering or ECDIS behaved as commanded. Forensic readiness is a safety capability. It protects the crew and the operator as much as it catches attackers.


Ⅱ. Case 2 — Iran's Merchant Fleet Goes Dark: A VSAT Attack at Fleet Scale

In March 2025 the hacktivist group Lab Dookhtegan ("Sewn Lips") claimed it had disabled the VSAT-based communications of 116 Iranian vessels: 50 belonging to the National Iranian Tanker Company (NITC) and 66 to the Islamic Republic of Iran Shipping Lines (IRISL). Both companies have been under US sanctions since 2020 for supporting the IRGC. The group said the attack was timed to coincide with US strikes on the Houthis, that ship–shore links had been severed, and that full recovery would take weeks.

NITC tanker Iran Delvar
An NITC VLCC (Iran Delvar). NITC and IRISL ships were the reported targets of both 2025 waves.

Independent verification was limited. Maritime threat-intelligence firm NORMA Cyber said it found no open-source confirmation that the outage happened. It did judge the published vessel list likely authentic, noting that 105 of the 116 ships appear on the OFAC sanctions list.

The group came back in August 2025 with a second, better-documented claim: 64 ships (39 tankers and 25 cargo ships) cut off. This time it described the route in. The attackers said they had compromised Fanava Group, an Iranian IT and telecom holding company that provides the fleet's satellite communications. They published screenshots of root access on Linux-based terminals running iDirect satellite software described as badly outdated. According to an Iranian opposition researcher, they then overwrote storage partitions on the terminals, erasing logs, configurations and recovery data, after access that may have persisted since spring. NITC and IRISL have not confirmed any downtime.

🔎 Analysis — The Ship Never Saw the Attack Coming

Set the geopolitics aside and this is a textbook supply-chain and service-provider compromise. The attackers did not need to breach 64 ships one at a time. They breached the one company that manages all 64 satellite terminals, and from there reached every terminal the provider could reach.

This is exactly where UR E26/E27 thins out. A commercial VSAT terminal used for business traffic and crew welfare is not a statutory system, so it is often left out of the computer-based system (CBS) inventory. UR E26 treats the satellite link as an untrusted network and requires protection at the ship's boundary. But the terminal's firmware, its remote management channel and the provider's network operations centre (NOC) all sit outside what the ship's class survey verifies. Mere compliance with E26/E27 is not enough. Overlooking non-mandated systems such as VSAT leaves vessels dangerously exposed.


Ⅲ. Case 3 — MSC Antonia: The Shoal Was Real. The Coordinates Were Not.

On May 10, 2025, the Liberian-flagged container ship MSC Antonia (IMO 9398216, ~7,000 TEU), on passage from Marsa Bashayer in Sudan to Jeddah, left its intended track and ran aground on the Eliza Shoals in the Red Sea. No one was injured. The day before, UKMTO had warned that several vessels in the Red Sea were experiencing electronic interference and GPS disruption.

Three intelligence providers, Windward, Pole Star Global and MarineTraffic, reached the same broad conclusion: the ship's GNSS position had been corrupted by spoofing or jamming. Its AIS track showed it "jumping" to false positions in the days before the grounding. The ship's systems believed it was somewhere it was not, and the bridge navigated on that belief. Windward has described the Red Sea, particularly near Sudan, as one of the world's busiest GNSS-interference hotspots.

Satellite image of MSC Antonia aground near Jeddah, 10 May 2025
MSC Antonia aground, 10 May 2025, 08:04 UTC. Image: Pole Star Defense / Copernicus Sentinel data 2025.
🔎 Analysis — An Attack With No Network Packet

GPS spoofing is simple in concept. A transmitter broadcasts counterfeit satellite signals that are stronger than the real ones, and the receiver locks onto the fake. No firewall is crossed, no password is guessed and no malware is installed. The "intrusion" arrives through the antenna as radio energy, and the corrupted position then flows through the ship's systems as trusted data. GNSS feeds ECDIS, autopilot and track control, AIS, the VDR and even the time stamps on the ship's logs.

This is why network segmentation, the backbone of UR E26/E27, does nothing against it. The defence has to be resilience in the navigation process: GNSS receivers that can detect spoofing, cross-checks against radar, gyro/log dead reckoning and the echo sounder, alarms when sources disagree, and bridge teams trained to doubt a position that "looks right". It is a failure you can test for, before it happens on a real shoal.


Ⅳ. Cross-Case Analysis — Where Was the Attack Surface?

Put side by side, the three cases point to one pattern. The exposure was in places that a CBS-by-CBS compliance exercise tends to miss: the RF environment, third-party service providers, and the ability to produce evidence after something goes wrong.

Case Exposed Surface Covered by UR E26/E27? What Would Have Helped
① Solong Bridge automation (autopilot/steering) — trust surface, not an attack Partly — for ships contracted from Jul 2024; pre-2024 fleet not covered Forensic readiness: configuration baselines, security logs, a fast "cyber or not?" triage
② Iran VSAT Commercial VSAT terminal + satcom provider NOC Boundary only — terminal and provider out of scope Provider security assurance, terminal hardening and patching, backup comms path
③ MSC Antonia GNSS RF input to ECDIS / AIS / autopilot No — not a network threat PNT resilience: spoofing detection, multi-sensor cross-checks, crew drills
🔍 Cyber Intrusion Analysis Reference — MITRE ATT&CK for ICS Mapping
Case / Stage Tactic Technique
② Provider → terminals Initial Access T0822 — External Remote Services · T0883 — Internet Accessible Device · T0859 — Valid Accounts
② Partition wipe Inhibit Response Function T0809 — Data Destruction · T0814 — Denial of Service
② Fleet comms lost Impact T0826 — Loss of Availability
③ GNSS spoofing Impact T0832 — Manipulation of View · T0880 — Loss of Safety · T0879 — Damage to Property

⚠️ This mapping is the author's analytical framing of publicly reported claims and assessments, not an official mapping by any government or investigating body. Case ① is deliberately left out because the cyber hypothesis was not supported by the investigation or the court. ATT&CK for ICS has no technique for over-the-air GNSS spoofing as such; the techniques listed for Case ③ describe its effect on the operator's view and on safety, not the RF delivery method. Technique IDs were checked against the MITRE ATT&CK for ICS matrix.


Ⅴ. What These Cases Mean for Owners, Managers & Shipbuilders

Each incident shows a different blind spot. Together they describe four gaps that a passed UR E26/E27 survey will not reveal on its own:

The asset inventory stops at the "mandated" line

E26 asset inventories are built around the systems in scope. VSAT terminals, crew-welfare networks, cloud-connected sensors and vendor gateways are often missing, yet attackers choose them precisely because nobody is watching them.

Third-party providers hold the keys to the whole fleet

One compromised satcom provider reached dozens of ships at once. Owners rarely audit their provider's NOC, remote-management credentials or patch practices, and charter contracts rarely require it.

Navigation trusts a single, spoofable source

ECDIS, autopilot and AIS consume GNSS as ground truth. In hotspots such as the Red Sea, the Gulf and the Black Sea, that assumption is no longer safe. Few bridges run structured drills for a GNSS position that is wrong but still plausible.

No evidence trail when the question "was it cyber?" is asked

After Solong, speculation filled the gap that evidence should have filled. Without security logs and configuration baselines, an operator cannot quickly clear its own systems, or prove that an attacker was involved.


Ⅵ. Beyond Compliance — An Attack-Surface Minimisation Strategy

The common answer to all three cases is not another checklist. It is the discipline of shrinking what an adversary can touch, and making sure the ship can still navigate, communicate and explain itself when something gets through.

Strategy 01 Map Every Connection — Not Just the Mandated Ones

Lesson from: Case ② (VSAT outside the CBS inventory).

Actions: Extend the asset inventory to all external connections: VSAT and LEO terminals, 4G/5G routers, crew Wi-Fi, OEM remote-access boxes and cloud data loggers. Remove or disable every interface without a clear operational need. Each connection that stays must have an owner, a documented purpose and a defined zone/conduit.

Strategy 02 Harden Satcom Terminals & Hold Providers Accountable

Lesson from: Case ② (provider compromise reaching the whole fleet).

Actions: Change default credentials, close unused management ports and keep terminal firmware patched. Write security obligations into satcom contracts: MFA on provider remote management, incident-notification deadlines, patch SLAs and the right to audit. Keep a backup communications path on a different provider or technology so that losing one link does not isolate the ship.

Strategy 03 Build PNT Resilience Into the Bridge

Lesson from: Case ③ (GNSS spoofing with no network intrusion).

Actions: Specify multi-constellation GNSS receivers with spoofing and jamming detection on new builds and retrofits. Configure ECDIS and the integrated navigation system (INS) to alarm when GNSS disagrees with radar, gyro/log dead reckoning or the echo sounder. In known interference areas, require radar-based position fixing and parallel indexing as standard practice. Run "plausible but wrong position" drills during bridge resource management training.

Strategy 04 Make Forensic Readiness Part of Safety Management

Lesson from: Case ① (the "hacked?" question nobody could answer fast) and Case ② (logs wiped from the terminals).

Actions: Keep configuration baselines for bridge and engine systems, and send security logs to storage that an attacker on the device cannot overwrite. Add a short "cyber or not?" triage step to the SMS casualty procedure so the first hours after an incident produce evidence, not speculation. Rehearse it with the company DPA and the class society.

Strategy 05 Treat E26/E27 as the Floor — and Extend It to the In-Service Fleet

Lesson from: all three cases.

Actions: On new builds, keep demanding UR E27-compliant equipment — it remains vital for securing onboard systems against cyber-induced loss of control. Then add the threats it does not model: RF and PNT, service providers, and non-mandated connectivity. For ships contracted before July 2024, run a voluntary gap assessment against E26 principles and close the highest-exposure items first: external connections, remote access and navigation.

⚓ Captain Paul's Take — Assessment

Read together, the 2025 cases are a warning about where we look. One ship was blamed on hackers and turned out to be a human failure that nobody could quickly prove. One fleet went dark because its satellite provider was the soft target. One ship ran aground because the satellites themselves were made to lie. None of these sat at the centre of a typical E26 CBS inventory.

IACS UR E26/E27 is necessary, and it is working. A year later, the VL Prosperity attack showed the same lesson from the engine room: what reaches the ship through the satellite link can reach the machinery. The question for every owner, manager and shipbuilder is not only "are we compliant?" but "what can an adversary still touch, and what happens to the ship when they do?"

📰 News Sources:

🇬🇧
Vessel involved in North Sea crash "may have been hacked", US claims
LBC · Mar 11, 2025 — White House official's comments to gCaptain
⚓
UK report says neither ship had lookouts despite patchy visibility
The Maritime Executive — MAIB interim report on Solong / Stena Immaculate
⚖️
Six-year jail sentence for Solong captain
Seatrade Maritime News — 2026
🛰️
NORMA Cyber perspective on cyber attack of 116 Iranian vessel VSATs
Digital Ship — independent assessment of the March 2025 claim
🛡️
Lab Dookhtegan hacking group disrupts communications on dozens of Iranian ships
Security Affairs — Aug 2025 wave, Fanava / iDirect terminal access
📡
Hackers disrupt communications of Iranian oil and cargo ships
Iran International · Aug 2025 — group statement on 39 tankers and 25 cargo ships
🧭
MSC Antonia grounding in the Red Sea attributed to suspected GNSS spoofing
Inside GNSS — Windward / Pole Star / MarineTraffic analyses
🚢
Intelligence firm confirms GPS spoofing responsible for MSC Antonia grounding
Marine Insight — Pole Star Global assessment
#MaritimeCyberIncidents #GPSSpoofing #VSATSecurity #MSCAntonia #Solong #IACSURE26 #IACSURE27 #AttackSurface #MaritimeCybersecurity #Maritime40

Disclaimer: This post is based on publicly available reporting, including LBC/gCaptain, The Maritime Executive (MAIB interim report), Seatrade Maritime News, Digital Ship/NORMA Cyber, Security Affairs, Iran International, Inside GNSS and Marine Insight. The Iranian fleet attack figures (116 and 64 vessels) are the attacking group's own claims and have not been independently confirmed. The MSC Antonia GNSS-interference finding comes from commercial intelligence providers, not an official casualty investigation. The Solong hacking hypothesis was not supported by the investigation or the court, and is discussed here only as a lesson in forensic readiness. All technical analysis and ATT&CK mapping is the author's independent assessment.

Captain Paul
Captain Paul (In Sung Lee)
Maritime Cybersecurity Analyst · ShipPaulJobs

Captain Paul has conducted E26 CRSI project assessments and cyber resilience evaluations across vessel types, working at the intersection of ship systems engineering and cybersecurity compliance. He writes on IACS UR E26/E27, OT security, and emerging threats to the maritime sector.

⚓ Join the ShipPaulJobs Community

Join →
Share

Comments

Top Ranked · All Posts

Popular Posts