Modbus TCP - an industrial control protocol with no security
Modbus TCP (port 502) - protocol overview, lack of authentication and encryption, function codes, known attacks, segmentation and DPI filtering recommendations per IEC 62443.
Modbus is one of the oldest and most widely used communication protocols in industrial automation. Developed in 1979 by Modicon (now Schneider Electric) for PLC communication, it has survived nearly half a century - and still runs in millions of installations worldwide. The TCP/IP version, defined in the 1999 Modbus/TCP specification, moved this simple protocol from RS-485 serial links to Ethernet networks. That migration introduced a fundamental threat: a protocol designed for isolated serial networks was now operating in an environment where any host on the network could send it a command.
How Modbus TCP works
Modbus TCP is a client-server protocol (master-slave in serial terminology). The client (e.g. a SCADA system, HMI) sends a request to the server (PLC, RTU, I/O module). Each request contains a Function Code (FC) specifying the operation type and a data address.
Communication follows a request-response model: the client sends a query, the server replies with data or an acknowledgement. There is no subscription or notification mechanism - the client must actively poll the servers.
Modbus TCP frame structure (Application Data Unit - ADU):
| Field | Size | Description |
|---|---|---|
| Transaction ID | 2 bytes | Transaction identifier (pairs request with response) |
| Protocol ID | 2 bytes | Always 0x0000 for Modbus |
| Length | 2 bytes | Length of the remaining frame |
| Unit ID | 1 byte | Device address (1-247), relevant for Modbus-serial gateways |
| Function Code | 1 byte | Operation code (1-127) |
| Data | variable | Request/response data |
The protocol’s simplicity is both its greatest strength (easy implementation, broad support) and its greatest weakness (complete absence of security mechanisms).
Technical parameters
| Parameter | Value |
|---|---|
| Port | 502/TCP |
| Transport | TCP/IP |
| Authentication | None |
| Encryption | None |
| Data integrity | CRC (TCP transport layer only) |
| Standard | Modbus Application Protocol Specification V1.1b3 |
| Organization | Modbus Organization (modbus.org) |
Function codes and their risk
Every Modbus command contains a function code (FC) specifying the operation. Understanding these codes is essential for configuring DPI (Deep Packet Inspection) rules on OT firewalls. The table below classifies the most important codes by risk level - a full analysis is available in the article on remote access to ICS systems.
| Function Code | Operation | Risk | Recommendation |
|---|---|---|---|
| FC 01-04 | Read Coils / Discrete Inputs / Holding Registers / Input Registers | Low | Allow from trusted sources |
| FC 05-06 | Write Single Coil / Register | High | Only from authorized engineering stations |
| FC 15-16 | Write Multiple Coils / Registers | High | As above - changes multiple values in a single command |
| FC 08 | Diagnostics (loopback, restart, reset counters) | Medium | Block from untrusted networks |
| FC 43 (0x2B) | Read Device Identification | Medium | Reveals manufacturer, model, firmware version |
An attacker who gains access to a network with Modbus devices needs no credentials - just a TCP packet to port 502 with a valid function code.
Security assessment
No authentication
Modbus TCP has no authentication mechanism whatsoever. Any host on the network that can establish a TCP connection on port 502 can read and write controller registers. There is no concept of a user, password, certificate, or token. The device has no way to distinguish a legitimate SCADA command from one sent by an attacker.
No encryption
All communication occurs in cleartext. A traffic capture tool (e.g. Wireshark with the Modbus plugin) can read every packet - including register values, digital output states, and control commands. An attacker in a man-in-the-middle position can not only eavesdrop but also modify packets in transit.
Known attacks and incidents
Although Stuxnet - the most well-known attack on ICS systems - did not use Modbus (it operated on the Siemens S7comm protocol), many other attacks and offensive tools rely on Modbus:
- Sality botnet (2014) - researchers Kyle Wilhoit and Stephen Hilt (Trend Micro) documented a botnet scanning the internet for Modbus devices on port 502 and actively modifying register values. The attack was fully automated.
- CrashOverride/Industroyer (2016) - while the main modules operated on IEC 104 and IEC 61850, the malware’s modular architecture demonstrated how easily support for another OT protocol could be added. Modbus was within the attackers’ reach.
- TRITON/TRISIS (2017) - an attack on Triconex safety systems at a petrochemical facility in Saudi Arabia. Communication with SIS controllers used the TriStation protocol, but network reconnaissance included scanning for Modbus devices.
- Public tools - Metasploit Framework includes modules for Modbus TCP scanning and exploitation (modbusclient). Tools such as smod (Modbus penetration testing framework) and mbtget allow register reads and writes from the command line. The barrier to entry for an attacker is minimal.
Internet exposure
IoT search engines (Shodan, Censys) regularly identify thousands of Modbus devices accessible directly from the internet. According to Shodan data from 2025, over 9,000 devices respond on port 502 - including PLCs, Modbus-serial gateways, BMS systems, and photovoltaic inverters. Each of them is potentially vulnerable to unauthorized reads and writes.
MITRE ATT&CK for ICS
Modbus TCP is directly associated with multiple MITRE ATT&CK for ICS techniques:
| Technique | ID | Description |
|---|---|---|
| Point & Tag Identification | T0861 | Enumerating device registers and coils |
| Manipulation of Control | T0831 | Writing values to control registers |
| Unauthorized Command Message | T0855 | Sending commands without authorization |
| Monitor Process State | T0801 | Reading process state via FC 01-04 |
Segmentation and protection recommendations
TIP
Segmentation is the only effective protection for Modbus TCP. The protocol offers no built-in security mechanisms - it cannot be “patched” or “updated to a secure version.” Protection must be implemented at the network architecture level following the zones and conduits model of IEC 62443. A detailed guide to OT network segmentation is available in the article OT network segmentation - zones and conduits.
Key recommendations
-
Isolate the Modbus segment - Modbus TCP devices should reside in a dedicated OT network zone (VLAN), separated by an industrial firewall from other segments. Port 502 should never be accessible from the corporate IT network or the internet.
-
DPI filtering on OT firewalls - use firewalls with deep packet inspection that understand Modbus TCP. Define rules at the function code level: allow FC 01-04 (read) from SCADA/HMI systems, block FC 05-06, 15-16 (write) from all sources except authorized engineering stations.
-
Passive monitoring - deploy an OT network anomaly detection system (e.g. Nozomi Networks, Claroty, Dragos) operating in tap/span port mode. The system should alert on: unusual function codes, writes to registers from unknown IP addresses, register range scanning, and value changes outside established thresholds.
-
Connection allowlist - on the firewall, explicitly define which IP address pairs are allowed to communicate via Modbus TCP. Any connection outside the list should be blocked and logged.
-
Consider Modbus/TCP Security (RFC draft) - the Modbus Organization published a Modbus/TCP Security extension that adds TLS to the transport layer (port 802). However, this requires device manufacturer support - in practice it is only available in the newest controllers.
-
Eliminate internet exposure - regularly scan the organization’s external attack surface. Port 502 should never be accessible from the internet. This also applies to VPN gateways, LTE routers, and edge devices with port forwarding.
Summary
Modbus TCP is a protocol from 1979 that was never designed with security in mind. It has no authentication, encryption, or integrity mechanisms. Despite this, it remains one of the most common protocols in industrial automation - and will continue to be used for many years. The only effective protection strategy is defense in depth: network segmentation, DPI filtering, anomaly monitoring, and strict access control at the firewall level. Organizations planning modernization should consider migrating critical segments to protocols with built-in security, such as OPC UA.
Open source tools
| Tool | Language | Description | Link |
|---|---|---|---|
| pymodbus | Python | Full Modbus TCP/RTU/ASCII stack - client, server, simulator | GitHub |
| mbtget | Perl | Simple CLI client for querying Modbus TCP | GitHub |
| mbpoll | C | CLI for polling RTU/TCP slaves (Linux/Windows/macOS) | GitHub |
| QModMaster | C++/Qt | Graphical Modbus client with bus monitor | SourceForge |
| Wireshark | - | Built-in Modbus TCP dissector | wireshark.org |
TIP
For lab environment testing: pymodbus allows scripting queries. Read example: client.read_holding_registers(address=0, count=10, slave=1). For fuzzing: generate random function codes and addresses, observe the response. Never in production.
Sources:
- Modbus Application Protocol Specification V1.1b3 - Modbus Organization
- NIST SP 800-82 Rev. 3 - Guide to OT Security - NIST, 2023
- IEC 62443 - Industrial communication networks - IT security - IEC
- MITRE ATT&CK for ICS - MITRE Corporation
- Shodan - Industrial Control Systems - Modbus device exposure data
- Modbus/TCP Security Protocol Specification - Modbus Organization, 2018
- Who’s Really Attacking Your ICS Equipment? - Trend Micro, Wilhoit & Hilt, 2014
Need help in this area?
Our experts will help you assess the risk and plan next steps.