Anatomy of an OT Attack Chain: From Auth Bypass to Root Shell

One box between IT and the plant floor

Most operational technology (OT) incidents do not begin with an exotic zero-day against a PLC. They begin with an ordinary networked device that was designed for reliability, not for a hostile network, and then quietly exposed to one. An IO-Link master, a protocol gateway, a remote terminal unit: a small Linux computer that speaks Modbus TCP or EtherNet/IP on one side and HTTPS or SSH on the other.

This post walks through a representative attack chain against exactly that kind of device, an eight-port IO-Link master gateway bridging field sensors and actuators to a PLC. Every step below maps to a well-understood weakness class and, more importantly, to a control that would have broken the chain. The point is not the specific product; it is the pattern, because the pattern repeats across the OT device market.

The target, from the attacker's point of view

Scanning the device's management interface reveals the shape of the problem:

SSH (Dropbear) on 22.

On the field side, the gateway drives eight IO-Link channels to physical sensors and actuators, and it talks north to a PLC over EtherNet/IP and Modbus TCP. Compromising the gateway therefore means the ability to *read and alter physical process data*, not merely to own a server.

Step 1 — Authentication bypass + command injection = root shell

The web UI and the CGI REST API share the classic OT device flaw: a request parameter is passed, unsanitised, into a shell command on the back end. Combined with an authentication check that can be skipped (a page that never verifies the session, or a hard-coded maintenance account), an attacker reaches the vulnerable endpoint without credentials and injects a command.

Because all services run as root, the injected command does not need a privilege-escalation stage. Command execution *is* root execution. In IT, command injection often lands you as `www-data` and the fight for root begins; in OT, the fight is frequently already over.

What breaks this step: input validation and least privilege. A device that ran its web service as an unprivileged account, and validated parameters against an allow-list, would have turned a full compromise into a contained one. You cannot patch the vendor's code, but you *can* refuse to expose that interface to any untrusted network (see Step 4).

Step 2 — Path traversal → SSH key theft

With or without the shell from Step 1, the file-viewer endpoint (here, an IODD file viewer) accepts a path and returns its contents. Supplying `../../../../etc/dropbear/` or the root user's `.ssh/` directory walks out of the intended directory and hands the attacker the device's private SSH keys.

Those keys are rarely unique per device. OT vendors routinely ship the *same* key across an entire product line, so a key lifted from one gateway may authenticate to every identical gateway in the plant, and in other plants. The attacker now has durable, "legitimate" SSH access that survives a web-UI patch.

What breaks this step: canonicalising and confining file paths, unique per-device credentials, and monitoring for SSH logins from unexpected sources. Since you cannot fix the firmware, treat any such device's management keys as already compromised and isolate accordingly.

Step 3 — Manipulate the process

This is where OT security stops resembling IT security. From the gateway the attacker can:

Alter sensor readings so the control logic and the human operator see a lie.

Inject actuator commands to move valves, motors, or relays directly.

Manipulate the PLC's process data over EtherNet/IP or Modbus TCP, protocols that, by design, assume every peer on the network is trusted and authenticated at the network layer, not the protocol layer.

The safety consequence, not the data-confidentiality consequence, is the headline risk. This is why OT threat models borrow the safety world's language of consequence and why frameworks like IEC 62443 exist alongside IT standards.

Step 4 — Lateral movement and pivot into the OT network

A gateway sits, by definition, on two networks. Having rooted it, the attacker uses it as a foothold to reach the rest of the cell or line: other gateways (using those shared SSH keys), the PLC, the engineering workstation, the historian. The single exposed device becomes the beachhead for the entire environment, exactly the scenario the Purdue Model's network segmentation is meant to prevent.

The defensive story, in order

Reading the chain backwards gives you a prioritised defence, and none of it requires a firmware fix you cannot make:

1. Segment ruthlessly. No OT management interface should be reachable from IT or the internet. Enforce the Purdue Model with firewalls and a DMZ between levels; a device that an attacker cannot reach cannot be exploited. This one control breaks the chain at Step 1.

2. Put a jump host and MFA in front of OT management. If SSH and web UIs are only reachable through a monitored, authenticated bastion, stolen device keys lose most of their value.

3. Treat vendor-shipped keys and default accounts as compromised. Rotate what you can, isolate what you cannot.

4. Monitor the protocols. Passive OT monitoring that baselines normal Modbus/EtherNet/IP traffic will flag injected commands and rogue sources without touching the fragile devices themselves.

5. Map your controls to a framework. NIST SP 800-82 Rev. 3 and IEC 62443 both give you a structured way to justify each of the above to leadership and auditors.

Practise the reasoning, not just the facts

Recognising this chain in an exam or an interview is a matter of pattern, not memorisation: exposed management interface, injection to root because of no privilege separation, traversal to durable credentials, then abuse of trust-by-default industrial protocols to reach physical process and pivot. Our [OT Security Lab](/labs/ot-security-lab) walks through enumerating and reasoning about ICS/OT environments, and the [ot_security practice bank](/certifications/ot_security) drills the concepts, from Purdue-Model segmentation to protocol weaknesses, that decide whether you see the chain coming.