Modbus TCP Security: Vulnerabilities, Attacks, and Defenses

Introduction

Modbus is the most widely deployed industrial communication protocol in the world. Developed in 1979 by Modicon (now Schneider Electric) for serial communication between PLCs and computers, it was adapted to TCP/IP in the late 1990s and is now the de facto standard protocol for OT environments across virtually every industrial sector.

Modbus's ubiquity makes it a central target for OT attackers. The PIPEDREAM/CHERNOVITE toolkit explicitly targets Modbus TCP. Unauthorized Modbus write commands can modify process setpoints, force output states, and disrupt automation logic without any authentication check. Understanding Modbus security at a protocol level is foundational knowledge for every OT security engineer.

This guide covers the Modbus TCP protocol architecture, its inherent security limitations, documented attack techniques, detection methodologies, and a structured set of defenses for Modbus-dependent environments.

Modbus TCP Protocol Architecture

Protocol Structure

A Modbus TCP transaction consists of a request from a client (typically a SCADA server or HMI) and a response from a server (typically a PLC or RTU). The transaction uses a simple request-response model:

Application Data Unit (ADU) structure:

| MBAP Header (7 bytes) | Protocol Data Unit (variable) |

MBAP Header:

| Transaction ID (2 bytes) | Protocol ID (2 bytes) | Length (2 bytes) | Unit ID (1 byte) |

• Transaction ID: Identifier for matching responses to requests; chosen by the client
• Protocol ID: Always 0x0000 for Modbus
• Length: Byte count of the following PDU
• Unit ID: The slave address within the server device (for gateways with multiple downstream serial slaves; for direct TCP connections, typically 0xFF or 0x01)

Protocol Data Unit (PDU):

| Function Code (1 byte) | Data (variable) |

The PDU is the payload that carries the actual read or write command.

Data Model

Modbus defines four data tables accessible via protocol commands:

The address space for each table is 0 to 65535 (16-bit address). In practice, specific address ranges are mapped to specific process variables by the PLC engineer — the mapping is in the PLC program, not in the Modbus protocol itself.

Function Codes

The function code specifies the operation. Key function codes:

Function codes 05, 06, 0F, and 10 are the "write" function codes — the ones that change state in the controlled device. These are the function codes that security controls must most carefully govern.

Inherent Security Limitations of Modbus TCP

Modbus TCP was not designed with security in mind. Its security model is defined by its complete absence of security features:

No Authentication

Modbus TCP has no authentication mechanism. There is no concept of user credentials, session tokens, or cryptographic challenge-response. Any device that can establish a TCP connection to the Modbus server on port 502 can send any Modbus command without any authentication check.

The protocol was designed for serial communication between a single master and slaves on a dedicated bus — a context where physical access was the only security concern. Its TCP adaptation added network transport but not security.

Attack implication: An attacker who gains network access to a subnet containing Modbus-enabled devices can immediately send write commands to every device on that subnet. There are no credentials to steal, no account to brute-force. Network reachability equals control access.

No Authorization

Even if Modbus had authentication, it has no authorization model. There is no concept of "this client may read but not write" or "this client may write setpoints but not force outputs." Any client that can communicate at all can execute any function code, access any address range, and modify any accessible data table.

Attack implication: An attacker who gains access to a DMZ historian that has Modbus read access to a historian can, without any additional privilege escalation, attempt Modbus write commands — there is no protocol-level mechanism to differentiate read and write permissions.

No Integrity Checking

Modbus TCP provides no cryptographic integrity checking. A man-in-the-middle attacker positioned between a Modbus client and server can modify Modbus responses in transit — changing the process values that the SCADA system receives without the server or the client detecting the modification. This is the mechanism behind T0856 (Spoof Reporting Message) in ATT&CK for ICS.

Attack implication: Process values displayed to operators on HMIs, and recorded in historians, are only as trustworthy as the network path carrying the Modbus traffic. An attacker who has achieved a network-level man-in-the-middle position can deceive operators and historians about the actual state of the controlled process.

No Encryption

Modbus TCP provides no encryption. All transaction data — including the register values that represent setpoints, process parameters, and sensor readings — is transmitted in plaintext. Any device on the network path can capture and interpret the full content of every Modbus transaction.

Attack implication: Passive monitoring of Modbus traffic reveals complete operational data: current setpoints, control states, process parameters, and the specific address mappings that tell an attacker which register addresses correspond to which process variables. This reconnaissance data significantly lowers the barrier to a subsequent manipulation attack.

No Session Management

Modbus TCP has no session concept. Every Modbus PDU is independent. There is no session establishment, no session state, and no mechanism to detect session hijacking. A client that sends a Modbus write command with a valid format will receive a successful response regardless of whether it is the authorized client or a spoofed packet.

Documented Attack Techniques Against Modbus TCP

Reconnaissance: Device Fingerprinting

Technique: Send a Read Device Identification request (Function Code 0x2B) to enumerate device vendor, product name, firmware version, and product code. This information feeds the attacker's knowledge of which specific vulnerabilities and attack techniques apply to the target device.

Modbus scanning tools: Several open-source tools support Modbus device scanning:

• modscan: A command-line tool for Modbus device polling
• mbtget: Python-based Modbus client for register polling
• PIPEDREAM included Modbus scanning capability for network discovery

Defense: Restrict access to Modbus TCP port 502 to authorized source addresses only (firewall rule). Detection: alert on Function Code 0x2B requests from sources other than authorized SCADA/engineering assets.

Register Mapping Discovery

Technique: Systematically read across all register address ranges to map which addresses are populated with data and what that data represents. By observing register value patterns and changes correlated with known process events, an attacker can build a process model — understanding which register addresses correspond to which physical process variables.

Execution: Read Holding Registers (FC 0x03) for addresses 0 through 65535. The response will contain zero values for unmapped addresses and non-zero values for mapped addresses. Repeat for Coil (FC 0x01) and Input Register (FC 0x04) spaces.

Defense: Firewall rule limiting Modbus TCP access to authorized source addresses prevents reconnaissance. Detection: alert on sequential register reads spanning large address ranges (consistent with systematic mapping rather than operational polling), or on reads to address ranges that authorized clients do not normally access.

Unauthorized Write Attacks (PIPEDREAM Style)

Technique: Use the register mapping knowledge gained through reconnaissance to send Modbus write commands that modify specific process parameters to achieve a desired effect:

• Write Single Register (FC 0x06) to modify a setpoint register — changing a temperature or flow setpoint to an unsafe value
• Write Multiple Registers (FC 0x10) to modify a block of control parameters simultaneously
• Write Single Coil (FC 0x05) to force an output — opening a valve, starting a pump, or disabling an interlock

PIPEDREAM's Modbus module specifically targets Schneider Electric Modicon M340/M580 PLCs. The module performs reconnaissance to identify the device and then executes write commands via Modbus to modify controller logic and force output states.

Defense:

• Firewall DPI restricting write function codes (0x05, 0x06, 0x0F, 0x10) to specific authorized source addresses
• Application-layer firewall rules restricting write access to specific address ranges
• OT monitoring platform alert on write commands from unauthorized sources (T0855 detection)

Man-in-the-Middle Response Spoofing

Technique: An attacker with network-level MITM capability (via ARP poisoning, VLAN hopping, or physical network access) intercepts Modbus responses in transit and replaces actual process values with spoofed values. The SCADA system receives falsified data while the actual process is in a different state than displayed.

The TRITON attack incorporated a MITM component: while the SIS logic was being modified, normal process data was replayed to the DCS to prevent operators from observing an anomaly. This is a direct application of Modbus response spoofing at a sophisticated level.

Defense:

• Network architecture that prevents MITM positioning: dedicated Layer 2 segments for PLC communications, not shared segments with other devices
• Cross-validation of Modbus sensor values against independent data sources (independent instruments, physical gauges, historian-based statistical validation)
• Detection through anomaly analysis: physically impossible sensor value combinations, sensors that stop changing when they should be responding to process changes

Denial of Service via Connection Flooding

Technique: Establish multiple simultaneous TCP connections to the Modbus server port. Many PLC Modbus TCP stacks support a limited number of simultaneous connections (typically 4-8). Exhausting the connection table prevents legitimate SCADA servers from establishing connections, causing loss of visibility and control.

Defense: Firewall rule limiting the source addresses permitted to connect to Modbus TCP port 502. Rate limiting on connection establishment at the firewall. Detection: alert on connection count to Modbus port from unexpected sources.

Logic Modification via Function Code 66 (Schneider Write Logic)

Technique: Schneider Electric Modicon PLCs support a Modbus extension (Function Code 0x42/0x66) for writing controller logic in certain older firmware versions. PIPEDREAM included a module that exploited this capability to upload modified control logic to Modicon devices.

Defense: Update Modicon firmware to versions where this capability has been removed or requires authentication. Implement Modbus DPI firewall rules that block non-standard function codes (anything above FC 0x17 not required for operations). Monitor for FC 0x42 or 0x66 from any source.

Modbus-Aware Firewall Configuration

An industrial firewall with Modbus DPI capability can enforce controls that a standard packet filter cannot:

Rule Design Principles

Restrict by source address first: The most impactful Modbus firewall rule restricts which source IP addresses can establish TCP connections to Modbus server ports:

Permit: Source=SCADA_Server_IPs, Destination=PLC_Subnet, Port=502, Protocol=TCP
Permit: Source=Engineering_WS_IPs, Destination=PLC_Subnet, Port=502, Protocol=TCP
Deny All: Destination=PLC_Subnet, Port=502

Apply function code restrictions: With Modbus DPI enabled, add function code restrictions per source:

Permit: Source=SCADA_Server_IPs, Destination=PLC_Subnet, Port=502, Modbus_FC=01,02,03,04 (read only)
Permit: Source=Engineering_WS_IPs, Destination=PLC_Subnet, Port=502, Modbus_FC=01,02,03,04,05,06,0F,10 (read+write, during maintenance windows only)

If the SCADA server requires only read access to operational data and does not need to write setpoints directly (setpoint changes go through the HMI operator), restrict it to read-only function codes. Engineering workstations that do require write access can be permitted separately.

Restrict address ranges: The most granular Modbus DPI controls limit write access to specific register address ranges:

Permit Write: Source=SCADA_Server, Destination=PLC_Unit1, Modbus_FC=06, Register=1000-1999 (setpoint range only)
Deny Write: Source=SCADA_Server, Destination=PLC_Unit1, Modbus_FC=06, Register=0-999,2000-65535

This configuration permits the SCADA server to write only to the specific register range mapped to authorized setpoints, blocking writes to all other address ranges even if the SCADA server is compromised.

Block non-standard function codes: Deny all Modbus function codes above 0x17 (23) unless specific vendor extensions are required and documented. PIPEDREAM's Modicon-specific logic write capability uses function codes above this range.

Firewall Logging for Modbus

Configure the Modbus-aware firewall to log:

• All permitted write commands (source, destination, function code, address range, value) — this creates an audit trail for all setpoint modifications
• All denied connection attempts — potential reconnaissance or unauthorized access
• All denied function code violations — potential attack attempts

Modbus write logs feed the change detection capability: comparing logged writes against authorized change records identifies unauthorized process parameter modifications.

OT Monitoring Platform Configuration for Modbus Detection

Communication Baseline for Modbus

The OT monitoring platform should baseline normal Modbus communication patterns for each PLC:

• Expected clients (source IP addresses and ports)
• Expected function code mix (typical read/write ratio and function codes used)
• Expected polling frequency (requests per second per client)
• Expected register address access patterns (which address ranges are normally accessed)

Deviations from baseline that should trigger alerts:

• New source address communicating with PLC on Modbus port
• Function code used that was not in the baseline (e.g., write function code from a client that only ever read)
• Access to register addresses not in the baseline (potential reconnaissance or manipulation)
• Significant change in polling frequency (potential DoS or bulk data read)

ATT&CK-Mapped Modbus Detections

Configure OT monitoring alerts mapped to ATT&CK for ICS techniques:

T0840 Network Connection Enumeration: Alert on Function Code 0x2B (Read Device Identification) from non-authorized sources, and on sequential read operations spanning large address ranges.

T0845 Program Upload: Alert on Modbus read operations to address ranges associated with logic storage (vendor-specific) from sources other than authorized engineering workstations.

T0843 Program Download: Alert on Modbus write operations to logic storage address ranges (vendor-specific, e.g., FC 0x42/0x66 on Modicon) from any source.

T0855 Unauthorized Command Message: Alert on write function codes (0x05, 0x06, 0x0F, 0x10) from sources other than authorized clients.

T0836 Modify Parameter: Alert on writes to register addresses mapped to critical process setpoints when the write occurs outside of authorized maintenance windows or from unexpected sources.

Compensating Controls for Legacy Modbus Installations

Many Modbus deployments involve legacy equipment that cannot be modified to improve security. Compensating controls provide meaningful protection without requiring device replacement:

Network Isolation as Primary Defense

For legacy PLCs with no authentication capability and no support for firewall DPI:

• Place the device in a dedicated network zone with the minimum required connectivity
• Allow only the specific source addresses (SCADA server, one engineering workstation) to communicate with the device on Modbus TCP port 502
• Block all other traffic to and from the device
• Monitor the device zone with the OT monitoring platform

This does not fix the protocol vulnerability but limits which devices can exploit it.

Passive Process Value Monitoring

For critical Modbus-accessible parameters, implement independent process value monitoring:

• Configure the OT monitoring platform to alert when specific register values (setpoints, critical parameters) change
• Cross-validate critical values against independent instrumentation (independent transmitters, physical gauges, alternative measurement paths)
• Configure SCADA alarm logic to alert on setpoint changes that exceed expected operational ranges

Protocol Whitelist Gateway

For environments where modifying the network topology around PLCs is impractical, a Modbus protocol whitelist gateway can be inserted in-line:

A protocol whitelist gateway sits in-line on the Modbus TCP connection and enforces function code and address range restrictions at the application layer. It passes only the specific Modbus transactions that are in the configured whitelist and blocks everything else. Vendors including Waterfall Security, Tofino (Honeywell), and Cisco offer in-line OT protocol filtering appliances that can serve this function.

Migration Pathways

For new deployments or major system upgrades, consider Modbus replacement or enhancement options:

OPC UA: The OPC UA protocol provides authentication, encryption, and integrity checking that Modbus entirely lacks. For new integrations between SCADA servers and modern PLCs (Siemens S7-1500, Rockwell 5370+, Beckhoff TwinCAT), OPC UA is the recommended replacement for Modbus wherever feasible.

Modbus Secure (Draft): There have been proposals for "Secure Modbus" extensions that add TLS transport to Modbus TCP. These have not achieved broad vendor adoption and are not a near-term migration path for most environments.

EtherNet/IP with CIP Security: For Rockwell and Ethernet/IP-native environments, CIP Security (TLS/DTLS with certificate-based authentication) provides the authentication and encryption that Modbus lacks. Adoption requires modern controller firmware and compatible engineering software.

For the installed base of Modbus-dependent equipment, these migration pathways are long-term objectives. The compensating controls described above provide meaningful security in the interim.

Conclusion

Modbus TCP's security limitations are not a failure of implementation — they are a result of the protocol's design context in 1979 and the absence of any security revision in the TCP adaptation. The protocol will be present in industrial environments for decades to come because the installed base is too large and too integrated to replace quickly.

Security for Modbus environments comes not from fixing the protocol but from controlling the network context in which it operates: limiting which devices can communicate with Modbus servers, restricting which function codes are permitted from which sources, monitoring all Modbus communication for deviations from baseline, and building detective controls that flag unauthorized writes before they achieve their intended effect.

These controls are achievable with existing industrial firewall technology, OT monitoring platforms, and sound network architecture. The absence of protocol-level security does not mean the absence of security — it means that the security must be implemented at the network and monitoring layers rather than within the protocol itself.

Beacon Security provides Modbus TCP security assessments, industrial firewall configuration for Modbus protocol control, and OT monitoring tuning for Modbus-dependent environments. Contact us to assess the security posture of your Modbus TCP deployments and implement appropriate controls.