We present an evidence-based investigation into suspected cyber compromises aboard two energy tankers bound for Texas, examining maritime IT/OT security, the unverified engine-control claims and the possible Iranian connection.

In August 2026, U.S. authorities investigated suspected cyber compromises involving two commercial energy vessels traveling toward Texas.

The vessels were the crude-oil tanker VL Prosperity and the LPG carrier Kohaku. According to reporting based on U.S. officials and vessel-tracking data, both vessels were targeted while transiting the Strait of Gibraltar. After the vessels reached the Gulf of Mexico, U.S. Coast Guard and FBI personnel conducted specialized cyber-security boardings on August 21 and August 24.

We have covered the V L Prosperity incident here.

The U.S. government has confirmed an important fact: investigators had indications that the vessels' networks had been compromised by foreign cyber actors. The Coast Guard and FBI examined both information-technology and operational-technology systems and worked with the crew and vessel operators to address the threat. The Coast Guard subsequently reported no operational disruptions, vessel instability, physical danger to crews, or environmental impacts.

A separate and much more dramatic account originated with Iranian media. Mehr News Agency reported that VL Prosperity suffered a cyberattack on August 7 and lost communications for approximately 30 hours. Citing an unnamed crew member, the report alleged that attackers reached engine-room systems, reduced engine cooling flow, increased engine speed and interfered with fuel and engine-oil systems. Those claims have not been independently verified by the U.S. government and no public forensic evidence has established that the attackers manipulated propulsion or other safety-critical OT.

The distinction is critical.

The public record currently establishes network compromise and a subsequent federal cyber investigation. It does not establish that an attacker remotely controlled the propulsion system, navigation system or cargo systems of either tanker.

The incident nevertheless matters because it demonstrates that cyber investigators considered the compromise significant enough to conduct shipboard examinations of both IT and OT systems. It also illustrates why maritime cyber risk cannot be treated solely as an information-security problem: on a modern vessel, cyber compromise can potentially intersect with systems responsible for propulsion, navigation, machinery and cargo operations. Rear Adm. Amy Grable, commander of Coast Guard Cyber Command, specifically warned that interconnected ship systems can create safety consequences if they are breached and controlled.

The most important unanswered questions remain technical:

·       How did the attackers obtain initial access?

·       Which networks and systems were actually compromised?

·       Did the intrusion cross from information technology into operational technology?

·       Was the reported communications outage caused by the intrusion?

·       Were any engine or machinery parameters actually changed?

·       Did the same access mechanism affect both vessels?

·       What evidence, if any, supports an Iranian connection?

As of September 18, 2026, those questions remain unresolved publicly.

What happened?

The incident essentially consists of two overlapping stories.

The first is the publicly documented U.S. response.

The second is the unverified technical account published by Iranian media.

We have tried to keep these two evidence streams separate.

What U.S. authorities have established?

As per the Coast Guard and FBI:

• U.S. authorities received indications that networks aboard two foreign-flagged commercial vessels had been compromised.

• The Coast Guard referred to the activity as involving foreign cyber actors.

• A specialized team boarded a vessel on August 21.

• The team included Coast Guard law-enforcement personnel, Coast Guard Cyber Protection Team members, a vessel inspector and FBI Cyber Action Team operators.

• Investigators examined both IT and OT systems.

• A second vessel was boarded on August 24.

• Authorities reported no vessel instability, operational disruption, physical danger to crews or environmental impact.

• The public U.S. statements did not identify the threat actor.

What remains a reported claim

Iranian media reported that VL Prosperity experienced a cyberattack on August 7 while transiting the Strait of Gibraltar and lost communications for approximately 30 hours.

Mehr's account, citing an unnamed crew member, alleged that attackers reached engine-room systems and manipulated engine cooling, engine speed and fuel/lubricating-oil systems.

The WSJ reported these allegations but stated that it could not independently confirm them.

Incident timeline

The Coast Guard's public account refers specifically to the August 21 boarding, while FBI reporting subsequently established that a second vessel was boarded on August 24. Reuters reporting noted that the agencies did not publicly explain every difference between their accounts.

The vessels

VL Prosperity

Public vessel records identify VL Prosperity as a very large crude carrier:

·       IMO: 9683697

·       Flag: Liberia

·       Length: approximately 333 metres

·       Built: 2015

·       Deadweight: approximately 319,547 tonnes

·       Crude capacity: approximately 2.3 million barrels

·       Voyage: Egypt toward Galveston, Texas

U.S. reporting and vessel-tracking information place the ship on a voyage from Egypt toward Galveston. The Coast Guard did not itself publicly name the vessel, but multiple reports identified it as VL Prosperity.

Kohaku

Public vessel data identifies Kohaku as:

·       IMO: 9932608

·       Vessel type: LPG carrier

·       Length: approximately 227 metres

·       Built: 2023

·       Flag: Marshall Islands

The vessel was reportedly traveling toward a Texas port to load LPG.

What is actually known about the cyber compromise?

Confirmed or strongly supported

Network compromise:
The FBI said its joint Coast Guard-FBI team boarded the vessels after receiving indications that the networks of both vessels were compromised. The Coast Guard described the actors as foreign cyber actors.

IT and OT examination:
The Coast Guard said investigators examined both the vessels' operational technology and information-technology systems.

Federal cyber response:
The response involved specialized Coast Guard cyber personnel and FBI Cyber Action Team operators.

No publicly reported safety consequence:
The Coast Guard reported no operational disruptions, vessel instability, physical danger to crews or environmental impacts.

Reported but unverified

Mehr reported:

·       approximately 30 hours of communications disruption;

·       access to engine-room systems;

·       reduced engine cooling;

·       increased engine speed;

·       interference with fuel and engine-oil systems.

Those claims originated from Iranian media and an unnamed crew source. The WSJ said it could not independently confirm them.

Unknown

There is currently no public evidence establishing:

• malware used;

• initial access vector;

• compromised credentials;

• compromised VPN;

• exploitation of a satellite terminal;

• exploitation of a vendor connection;

• lateral movement from IT to OT;

• manipulation of PLCs or engine controllers;

• manipulation of ECDIS;

• remote steering;

• cargo-system manipulation;

• persistence after the vessels reached U.S. waters.

These should remain unknown, not reconstructed as facts. Now let’s move on to the most important question.

Could a cyberattacker actually control a tanker?

The answer depends entirely on architecture.

A compromise of a vessel's corporate IT network does not automatically provide control of propulsion or navigation.

A realistic attack chain would (potentially) require several additional conditions (akin to the Swiss cheese model):

External connectivity → onboard network → authentication/access control → segmentation boundary → engineering or OT workstation → control network → relevant controller → physical process

Each step represents an additional technical barrier.

The precise architecture of VL Prosperity and Kohaku is not publicly available, so it would be inappropriate to state that either vessel uses a particular PLC protocol, firewall architecture, data diode, jump server or remote-maintenance topology.

Four different levels of compromise should therefore be distinguished

That distinction is more important than the dramatic question of whether an attacker could theoretically “take over a ship.”

Rear Adm. Amy Grable has confirmed that interconnected ship systems can create a pathway from cyber compromise to safety consequences. But her statement describes the risk condition, not evidence that the two vessels in this case were remotely controlled.

The engine-room claims

The most technically significant allegation concerns VL Prosperity's engine room.

Mehr reported that attackers:

· reduced engine cooling flow;

· increased engine speed;

· interfered with fuel systems;

· interfered with engine-oil systems.

These claims deserve scrutiny but should not be converted into confirmed findings.

There are several possibilities:

· The claims could describe genuine manipulation of machinery systems.

· They could describe temporary disruption or anomalous readings rather than direct control.

· They could represent an incomplete or inaccurate understanding of what occurred.

· They could reflect information released during an ongoing investigation.

· They could be a combination of genuine cyber activity and inaccurate technical interpretation.

The public evidence does not currently allow those possibilities to be separated.

Most importantly, the absence of publicly confirmed physical consequences does not automatically prove that OT was untouched. Conversely, the existence of a network compromise does not automatically prove that OT was reached.

That uncertainty is precisely why the federal investigation examined both IT and OT.

Investigating the Iranian connection

The U.S. is investigating whether Iran was responsible or involved.

The WSJ reported that U.S. officials were investigating possible Iranian involvement. The same reporting states that U.S. authorities had not publicly attributed the attacks to Iran.

Attribution evidence currently available

The fact that Iranian media reported details about the incident is relevant to the investigation, but it is not forensic attribution evidence by itself.

There is also no public evidence establishing that the reporting came from intercepted communications, an intelligence source or direct knowledge of the attackers.

Therefore:

Attribution remains unresolved.

The appropriate analytical position is that Iranian involvement is an active investigative hypothesis.

MITRE ATT&CK mapping  

MITRE ATT&CK should not be used to fill gaps in the investigation.

The following mapping therefore distinguishes between what is potentially applicable and what has actually been demonstrated.

MITRE defines T0836 as modification of parameters used to instruct ICS devices. It is therefore conceptually relevant to the engine-room allegation, but mapping a technique does not establish that the technique occurred.

Likewise, T1190, T1078 and T1021 should not be presented as reconstructed attack steps without evidence showing that those mechanisms were used.

The maritime OT attack surface

Although the architecture of the two vessels is not publicly documented, maritime operators commonly need to manage cyber risk across several connected technology domains.

These can include:

·       satellite communications;

·       onboard administrative IT;

·       crew networks;

·       navigation systems;

·       engine and machinery monitoring;

·       propulsion-control systems;

·       cargo-control systems;

·       ballast systems;

·       engineering workstations;

·       remote vendor-support connections;

·       shore-to-ship data links;

·       removable media;

·       fleet-management platforms.

The relevant security question is therefore not simply:

“Is the vessel connected to the internet?”

It is:

“Which connected systems can communicate with systems that influence safe vessel operation, and under what controls?”

The IMO's maritime cyber-risk guidance uses a risk-management approach spanning identification, protection, detection, response and recovery. The organization has also explicitly recognized that cyber risk belongs within the broader safety-management environment of shipping.

The IT/OT boundary is a critical question

The central technical question in this incident is whether the compromise remained within information networks or crossed into operational technology.

The exact implementation should be determined through vessel-specific risk assessment.

A data diode may be appropriate for certain one-way monitoring architectures, but it should not be presented as a universal requirement for maritime OT. Similarly, “air-gapping” diagnostic laptops is not always operationally realistic.

The security objective should instead be to:

·       minimize unnecessary connectivity;

·       strictly control remote access;

·       authenticate privileged users;

·       segment systems according to operational risk;

·       monitor OT communications;

·       control removable media;

·       maintain safe manual fallback;

·       validate changes to critical control systems;

·       preserve recovery capability.

Safety consequences: Theoretical vs. observed

This distinction should remain throughout the article.

Potential cyber-physical consequences are real. The public evidence does not show that they occurred in this incident.

Why the Strait of Gibraltar matters

The Strait of Gibraltar is a strategically important maritime corridor connecting the Mediterranean with the Atlantic.

The WSJ reported that approximately 300 ships transit the waterway each day, illustrating the scale of maritime traffic through the corridor.

For cyber defenders, the significance is not simply that the strait is geographically narrow.

A vessel in transit has different response constraints from a facility on land:

·       shore-based engineers may not be immediately available;

·       physical access to systems is limited;

·       network connectivity may be intermittent or degraded;

·       crew must maintain safe navigation while investigating an incident;

·       cyber response must coexist with marine engineering and safety procedures;

·       evidence can be difficult to preserve without disrupting operations.

That makes shipboard incident response a distinct operational discipline.

The most important development: Cyber investigation at sea

One of the more significant aspects of this incident is not the unverified claim of remote engine manipulation.

It is the U.S. government's decision to conduct a specialized cyber investigation aboard vessels after they entered the Gulf of Mexico.

The Coast Guard team included cyber specialists, law-enforcement personnel and a vessel inspector, while FBI Cyber Action Team personnel participated in the investigation. The team examined both IT and OT environments.

This demonstrates an increasingly important requirement for maritime operators:

A cyber incident aboard a vessel may become a physical incident-response problem.

The investigation may require personnel who understand:

·       network forensics;

·       vessel engineering;

·       OT architecture;

·       navigation;

·       machinery control;

·       evidence preservation;

·       maritime safety;

·       port operations.

That convergence is arguably the most important operational lesson from the case.

What this incident reveals about maritime cybersecurity

Network compromise is not the same as vessel control

The distinction between access, persistence, OT access and physical manipulation must remain explicit.

IT/OT boundaries require evidence, not assumptions

A vessel can have significant connectivity without providing a direct path to propulsion or navigation.

Cyber incidents can require physical intervention

The U.S. response demonstrates that authorities may need to examine onboard systems directly when a vessel's network is suspected of compromise.

Maritime cyber response must be operationally aware

Investigating a compromised ship is different from investigating a compromised office network.

Third-party connectivity deserves particular scrutiny

Fleet management, OEM support and remote engineering connections can create legitimate pathways that require strong authentication, segmentation, authorization and monitoring.

Resilience matters as much as prevention

A vessel must be capable of maintaining safe operations when digital systems become unavailable or untrusted.

Defensive recommendations

The appropriate response is not to disconnect every vessel from every external network.

It is to make connectivity controlled, observable and recoverable.

1. Establish a complete vessel cyber asset inventory

Identify:

·       IT systems;

·       OT systems;

·       navigation systems;

·       machinery-control systems;

·       cargo systems;

·       communications equipment;

·       engineering workstations;

·       remote-access gateways;

·       vendor connections;

·       removable-media interfaces.

Critical assets should be mapped to operational consequences.

2. Segment vessel networks according to operational risk

Separate, where technically and operationally appropriate:

·       crew/welfare networks;

·       administrative IT;

·       communications;

·       navigation;

·       engineering;

·       machinery control;

·       cargo-control systems.

Use controlled conduits and monitored access between zones.

3. Eliminate unnecessary permanent remote access

Vendor access should use:

• strong authentication;

• least privilege;

• time-limited access;

• controlled jump hosts;

• approval workflows;

• session logging;

• access monitoring.

4. Monitor OT passively

OT monitoring should establish normal communication patterns and identify:

• unexpected engineering-station connections;

• unauthorized configuration changes;

• unusual control traffic;

• new devices;

• unexpected remote sessions;

• changes to critical parameters.

5. Strengthen removable-media controls

Engineering USB devices should be inventoried, scanned and controlled before introduction into sensitive environments.

6. Build vessel-specific incident-response procedures

Plans should answer:

• Who declares a cyber incident?

• Who can isolate a network?

• Who controls machinery if digital systems become unavailable?

• How is evidence preserved?

• When is the vessel operator notified?

• When are authorities contacted?

• How does the vessel continue safely while forensic work is underway?

7. Exercise manual fallback

Cyber exercises should include degraded-network scenarios rather than stopping at IT ransomware simulations.

The objective is not simply to restore a server.

It is to maintain safe vessel operation.

A practical maritime OT security architecture

A reference architecture should focus on segmentation, controlled access and visibility, rather than assuming that every vessel requires the same hardware.

Cross-zone communication should be explicitly authorized, monitored and minimized.

For monitoring architectures, one-way data flows can be considered where they provide operational value without introducing unnecessary control paths.

This should be determined through vessel-specific engineering and risk analysis rather than imposed as a generic architecture.

30–90–180 Day Maritime Cybersecurity Program

The IMO's cyber-risk guidance emphasizes continuous identification, protection, detection, response and recovery rather than treating cybersecurity as a one-time compliance exercise.

Unanswered questions

Several questions remain central to the investigation:

• What was the initial access vector?

• Were credentials compromised?

• Was an internet-facing system exploited?

• Was satellite communications infrastructure involved?

• Was a vendor or fleet-management connection involved?

• Did the attackers reach OT networks?

• Were any PLCs, HMIs or engineering workstations compromised?

• Did the reported communications outage result directly from malicious activity?

• Were engine parameters actually modified?

• Was Kohaku compromised using the same mechanism?

• Were other vessels in the same fleet exposed?

• Did investigators identify persistence mechanisms?

• Were malware samples recovered?

• Will authorities release IoCs or forensic findings?

• What evidence supports the investigation into possible Iranian involvement?

Until these questions are answered, any detailed reconstruction of the attack chain remains provisional.

Shieldworkz assessment

The available evidence supports a narrower conclusion than some early reporting suggests.

Two U.S.-bound commercial energy vessels were subjected to suspected cyber compromise significant enough to trigger specialized Coast Guard and FBI cyber investigations. U.S. authorities identified foreign cyber actors and examined both IT and OT environments. No operational disruption, vessel instability, physical danger to crews or environmental impact was publicly reported.

The more dramatic claim that attackers manipulated propulsion and engine-room systems aboard VL Prosperity remains unverified in the public record.

Likewise, Iranian involvement remains an investigative hypothesis. The strategic lesson therefore does not depend on proving that an attacker successfully took control of a tanker.

The more immediate lesson is that commercial vessels are cyber-physical environments whose network compromise can require the same combination of digital forensics, OT expertise, engineering judgment and safety response normally associated with industrial facilities.

For fleet operators, the key question is not whether every cyberattack can cause a collision.

It is whether an attacker can move from a compromised communications or information system into a system that matters to safe navigation, propulsion or cargo operations — and whether the operator can detect, contain and recover from that movement before it becomes an operational event.

That is the security boundary that deserves the greatest attention.

What Maritime operators should learn from the incident

The practical priorities are straightforward:

·      Know what is connected.

·      Know which connections can reach OT.

·      Control who can access them.

·      Monitor changes to critical systems.

·      Maintain safe manual fallback.

·      Prepare to investigate a vessel while it is still operating.

·      Treat cyber risk as part of operational and safety risk, not merely an IT issue.

IMO's maritime cyber-risk framework explicitly places cyber risk within the broader objective of safe and resilient shipping.

Shieldworkz Maritime OT resources

For readers looking to translate these lessons into an OT-security program, the following Shieldworkz resources are directly relevant:

• OT/ICS Security for Ports & Maritime Infrastructure — guidance covering asset inventory, segmentation, navigation resilience, vendor access, OT monitoring and recovery.

• Maritime OT Cybersecurity IEC 62443-3-2 Risk Assessment Playbook — focused on maritime OT risk assessment, asset inventory, zones and conduits, risk scoring and treatment planning.

• Securing Modern Ports & Maritime Terminals — an IEC 62443-aligned blueprint covering maritime OT architecture, segmentation, asset visibility and incident preparedness.

Primary Shieldworkz resource:
OT/ICS Security for Ports & Maritime Infrastructure

Sources and evidence base

This investigation should be read with the following evidence hierarchy:

Primary / official sources

• U.S. Coast Guard statements concerning the cyber-security boarding and findings.

• FBI statements concerning the boarding of the two vessels.

• IMO maritime cyber-risk guidance.

• High-quality reporting

• The Wall Street Journal investigation based on U.S. officials.

• Reuters reporting on the vessel compromises and government response.

• CBS News reporting incorporating Coast Guard statements and vessel information.

• Secondary reporting: Jerusalem Post reporting based on the WSJ investigation.

• Maritime industry reporting concerning the vessel identities and Iranian media claims.

• Claim-source material

• Mehr News Agency reporting concerning the alleged August 7 attack and engine-room effects.

The evidence should not be treated as equivalent across these categories. In particular, the engine-manipulation claims originate from Iranian media and an unnamed crew source and remain unverified in the public record.