There and Back Again: Discovering OT Devices Across Protocol Gateways

There and Back Again: Discovering OT Devices Across Protocol Gateways

Speaker: Rob King

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch the full talk

Reading time: ~7 minutes

TL;DR

Operational technology (OT) devices — the PLCs, SCADA systems, and field devices controlling physical infrastructure — are increasingly reachable over IP networks, often with no authentication whatsoever. Security researcher Rob King walks through exactly how to discover these devices not just at the IP perimeter but through the protocol gateways that bridge legacy industrial buses to modern networks, using Modbus TCP, DNP3, and EtherNet/IP as case studies.

Introduction

For decades, operational technology lived in its own world: physically isolated on factory floors, connected by serial cables and proprietary buses, protected mainly by the fact that you had to be standing in the building to touch it. That world no longer exists. The convergence of IT and OT — information technology and operational technology — has brought PLCs and SCADA systems onto the same IP networks as enterprise laptops, cloud services, and the public internet. The security implications range from uncomfortable to genuinely alarming.

Rob King's BSidesSF 2025 talk cuts through the terminology confusion that plagues the OT space and delivers a concrete technical tour of how to discover OT devices that hide behind protocol gateways. The key insight: a protocol gateway is not a security boundary. Stopping discovery at the gateway misses the majority of the devices on an OT network.

▶ Watch: Defining OT and the convergence problem (02:00)

The Threat Landscape: OT Devices With No Concept of Authentication

Before getting into discovery techniques, King establishes why this matters. OT devices — programmable logic controllers, computer numerical control systems, remote terminal units — were designed to run in isolated environments where physical access was the only security model. Many have no concept of a login. Many that technically support passwords have them disabled. The hardware often lacked the CPU headroom to run cryptographic authentication in the first place.

The result of IT/OT convergence is that thousands of these devices are now reachable on the public internet. King's team has found exposed PLCs, power devices, and systems that could be remotely controlled — pumps, valves, industrial machinery — with no authentication barrier. Modbus, the dominant industrial protocol, appeared in 1978. TCP wasn't standardized until 1982. These protocols were designed before network security was a concept.

▶ Watch: Internet-exposed OT devices and the authentication gap (10:01)

Modbus TCP: The Encapsulated Interface

Modbus is the foundational OT protocol. The original serial version supported a simple "tell me your address" broadcast, but Modbus TCP — the IP-ported version — introduced something more powerful: the Modbus Encapsulated Interface (MEI). This is a mechanism for embedding richer command objects inside a standard Modbus frame, and it supports the Report Device Identity command.

When you send a properly formed MEI request to a Modbus device at a given address, the device responds with its vendor name, product name, and version information. The MEI response also includes a linked-list structure of identity objects with a "next object" pointer — King notes this pointer logic resembles DNS compression pointers, and carries similar potential for parser confusion.

For devices behind a protocol gateway, the Modbus address space is only 255 units on most serial configurations, making it practical to enumerate all reachable devices by iterating addresses. The gateway transparently proxies the MEI requests to the downstream bus, revealing devices that a pure IP-layer scan would never find.

▶ Watch: Modbus TCP and the Report Device Identity command (14:01)

DNP3: The Electrical Grid Protocol With Hidden Addressing

Distributed Network Protocol 3 (DNP3) is the de facto standard for electrical distribution networks in North America. When its designers ported it to TCP, they made an architectural choice that has significant security implications: they stacked the entire DNP3 protocol stack — transport layer, addressing layer, connection layer, application layer — directly on top of TCP without simplification. The original blocking and checksumming is preserved even inside a TCP stream.

This complexity creates a discovery puzzle. DNP3 addresses are 16-bit values, giving roughly 65,000 possible addresses. A secondary device (the field unit) will only respond to its pre-configured primary device (the master), verified at the DNP3 protocol layer — not just by IP address. To enumerate a DNP3 device, you need to know both the secondary address and its expected primary address. With 65,000 possible values for each, that's theoretically 4.2 billion combinations to try.

In practice, King notes, DNP3 networks tend to use small addresses starting at 1, rarely exceeding 512. But there's a better technique: DNP3 devices immediately emit an unsolicited status message when a TCP connection is established. This banner-grab reveals the device's own DNP3 address and the address of its expected primary. An attacker or auditor can then reverse those values to craft properly addressed requests, collapsing the search space dramatically.

▶ Watch: DNP3 address discovery via unsolicited connection banners (20:02)

EtherNet/IP and CIP: Discovery Across Hidden Backplanes

The most powerful — and most complex — discovery technique King covers involves EtherNet/IP and the Common Industrial Protocol (CIP). King takes a moment to acknowledge the naming is genuinely confusing: EtherNet/IP is "barely Ethernet and is not IP," while CIP (Common Industrial Protocol) shares an acronym with Critical Infrastructure Protection, a common set of OT regulations. The abbreviation ENIP is more common in practice.

EtherNet/IP supports a List Identity command at the IP layer — send a broadcast UDP packet and every EtherNet/IP device on the local network replies with its vendor name, device type, and firmware version. Rockwell Automation Allen-Bradley PLCs are among the most common responders. But this only surfaces the gateway itself, not the devices behind it.

To discover the hidden network, King uses CIP's Connection Manager Object. By building a CIP connection path through the gateway's backplane and out onto downstream buses — DeviceNet, ControlNet, or even serial RS-232 via an adapter card — you can traverse multiple hops and query devices that have no direct IP presence at all. The CIP route path specification supports this multi-hop traversal explicitly, letting a single IP-layer session pivot through protocol gateways, address translation, even NAT, to reach devices deep in the physical infrastructure.

King demonstrates traversing from Ethernet all the way through a 1734 PLC adapter to an RS-232 serial device — going from modern TCP/IP to 1970s-era serial in a single connected session.

▶ Watch: EtherNet/IP List Identity and CIP backplane traversal (22:03)

Standards Availability and Practical Caveats

King closes with useful notes on accessing the relevant specifications. The Modbus standard is freely downloadable from modbus.org — a short PDF, roughly six pages. DNP3 is also publicly available, though without a hard specification for attribute numbering (most implementations have standardized on Schneider Electric's numbering scheme). EtherNet/IP and CIP are more complicated: about half the ODVA specifications are publicly available; the other half require ODVA membership.

The answer to the audience question "how authentic is any of this signaling?" is sobering: once a command reaches the lowest layers of an OT network, there is generally no authentication. Authenticated CIP (CIP-S) exists but is rarely enabled. Sensors and field devices have essentially no mechanism to verify the authenticity of commands they receive. This is why King's recurring advice throughout the talk is direct: do not expose OT devices to the public internet.

Notable Quotes

"The biggest downside is you can, in fact, communicate with them remotely." — Rob King at 10:01, on the consequence of IP convergence for OT devices

"Protocol gateways are not where you should stop. If you're trying to really find everything on your network, don't stop at the protocol gateway. Keep going." — Rob King at 28:03

"I'm having to transit from Ethernet all the way to RS-232 classic serial to talk to another device and get information about it, and I love that." — Rob King at 28:03

Key Takeaways

• IP convergence has made OT devices reachable — and vulnerable. Thousands of PLCs and industrial control devices are exposed on the public internet with no authentication. This is a direct consequence of OT/IT convergence.
• Protocol gateways are not security boundaries. Modbus TCP, DNP3, and EtherNet/IP all provide mechanisms to traverse gateways and enumerate devices on the downstream bus.
• Modbus MEI enables vendor/product discovery. The Report Device Identity command in the Modbus Encapsulated Interface returns detailed device information; the address space is small enough to enumerate exhaustively.
• DNP3 devices announce themselves on connection. The unsolicited status message emitted at TCP connect time reveals the device's own address and its expected primary, short-circuiting brute-force address enumeration.
• CIP's Connection Manager Object enables multi-hop discovery. By building route paths through backplanes and downstream buses, an auditor can discover devices with no IP address at all — including RS-232 serial devices behind multiple protocol translation layers.