Modbus

Every Modbus transaction follows the same structure. The master sends a protocol data unit containing a function code and data. The slave responds with either the requested data or an exception code indicating why the request failed. In RTU mode, the protocol data unit is preceded by a slave address and followed by a CRC checksum. In TCP mode, it is preceded by a six-byte application data unit header containing a transaction identifier, a protocol identifier set to zero, and a length field, with the unit identifier taking the place of the slave address.

Function codes are the vocabulary of Modbus. The most common are FC01 for reading coils, FC02 for reading discrete inputs, FC03 for reading holding registers, FC04 for reading input registers, FC05 for writing a single coil, FC06 for writing a single holding register, FC15 for writing multiple coils, and FC16 for writing multiple holding registers. Each function code maps to a specific type of data access. Knowing which function codes are legitimate for a given device and which are not is the foundation of Modbus monitoring and anomaly detection.

The data model divides device memory into four tables that correspond to different physical quantities. Coils are single-bit values that typically represent discrete outputs such as relay states. Discrete inputs are single-bit read-only values from physical inputs. Holding registers are 16-bit read/write values used for setpoints, parameters, and output values. Input registers are 16-bit read-only values from sensors and measurements. This organization is a convention rather than a strict hardware mapping, and different vendors implement it differently, which is why reading device documentation is essential before interpreting captured Modbus traffic.

The distinction between Modbus RTU and Modbus TCP is important for both operational understanding and security assessment. Modbus RTU was designed for serial communication, typically over RS-485 multidrop buses where one master communicates with up to 247 addressed slaves on a single physical cable. The serial nature of the medium provides a degree of physical access control: an attacker must be on the cable or connected to a device on the cable to interact with the bus. This is not a strong security control, but it is a real one that disappears when the protocol is bridged to Ethernet.

Modbus TCP, standardized in 1999, takes the same protocol data unit and carries it over TCP connections, typically to port 502. The shift to TCP brings all the reach of Ethernet and IP routing with it. A Modbus RTU device that was physically isolated on a serial bus becomes a Modbus TCP device that may be reachable from anywhere on the plant network, from connected corporate networks, and potentially from the internet if network boundaries are not carefully managed. Many serial-to-Ethernet converters exist precisely to bridge legacy serial Modbus devices into modern network architectures, and they often introduce connectivity without introducing any access control.

From an attacker's perspective, Modbus TCP is significantly more accessible than Modbus RTU because it can be reached remotely without physical access to a serial cable. Scanning for port 502 on reachable networks is trivial, and tools for interacting with Modbus TCP are widely available. When assessing an OT environment, Modbus TCP exposure on port 502 should be treated as high priority, and any exposure beyond the control network zone should be considered a critical finding.

Modbus access gives an attacker a direct interface to process data and control functions with no authentication required. The attack surface is defined by what is mapped to the device's data tables. An attacker can systematically read all register addresses and coil addresses across all valid slave addresses to build a complete picture of process state: which outputs are active, what all the setpoints are, what the current measurements show, and how the system is behaving. This reconnaissance requires no special knowledge of the target device, only knowledge of how Modbus addressing works.

Write access is where the physical consequences begin. An attacker who knows or can infer which registers contain setpoints can alter them. A register that controls a temperature setpoint, a pressure limit, a speed reference, or a chemical dosing rate can be written with a new value that drives the physical process outside its intended operating range. Because the PLC or controller continues to operate its own control logic normally, and because the modified value looks like any other register write in the absence of monitoring, the change may persist and compound before operators notice anything wrong.

The coil write function is particularly direct. Writing to a coil that represents a physical discrete output can force that output on or off independently of the PLC's logic. This means an attacker can command a valve to open or close, a motor to start or stop, or a relay to energize or de-energize without going through any control logic at all. The effect is immediate and physical. Combined with the ability to read process state in real time, an attacker with persistent Modbus access has a highly capable interface for manipulating a physical process.

Because Modbus traffic from a legitimate master follows predictable patterns, it is well suited to anomaly detection. A production system typically communicates with a known set of slave addresses, uses a consistent set of function codes, reads from specific register ranges, and does so at regular polling intervals. Any deviation from these patterns, such as reads from unusual register addresses, write function codes appearing when the master only reads, or traffic from an unexpected source IP, is a meaningful signal worth investigating.

Industrial network monitoring tools that understand Modbus can parse function codes and data addresses and generate alerts based on policy rules. A simple but effective policy is to alert on any write function code observed on a network that is supposed to be read-only for monitoring purposes, or to alert on write operations to specific high-consequence register addresses. More sophisticated approaches build behavioral baselines and alert on statistical deviations.

Detection without response capability has limited value. When a suspicious Modbus write is detected, the response workflow needs to be defined in advance: who is notified, what manual actions operators should take to verify the physical state of the process, and how the affected device can be isolated if needed. In OT environments where stopping the process has its own consequences, the response plan must account for both the cybersecurity dimension and the operational dimension of any containment action.

Modbus cannot be patched to add authentication or encryption. The protocol is what it is, and the installed base is enormous. The security approach therefore focuses entirely on compensating controls: limiting who can reach Modbus devices, monitoring the traffic that does reach them, and ensuring that the consequences of any unauthorized access are bounded.

Network segmentation is the most important control. Modbus devices should be on a dedicated control network segment that is accessible only from authorized engineering workstations and master controllers, with that access enforced by firewalls that perform Modbus-aware deep packet inspection. Industrial firewalls can enforce function code allow lists, address range restrictions, and rate limits at the protocol level, providing a meaningful layer of control without requiring changes to the devices themselves.

Physical security remains relevant for serial Modbus deployments. RS-485 bus access points, serial-to-Ethernet converters, and serial port servers should be in locked panels or cabinets. Unauthorized physical access to these components is equivalent to unauthorized Modbus access. Inventory of all serial-to-Ethernet conversion points is a necessary first step in understanding the true exposure of a legacy Modbus RTU deployment, because these converters are often installed for convenience and forgotten without being documented in network diagrams.