A Paperclip, a Superyacht, and a Bypassed Keylock

Sixty metres of floating luxury. One bent paperclip.

There is a particular tension that exists when you are standing in a teak-lined corridor of a sixty-metre superyacht, wearing deck shoes borrowed from the bosun's locker, holding a straightened paperclip, and preparing to bypass the only security control standing between you and the vessel's entire satellite communications infrastructure.

The paperclip cost a fraction of a penny. The satellite uplink cabinet it was about to open served a vessel valued in excess of forty million pounds. The assumption underpinning the vessel's network security was that physical control of the cabinet equated to control of the network. The cabinet was locked. Therefore the network was secure.

The lock was a tubular cam lock — the kind found on vending machines, office furniture, and filing cabinets across the world. It had a four-pin tumbler mechanism. It took us approximately ninety seconds to defeat it. What followed took rather longer to explain to the vessel's management company.

The Engagement Brief

The client was a yacht management company responsible for the technical and operational oversight of a fleet of large motor yachts. Following a series of high-profile incidents in the maritime sector — including GPS spoofing, ransomware attacks on shipping firms, and the compromise of satellite communication systems — the management company had taken the proactive step of commissioning a full security assessment of one of their flagship vessels.

The scope was comprehensive. We were tasked with assessing the vessel's IT and communication infrastructure from the perspective of an attacker with physical access equivalent to a guest, a temporary crew member, or a contractor working aboard. The engagement covered the satellite communication systems, onboard networking, crew and guest wireless networks, navigation and bridge systems (observation only — no active testing of safety-critical navigation equipment), and the physical security of network infrastructure.

The vessel was alongside in a Mediterranean port for a scheduled maintenance period. There were no guests aboard. The crew were aware that a security assessment was taking place but were not informed of the specific methods or timing. This arrangement gave us the freedom to operate as a realistic threat actor whilst ensuring that the vessel's operations and safety were never compromised.

We boarded at 0800 with a rucksack containing a laptop, a small wireless assessment kit, a USB Ethernet adapter, and a clear plastic bag of assorted items from a stationery cupboard. The last item would prove to be the most consequential.

Understanding the Vessel

Before beginning any technical assessment, we spent the first two hours conducting a physical survey of the vessel. A superyacht is a unique operational environment. Unlike a commercial office building, where network infrastructure is concentrated in server rooms and communication risers, a vessel distributes its systems across multiple decks, compartments, and technical spaces according to the logic of naval architecture rather than IT best practice.

This particular vessel had five decks. The lower deck housed the engine rooms, crew quarters, and the main technical compartment where the vessel's servers and network equipment were installed. The main deck contained the guest accommodation, the main saloon, and the galley. The upper deck held the bridge, the captain's cabin, and an exterior dining area. The sun deck was an open entertainment space. And the flybridge — the highest point of the vessel's superstructure — housed the satellite communication domes and their associated electronics.

The vessel's network architecture, as described to us by the chief officer, was straightforward. A VSAT (Very Small Aperture Terminal) system provided the vessel's primary internet connectivity via a Ku-band satellite link. This connected to a router in the flybridge electronics cabinet, which fed down to a core switch in the lower deck technical compartment. From there, the network branched into three segments: a crew network, a guest network, and a management network used for vessel operations, monitoring, and communication with the shore-based management company.

The chief officer was confident in the security of the arrangement. The technical compartment on the lower deck was locked and access-controlled. The flybridge electronics cabinet was locked. The bridge systems were in a secured space. Physical security, he explained, was the primary control.

The Flybridge Cabinet

We made our way to the flybridge. The satellite communication domes sat on the uppermost platform — two white radomes, one for the primary Ku-band VSAT link and one for a backup L-band terminal. Beneath them, mounted against the interior bulkhead of a small electronics enclosure, was the cabinet we had been told about.

The cabinet was a standard 12U wall-mounted rack enclosure, the kind used in marine environments — corrosion-resistant, vibration-dampened, with a glass-fronted door secured by a single tubular cam lock. Through the glass, we could see the VSAT modem, a managed Ethernet switch, a wireless access point, a media converter, a power distribution unit, and a tangle of Cat6 and coaxial cabling.

This single cabinet was the gateway between the vessel and the outside world. Every byte of internet traffic — crew email, guest streaming, operational data, remote monitoring telemetry, VoIP calls to shore — passed through the equipment behind this glass door.

The door was locked. The key was held by the chief officer. On paper, this was adequate physical security. In practice, there were two problems.

Defeating the Lock

The first problem was the lock itself. Tubular cam locks — sometimes called tubular pin tumbler locks or radial locks — are among the most commonly defeated lock types in physical security assessments. They use a circular keyway with pins arranged around the circumference, rather than the linear pin arrangement of a standard pin tumbler lock. They are compact, inexpensive, and ubiquitous in low-security applications.

They are also vulnerable to a well-documented bypass technique. A tubular lock pick — which can be purchased commercially or improvised from a biro tube — applies rotational tension to all pins simultaneously and can set them through progressive manipulation. For a four-pin tubular lock of the type fitted to this cabinet, the process is rapid.

We did not use a tubular lock pick. We used something simpler. The second problem with the cabinet was that the lock's retaining nut — the component that secures the lock barrel to the cabinet door — was accessible from the exterior of the cabinet. Using a straightened paperclip as a makeshift tool, we depressed the retaining clip and withdrew the entire lock barrel from the door in one piece. The door swung open. The lock was intact. It simply was no longer in the door.

Inside the Cabinet

With the cabinet open, we documented every device, every cable, and every visible configuration indicator. The equipment stack consisted of six primary components.

The first action we took was to connect our laptop to a spare port on the managed switch using the USB Ethernet adapter from our kit. The switch port came active immediately — no 802.1X, no MAC filtering, no port security of any kind. We received a DHCP lease on the 192.168.1.0/24 range.

We were now on the vessel's network, upstream of every other device aboard, sitting between the satellite uplink and the rest of the vessel's infrastructure.

Enumerating the Connectivity Stack

From our position in the flybridge cabinet, we performed a careful enumeration of the network. The topology was simpler than a typical corporate environment but the implications of compromise were proportionally greater — this network carried everything the vessel depended upon for communication with the outside world.

Sixteen devices. One subnet. No VLANs. No segmentation of any kind. The guest wireless network, the crew wireless network, the bridge systems, the CCTV, the AV and lighting controls, the vessel management server, and the satellite uplink were all on the same flat Layer 2 broadcast domain. A guest connecting to the wireless network in the main saloon was on the same network as the bridge PC and the VSAT modem.

The Firewall That Wasn't

We turned our attention to the firewall at 192.168.1.1. The web management interface was accessible on port 80 — unencrypted HTTP. The device was a consumer-grade router marketed for small office and home use. It was not a marine-rated device. It was not an enterprise firewall. It was the kind of device you might find in a suburban house, sitting on a shelf next to a broadband modem.

The login page accepted the manufacturer's default credentials. We had full administrative access to the vessel's gateway device.

The findings were severe. The firewall had no ingress or egress filtering rules — the default 'allow all' policy had never been modified. Three port forwards were configured, exposing the vessel server's RDP and HTTP management interface, and the CCTV system's RTSP feed, directly to the satellite WAN — meaning these services were accessible from the public internet via the vessel's satellite IP address. UPnP was enabled, allowing any device on the network to create additional port forwards without administrative approval. Remote management was enabled on the WAN interface, meaning the router's admin panel was accessible from the internet with the default credentials we had just used to log in.

The vessel's management server was accessible via RDP from the open internet. The CCTV system was streaming to anyone who knew the satellite IP address. The router itself could be reconfigured by any attacker who found it.

The VSAT Modem — Talking to the Sky

The VSAT modem at 192.168.1.2 was the device that maintained the satellite link — the vessel's lifeline to the shore-side world. Its web interface was accessible without encryption on port 80. The default credentials, predictably, had not been changed.

The modem's management interface provided extensive control over the satellite link. We could view and modify the transmission parameters, the satellite beam assignment, the allocated bandwidth, and the Quality of Service profiles that governed how traffic was prioritised across the link. We could see the shore-side teleport's configuration. We could view traffic statistics, connection logs, and error rates.

The SNMP service on port 161 was configured with the default community strings of public for read access and private for read-write access. Using snmpwalk, we extracted the full MIB tree, which disclosed the modem's firmware version, uptime, interface statistics, routing tables, and configuration parameters — including the satellite link credentials.

An attacker with this level of access could reconfigure the satellite link, redirect traffic through an attacker-controlled proxy, modify DNS settings to enable pharming attacks, degrade or disable the vessel's internet connectivity entirely, or exfiltrate traffic by mirroring the satellite interface. In an ocean environment, where the satellite link is the only connection to the outside world, control of the VSAT modem is control of the vessel's ability to communicate.

Guest Network to Bridge Systems

To demonstrate the full impact of the flat network architecture, we disconnected from the flybridge cabinet and moved to the main saloon on the guest deck. We connected to the guest wireless network — which was protected with a WPA2-PSK passphrase printed on a laminated card left on the coffee table for guests.

From the guest wireless network, we confirmed that every device we had enumerated from the flybridge cabinet was reachable. The bridge PC at 192.168.1.20 responded to ping. The chart plotter interface at 192.168.1.21 served its web page. The vessel server at 192.168.1.10 accepted RDP connections. The CCTV NVR at 192.168.1.11 streamed live feeds via RTSP. The VSAT modem's management interface was accessible. The firewall's admin panel was accessible.

A guest aboard the vessel — a charter guest, a visitor during a port call, anyone given the wireless password — had unrestricted network access to every system aboard, including bridge navigation displays, CCTV, the satellite uplink, and the vessel's management server.

We accessed the chart plotter's web interface from the guest network. It displayed the vessel's current position, planned waypoints, AIS data for surrounding vessels, and chart overlays. This interface was intended for use on the bridge. It was accessible from a sun lounger.

From Paperclip to Total Vessel Compromise

Maritime Security — The Floating Blind Spot

The maritime environment presents a unique combination of cybersecurity challenges that are poorly understood by the broader information security community and, more critically, by the maritime industry itself.

The IMO's Maritime Cyber Risk Management guidelines (MSC-FAL.1/Circ.3) recognise that maritime cyber risk should be addressed in Safety Management Systems. Flag state administrations are increasingly requiring cyber risk assessments. Classification societies are developing cyber security notations. But the practical reality aboard most vessels — particularly yachts, which fall outside many commercial regulatory frameworks — remains years behind the guidance.

The vessel we assessed had no firewall rules. No network segmentation. No changed default credentials on any infrastructure device. No firmware update programme. No intrusion detection. No logging. No monitoring. And the only physical security control protecting the entire communications infrastructure was a lock that cost less than the paperclip we used to bypass it.

Technique Mapping

Recommendations and Hardening

The remediation programme for this vessel required a combination of immediate actions to address the most critical exposures and a longer-term programme to bring the vessel's network architecture to an acceptable security baseline.

Network segmentation was the highest-impact recommendation. Guest, crew, operational, and bridge systems must be on separate VLANs with firewall rules governing inter-VLAN communication. A guest should never be able to reach the bridge PC, the CCTV system, or the VSAT modem. This segmentation should be enforced at the switch level and verified by policy.

The consumer-grade router must be replaced with a purpose-built marine firewall capable of stateful inspection, VPN termination, and granular access control. Several marine-rated products exist that are designed for the environmental conditions, power requirements, and operational constraints of vessel installations. The cost of an appropriate device is negligible relative to the value of the assets it protects.

The physical security of the flybridge cabinet must be upgraded. A high-security lock — ideally a restricted-key disc detainer or Abloy-style mechanism — should replace the tubular cam lock. The cabinet should be fitted with a tamper-evident seal that the crew can inspect during routine rounds. Access should be logged and restricted to authorised personnel only.

For remote shore-side management, the port forwards must be permanently removed and replaced with a properly configured VPN. Management traffic should traverse an encrypted tunnel initiated from the vessel, eliminating the need for any inbound port exposure on the satellite WAN address.

The ocean does not make you invisible.

There was a time when putting to sea meant leaving the connected world behind. That time has passed. A modern superyacht is a floating data centre with a sun deck. It carries the same network infrastructure as a small business — email, file servers, CCTV, access control, VoIP — and connects it to the internet via a satellite link that is visible to every scanning engine on the planet.

The physical isolation of the ocean is an illusion. The satellite link bridges it. The moment a vessel establishes a VSAT connection, it becomes a node on the public internet, subject to the same automated scanning, credential stuffing, and opportunistic exploitation that every other internet-connected device faces. The difference is that a vessel at sea cannot call an IT support company. It cannot switch to a backup ISP. It cannot physically disconnect and walk away.

We gained full access to this vessel's communications, CCTV, bridge displays, and management systems with a paperclip, a laptop, and four hours of work. An attacker with the same access — a disgruntled crew member, an opportunistic contractor, a determined adversary who books a charter — would have had the same results.

The lock on the cabinet was not the problem. The lock was a symptom. The problem was the assumption that physical security alone was sufficient to protect a network that was, in reality, exposed to the entire internet.

Until next time — stay sharp, stay curious, and check what is behind the locked cabinet. You might be surprised how little stands between you and everything.