I am still the Captain now!

I am still the Captain now!

Speakers: Paul Brownridge

Conference: DEF CON 32

YouTube: https://www.youtube.com/watch?v=j7twZA6SBz8

Overview

In "I am still the Captain now!", Paul Brownridge, an experienced OT and maritime cybersecurity professional, delves into the complex and often overlooked cybersecurity landscape of large container ships. The talk uses the highly publicized MV Dali incident, where a container ship collided with the Francis Scott Key Bridge in Baltimore, as a topical entry point. Brownridge aims to move beyond speculative "hack" theories by providing a grounded, technical understanding of ship operational technology (OT) systems, their interconnectedness, and inherent vulnerabilities.

Brownridge's presentation serves as a critical examination of how modern IT components interface with decades-old industrial control systems (ICS) in maritime environments, creating unique attack surfaces. He highlights the critical role of human intervention and manual overrides as a last line of defense, even as systems become increasingly automated and interconnected. The talk is essential for anyone interested in industrial control systems, critical infrastructure security, and the unique challenges presented by the maritime sector, offering insights into real-world penetration testing experiences.

The core of the presentation unpacks a specific discovery made during a ship penetration test: a hidden, rugged Windows PC acting as a bridge between IP networks and legacy serial systems. This device, crucial for fuel consumption prediction, exposed a significant vulnerability via an insecure Modbus connection to the ship's Programmable Logic Controllers (PLCs), demonstrating a clear path for an attacker to potentially inject malicious commands and disrupt critical operations.

Background

▶ Watch: Speaker intro and MV Dali incident overview (0:00)

The maritime industry, though vital for global trade, often operates with a patchwork of technologies, some dating back decades. This creates a challenging environment for cybersecurity, a reality brought into sharp focus by incidents like the MV Dali collision. While public speculation frequently veered towards cyberattack, Brownridge suggests a more nuanced understanding is required, one that considers the intricate architecture of shipboard systems and their operational realities.

A modern container ship's propulsion and steering are managed by a sophisticated, yet often antiquated, network of operational technology. At its heart is the main engine, a singular, massive unit supported by numerous ancillary systems responsible for cooling, fuel injection, and other vital functions. These systems are powered by generators, typically arranged in redundant arrays, which also supply power to critical components like the steering gear. Orchestrating this entire power infrastructure is the Power Management System (PMS). All of these, in turn, feed into the Integrated Control and Monitoring System (ICMS), sometimes referred to as the Integrated Alarm and Monitoring System (IAMS). This ICMS acts as the "brains and eyes" of the ship, controlling Programmable Logic Controllers (PLCs) in the engine room, managing rudder control, and overseeing power distribution. Without a functioning ICMS, the ship cannot operate.

Connectivity between these disparate systems is a blend of old and new. Many legacy OT systems still rely on serial connections, which are then often bridged to modern IP networks using IP to serial connectors. This hybrid environment introduces complexity and potential vulnerabilities. The ship's helm, where steering controls reside, is typically tied into an autopilot system. Crucially, Brownridge emphasizes that despite automation, a physical switch always exists to disconnect the autopilot and allow for manual steering, ensuring a human remains in the loop as a failsafe. Similarly, an emergency "steering flat" provides manual control in critical situations.

The procedures for restarting ship systems after a blackout—a complete loss of power—are complex and sequential, not a simple one-button operation. While regulations stipulate that emergency generators should come online within 45 seconds, real-world scenarios often see this process take several minutes and require multiple crew members to manually start generators and close breakers. In the open sea, this delay might be manageable; however, when approaching critical infrastructure like a bridge, even a minute or two of unpowered drift can lead to catastrophic consequences. Blackouts themselves can be triggered by various factors, including bad fuel, heavy seas causing pressure loss, electrical problems, or poor maintenance—issues that tend to worsen with the age of the vessel. Brownridge cites historical examples, such as the Carnival Triumph (2013) and Viking Sky (2019) cruise ship blackouts, to underscore that these incidents are not uncommon.

The threat landscape for these systems is evolving. While a direct supply chain attack to compromise autopilot firmware is considered possible but highly unlikely due to the significant effort required for signing and distribution, the more immediate threat lies within the operational network itself. The blend of old, discrete systems (some 30-40 years old) with newer IP-based components, often managed by rotating crews who may not fully understand every running system, creates an environment ripe for overlooked vulnerabilities and "shadow IT" components left running out of fear of disrupting unknown functions.

Key Findings

▶ Watch: Restart procedures and challenges during a ship blackout (3:08)

During a penetration test on a ship, Paul Brownridge's team uncovered a critical and overlooked component that represented a significant attack vector. This discovery was made through meticulous physical reconnaissance, where the team identified an uncatalogued system during their "walk around" of the vessel.

The central finding was a rugged Windows-based PC concealed within one of the ship's panels. This PC was not part of the documented systems but was actively running, highlighting a common issue in OT environments: forgotten or undocumented assets. Further investigation revealed that this hidden PC served a specific function: calculating and predicting fuel consumption based on engine revolutions per second, a critical operational parameter for ship economics and performance.

The most significant aspect of this discovery was the PC's connectivity. It utilized an IP to serial connector to interface with the ship's industrial control systems. This connector facilitated two distinct communication paths, each with vastly different security implications:

1. Connection to the Bridge ICMS/Charting System: One output from the IP to serial connector was directed to the ship's bridge, specifically feeding data to the Integrated Control and Monitoring System (ICMS) and the charting system. This link was designed to track the ship's position and speed relative to fuel consumption. Crucially, the team discovered that this connection was transmit-only. Wired with only two lines (ground and a single serial connection), it could only send data from the rugged PC to the bridge systems. From an attacker's perspective, this configuration was secure; no data injection or command manipulation was possible down this specific line.

1. Connection to the Main Engine PLCs: The second, and far more critical, connection from the IP to serial converter led directly to the Programmable Logic Controllers (PLCs) on the main engine. This connection utilized the Modbus protocol. Unlike the transmit-only link, this Modbus connection was fully bidirectional. The rugged PC would poll the PLCs for data like engine revolutions per second and fuel consumption. The key finding here was that because Modbus operates on a master-slave principle where the master polls for values, an attacker who gains access to the rugged PC (or the network segment it resides on) could leverage this connection. By injecting malicious Modbus commands, an attacker could write arbitrary values to the PLCs, effectively manipulating critical engine parameters such as speed, fuel delivery, or even initiating emergency shutdowns.

This discovery highlighted a significant vulnerability: a hidden, undocumented Windows PC bridging IT and OT networks, with one of its connections secured (transmit-only serial) and another critically exposed (bidirectional Modbus to PLCs). The ability to inject values into the PLCs via Modbus represents a direct path to physical disruption and potential catastrophe, far beyond mere data exfiltration.

Technical Deep Dive

▶ Watch: Causes and critical timeframes for ship blackouts (4:40)

The technical architecture of maritime operational technology, as explored by Brownridge, presents a fascinating blend of legacy and modern systems. At the core of a ship's operational capabilities are its main engines, which are not standalone units but are intricately supported by ancillary systems. These include pumps for cooling, fuel injection systems, and lubrication, all of which are essential for the engine's operation. Powering these systems, and indeed the entire ship, are multiple generators, often configured in redundant arrays to ensure continuous operation.

The orchestration of power generation and distribution falls under the purview of the Power Management System (PMS). This system ensures that the ship's electrical load is balanced and maintained, even in dynamic conditions. The PMS, along with other critical operational data from various sensors and control points, feeds into the Integrated Control and Monitoring System (ICMS). The ICMS acts as a centralized hub, providing visibility and control over virtually all critical ship functions, including the propulsion, steering, and auxiliary machinery. It interfaces with Programmable Logic Controllers (PLCs) located in the engine room, which are the workhorses responsible for executing automated control sequences for pumps, valves, and engine parameters.

The challenge, and the source of many vulnerabilities, lies in the interconnection of these systems. Many legacy PLCs and control devices communicate via traditional serial connections. To integrate these older systems with modern IP-based networks, IP to serial connectors are extensively used. These devices, essentially protocol converters, encapsulate serial data within IP packets, allowing serial devices to be managed and monitored over Ethernet networks. While convenient, this bridging introduces new attack surfaces if not properly secured.

Brownridge's team identified a specific instance of such a bridge: a rugged Windows-based PC. This PC was performing "fancy mathematics" to predict fuel consumption by polling engine parameters like revolutions per second from the PLCs. Its role as an intermediary between IP and serial domains made it a high-value target.

The critical vulnerability stemmed from the PC's use of Modbus over its serial connection to the engine PLCs. Modbus is a widely adopted, master-slave (or client-server) communication protocol used in industrial control systems. It operates by a master device (in this case, the rugged PC) sending requests to a slave device (the PLCs) to read or write data to specific registers. A key characteristic of Modbus is its inherent lack of security features; it does not include authentication, encryption, or integrity checks by default. If an attacker gains access to the network segment where the Modbus communication occurs, or compromises the master device (the rugged PC), they can send arbitrary Modbus commands to the PLCs.

In this scenario, the attacker could:

1. Read critical operational data: Obtain real-time engine revolutions, fuel flow rates, temperatures, and other sensor data.
2. Write malicious values: Inject commands to modify PLC registers. For instance, an attacker could command the engine to increase or decrease revolutions beyond safe limits, alter fuel injection rates, or even trigger emergency stops. Such actions could lead to engine damage, loss of propulsion, or catastrophic events if the ship is in a critical navigation phase.

The contrast with the transmit-only serial connection to the bridge ICMS is crucial. That specific link, physically wired with only two wires (ground and transmit data), inherently prevented any inbound data injection. This demonstrates that while the technology (IP to serial) was the same, the implementation and physical wiring dictated the security posture. The Modbus connection, however, was designed for bidirectional communication, making it susceptible to manipulation once the intermediary PC was compromised. The prevalence of old, discrete OT systems (some 30-40 years old) necessitates the use of such converters, but their configuration and the protocols they carry are paramount to security.

Demo / Proof of Concept

▶ Watch: Documented instances of cruise ship blackouts (5:50)

While "I am still the Captain now!" did not feature a live, active exploitation demonstration, the talk detailed a compelling discovery and analysis process that serves as a proof of concept for the presented attack vector. Brownridge described this as a real-world scenario encountered during a maritime penetration test.

The "demo" began with the physical reconnaissance phase, often referred to as a "walk around" in OT security assessments. Brownridge emphasized that in complex environments like ships, where systems are often undocumented or forgotten, this hands-on approach is crucial. His team observed cables and pipes running throughout the ship, indicative of numerous interconnected systems, but without clear documentation or understanding from the crew.

The pivotal moment occurred when the team opened various panels to trace connections and identify unknown devices. This led to the discovery of a hidden rugged Windows-based PC. This PC was not only undocumented but also actively running, performing calculations related to fuel consumption based on engine data.

The subsequent technical analysis of this PC and its connections formed the core of the proof of concept:

1. Identification of IP to Serial Connectivity: The team identified that the rugged PC was utilizing an IP to serial connector to bridge its internal IP network with the ship's legacy serial control systems. This device was key to understanding how the modern PC interacted with the older OT infrastructure.

1. Tracing Dual Communication Paths: They meticulously traced the serial connections emanating from the converter.

• One path led to the bridge's ICMS (Integrated Control and Monitoring System) and charting system. Upon inspection, it was determined to be a transmit-only connection, physically wired with only two conductors (ground and a single data line). This meant data could only flow from the PC to the bridge, preventing any external injection of commands. This effectively demonstrated a secure implementation for one part of the system.
• The second, and more critical, path connected directly to the PLCs (Programmable Logic Controllers) on the main engine. This connection utilized the Modbus protocol. Crucially, this link was found to be bidirectional, allowing the rugged PC to poll the PLCs for data (like revolutions per second, fuel consumption) and, conversely, allowing for commands to be sent to the PLCs.

1. Proof of Vulnerability through Modbus Analysis: The discovery of a live, bidirectional Modbus connection to critical PLCs, accessible via an undocumented Windows PC, served as the proof of concept. Brownridge explained that given access to this PC, an attacker could easily inject malicious Modbus commands. By leveraging the inherent lack of security in the Modbus protocol, an adversary could write arbitrary values to PLC registers, thereby directly manipulating engine parameters. This demonstrated a clear, actionable attack path that could lead to physical damage, operational disruption, or even loss of control over the vessel's propulsion system.

The "demo" thus wasn't a live exploit but a detailed, forensic account of how a real-world penetration test unveiled a significant, previously unknown vulnerability in a critical operational environment. It showcased the importance of physical security, asset inventory, and thorough network analysis in OT contexts.

Defensive Implications

▶ Watch: Autopilot systems and supply chain cyber attack vectors (6:20)

Paul Brownridge's findings highlight several critical areas for improving the cybersecurity posture of maritime operational technology. Defenders must adopt a holistic approach that considers both physical and network security, as well as operational procedures.

1. Comprehensive Asset Inventory and Visibility: The discovery of a hidden, undocumented rugged PC underscores a fundamental problem: many organizations lack a complete and accurate inventory of their OT assets. Defenders must meticulously map out all systems, including those that are old, forgotten, or installed ad-hoc. This includes physical reconnaissance ("walk arounds") to identify devices not visible on network scans or in documentation. Knowing what's running is the first step to securing it.

1. Network Segmentation and Isolation: The blending of IP networks with legacy serial systems via IP to serial converters creates critical junctures. OT networks, especially those controlling critical functions like propulsion and steering, must be rigorously segmented from IT networks and external internet connectivity. This limits the lateral movement of attackers and prevents easy access to vulnerable industrial protocols like Modbus.

1. Secure Configuration of Bridging Devices: IP to serial converters, while necessary, must be configured with security in mind. Where possible, enforce transmit-only or read-only communication if bidirectional control is not required, as demonstrated by the secure bridge-ICMS connection. Implement strong authentication and access controls on these devices themselves, and ensure they are patched and monitored.

1. Modbus Security Enhancements: The inherent insecurity of Modbus necessitates additional layers of protection. Defenders should explore solutions such as wrapping Modbus in more secure protocols (e.g., Modbus/TCP over VPN or TLS), implementing industrial firewalls to filter Modbus commands based on known good states, and deploying Intrusion Detection Systems (IDS) specifically designed to monitor for anomalous Modbus traffic or unauthorized write commands. Strict access control lists (ACLs) should be applied to prevent unauthorized devices from communicating with Modbus slaves.

1. Physical Security Controls: The fact that the vulnerable PC was "hidden in a panel" suggests a lack of robust physical security. Critical OT devices, especially those acting as bridges, must be housed in locked enclosures, with access restricted to authorized personnel. Physical access control, surveillance, and tamper detection are crucial to prevent direct manipulation or the installation of malicious devices.

1. Lifecycle Management and Decommissioning: Old, undocumented, or forgotten systems pose a significant risk. Organizations need clear policies and procedures for the lifecycle management of OT assets, including proper decommissioning. Systems that are no longer needed or whose function is unknown should be thoroughly investigated and, if safe to do so, powered down and removed.

1. Crew Training and Awareness: The "turn of engineers" and fear of turning off unknown systems contribute to the problem. Regular training for ship engineers and crew on cybersecurity best practices, asset identification, and the importance of reporting suspicious or undocumented equipment is vital. They are often the first line of defense and their awareness can prevent significant incidents.

1. Redundancy and Manual Overrides: While a cybersecurity measure, the emphasis on human intervention and physical override switches (for autopilot, steering, and generator startup) reinforces the importance of defense-in-depth. Defenders must ensure these manual controls are always functional, accessible, and that crew members are proficient in their use as a final safety net against automated system failures or cyberattacks.

By addressing these implications, maritime operators can significantly reduce their attack surface and enhance the resilience of their critical operational technology against sophisticated and opportunistic threats.

Key Takeaways

• Hybrid IT/OT Architectures Create Unique Risks: The integration of modern IP-based systems with decades-old serial industrial control systems, often via IP to serial connectors, introduces complex and often overlooked attack surfaces.
• Physical Reconnaissance is Paramount in OT: Discovering hidden, undocumented devices like the rugged Windows-based PC during a physical "walk around" highlights that traditional network scanning alone is insufficient for comprehensive OT asset inventory and vulnerability identification.
• Modbus Protocol's Inherent Insecurity: The use of Modbus for critical engine PLC communication, without additional security layers, creates a direct path for attackers to inject malicious commands and manipulate physical processes.
• Configuration Dictates Security Posture: Even with the same technology (IP to serial), a transmit-only wiring configuration for one link provided strong security, while a bidirectional Modbus connection on another link proved highly vulnerable.
• Human-in-the-Loop is a Critical Failsafe: The existence of physical override switches and manual control capabilities for steering and engine management serves as an essential last line of defense against both cyberattacks and system failures.
• Comprehensive Asset Management and Network Visibility are Non-Negotiable: The presence of undocumented systems running critical functions underscores the urgent need for complete asset inventories, rigorous network segmentation, and continuous monitoring in maritime OT environments.

About the Speaker(s)

Paul Brownridge is a cybersecurity professional with a strong background in operational technology (OT). He began his career as an engineer in Cape Town, South Africa, gaining hands-on experience in industrial environments. Through a series of career shifts, he transitioned into the field of cybersecurity, where he now specializes in OT testing across various sectors, including maritime, IoT, and APIs. Brownridge is known for his practical approach to security, often working with teams like the P2P group to conduct detailed assessments of complex industrial systems. His expertise lies in understanding the unique challenges of securing critical infrastructure where legacy systems interface with modern technology.