Modbus Security Vulnerabilities: No Auth, No Encryption, No Problem?

Modbus was designed in 1979 by Modicon for serial communication between PLCs. In 1979, the threat model was simple: the devices were physically isolated. Nobody imagined connecting a programmable logic controller to a TCP/IP network accessible from a corporate laptop — let alone the internet.

Today, Modbus TCP is the most widely deployed protocol in OT environments. And it has zero authentication, zero encryption, and zero message integrity checking. Any device on the network can read any register, write any coil, and no Modbus device will refuse the request or even log that it happened.

How Modbus Works (and Why That's a Problem)

Modbus uses a master-slave model. The master (HMI, SCADA server, engineering workstation) sends requests; the slave (PLC, RTU, sensor) responds. The protocol defines a set of function codes that determine what operation to perform:

The critical column is the last one. Function codes 0x05, 0x06, 0x0F, and 0x10 directly change the physical state of industrial equipment — and any device on the Modbus TCP network can issue them with no credentials required.

The Attack Surface: CVE Analysis

The most relevant Common Weakness Enumerations for Modbus are:

• CWE-306 — Missing Authentication for Critical Function. The protocol has no concept of identity or credentials. Every Modbus device is vulnerable by design.
• CWE-319 — Cleartext Transmission of Sensitive Information. Register values, setpoints, and process data are transmitted in plaintext with no encryption.
• CWE-345 — Insufficient Verification of Data Authenticity. There is no way to verify that a received Modbus frame originated from a legitimate master.
• CWE-294 — Authentication Bypass by Capture-replay. Captured valid Modbus frames can be replayed indefinitely since there are no timestamps or sequence numbers.

A Real Attack: Modbus MITM in 12 Lines

A man-in-the-middle attack on a Modbus TCP network requires only ARP spoofing and a packet manipulation library. Here's the conceptual flow:

# Step 1: ARP poison — tell the HMI that the PLC's IP maps to our MAC
arp_spoof(target=HMI_IP, spoof=PLC_IP)

# Step 2: Forward all traffic except the frames we want to modify
# Step 3: Intercept a FC03 Read Holding Registers response
frame = capture_modbus_response()

# Step 4: Modify the register value (e.g., temperature setpoint)
#         The HMI sees 75°C; the actual value is 240°C
frame.data[4:6] = b'\x00\x4B'  # 75 decimal — falsified reading

# Step 5: Send a FC06 Write Single Register to the PLC directly
#         Set the actual setpoint to 240°C while HMI shows "normal"
send_modbus(FC06, register=40001, value=0x00F0)  # 240 decimal

This attack is undetectable by the PLC (it sees valid Modbus frames from a valid IP) and invisible to the operator (the HMI sees falsified readings). The attack was demonstrated at multiple ICS security conferences and underpins the Stuxnet-era technique of false data injection.

Real-World Incidents Involving Modbus

While many ICS incidents go unreported, several documented cases involve Modbus exploitation:

• Oldsmar Water Treatment (2021) — An attacker used remote access to issue a Modbus write command changing sodium hydroxide concentration from 111 ppm to 11,100 ppm. A vigilant operator noticed the cursor moving and reversed it manually. No Modbus authentication was in place.
• Industroyer/Crashoverride (2016) — The Ukraine power grid malware included a dedicated Modbus module for persistence, issuing commands to RTUs alongside its primary IEC 104 payload.
• Triton (2017) — After compromising Safety Instrumented Systems, attackers used Modbus to communicate with PLCs in the same OT segment, gathering process data to time the safety system attack.

Practical Defenses

Since Modbus itself cannot be fixed, defense requires compensating controls at the network and architecture level:

1. Network Segmentation (Most Impactful)

Place Modbus devices in a dedicated OT network segment. Use a next-generation firewall or industrial demilitarised zone (DMZ) to allow only expected master-slave pairs. No general-purpose IT host should be able to reach a Modbus TCP port (502/TCP) directly.

IEC 62443 reference: SR 5.1 — Network Segmentation. Zone/Conduit architecture ensures that even if the IT network is compromised, attackers cannot reach Modbus devices directly.

2. Deep Packet Inspection with an OT-aware IDS

Deploy an ICS-specific intrusion detection system (e.g., Claroty, Dragos, Nozomi Networks) that understands Modbus function codes. Configure alerts for:

• FC05/FC06/FC0F/FC10 from any host not in the approved master whitelist
• Any FC to a unit ID not in the expected device inventory
• Register writes outside the expected value range (process baseline deviation)
• New Modbus masters appearing on the network

3. Application-Layer Firewalling

Some industrial firewalls (Tofino, Fortinet FortiGate NGFW with ICS signatures) can enforce Modbus function code allow-lists — permitting FC01/FC03 (read) but blocking FC05/FC06/FC10 (write) unless the source IP is an authorized engineering workstation. This is not native to Modbus but adds a compensating control at the network layer.

4. Encrypted Tunnels (VPN/TLS Wrapper)

For Modbus TCP over WAN links (e.g., SCADA polling RTUs remotely), wrap Modbus inside an IPsec VPN or TLS tunnel. This does not add authentication to Modbus itself but prevents eavesdropping and replay attacks over untrusted network segments.

5. Network Behaviour Baselining

Passively monitor Modbus traffic to establish a baseline of normal register addresses, function codes, and master-slave pairs. Any deviation — a new FC06 write to a register that has never been written, or a read from an unknown host — is an alert trigger. This approach (anomaly-based OT IDS) is now the industry standard for legacy protocol security.

Why This Isn't Going Away

The estimated installed base of Modbus-enabled devices is in the hundreds of millions. Water treatment plants, manufacturing lines, oil & gas pipelines, and power substations all run Modbus. Most have operational lifespans of 15–30 years. You cannot replace Modbus — you have to design around it.

The security community's approach has shifted from "fix Modbus" (impossible) to "compensating controls + network visibility" (achievable). IEC 62443's Zone and Conduit model, combined with passive OT IDS, gives defenders visibility without requiring any changes to the Modbus devices themselves.

Summary

• Modbus has no authentication, encryption, or integrity checking — by design
• Any device on the network can issue write commands with no credentials
• Key attacks: MITM with register manipulation, replay, false data injection
• Defense relies on network segmentation, function code filtering, and OT-aware IDS
• IEC 62443 SR 5.1 and NIST 800-82 both mandate network segmentation as the primary compensating control