Listen to this Post
Introduction
Industrial control systems (ICS) and programmable logic controllers (PLCs) were designed for reliability and real-time performance, not security. Attackers no longer need zero‑day exploits – they simply query public search engines like Shodan to find exposed Modbus TCP (port 502), IEC 104 (port 2404), and Siemens S7 (port 102) devices that lack authentication or encryption. This article shows you exactly how to discover your own exposed OT assets, shut down direct internet access, and deploy deception techniques to catch attackers before they manipulate physical processes.
Learning Objectives
- Identify exposed OT devices using Shodan, Nmap, and protocol‑specific reconnaissance techniques.
- Implement network isolation, firewall rules, and secure remote access (VPN + jump hosts) to protect PLCs.
- Deploy protocol‑aware monitoring, decoy PLCs, and anomaly detection to detect unauthorised write commands.
You Should Know
- Finding Your Exposed PLCs with Shodan and Nmap
Shodan indexes internet‑facing devices by banner grabbing. Attackers use it to build target lists without sending a single exploit packet. You must proactively check your own public IP ranges.
Step‑by‑step guide (Linux / Windows WSL):
1. Install Shodan CLI (requires Python):
pip install shodan shodan init YOUR_API_KEY Get free API key from shodan.io
- Search for your organisation’s IP range (replace
YOUR_NETWORK_CIDR):shodan search --limit 100 --fields ip_str,port,org,product net:YOUR_NETWORK_CIDR port:502,102,2404
-
Use Nmap for deeper banner grabbing (identify vendor and firmware):
nmap -p 502 --script modbus-discover --script-args modbus-discover.aggressive=true <target_IP> nmap -p 102 --script s7-info <target_IP>
-
Interpret results – if you see `Modbus/TCP` without authentication or `Siemens S7` with firmware version, assume an attacker can read/write registers.
Windows alternative: Use `Test-NetConnection` and the free `ModbusPoll` tool to connect to port 502 and attempt a read coil operation.
2. Immediate Isolation: Firewall Rules and Port Blocking
If you find an exposed PLC, close the hole immediately – even if it means halting remote diagnostics. Do not wait for a maintenance window.
Step‑by‑step guide:
- Linux (iptables / nftables) – block inbound OT protocols at the edge firewall:
iptables -A INPUT -p tcp --dport 502 -j DROP Modbus iptables -A INPUT -p tcp --dport 102 -j DROP S7 iptables -A INPUT -p tcp --dport 2404 -j DROP IEC 104 iptables-save > /etc/iptables/rules.v4
2. Windows Firewall (PowerShell as Admin):
New-NetFirewallRule -DisplayName "Block Modbus 502" -Direction Inbound -Protocol TCP -LocalPort 502 -Action Block New-NetFirewallRule -DisplayName "Block S7 102" -Direction Inbound -Protocol TCP -LocalPort 102 -Action Block
- Verify isolation – re‑run Shodan scan or use `nmap` from an external VPS to confirm ports are filtered/closed.
-
Detecting Unauthorised Modbus Write Commands with tcpdump and Wireshark
Attackers don’t need malware – they use legitimate protocol functions like Function Code 06 (Write Single Register) or 05 (Write Single Coil). Your SOC may miss these because they look like normal traffic.
Step‑by‑step guide to capture and detect:
- Capture traffic on the OT switch span port (Linux):
sudo tcpdump -i eth0 'tcp port 502' -s 1500 -C 100 -G 3600 -W 24 -w modbus_%Y%m%d_%H%M%S.pcap
2. Extract all write commands using `tshark`:
tshark -r capture.pcap -Y "modbus.func_code == 6 or modbus.func_code == 16 or modbus.func_code == 5" -T fields -e ip.src -e ip.dst -e modbus.func_code -e modbus.quant
- Set up real‑time alert with `ngrep` and
sendmail:sudo ngrep -d eth0 -q -W byline '^\x00\x00\x00\x00\x00\x06\x01\x06' port 502 Bytes: Transaction ID (0), Protocol ID (0), Length (6), Unit ID (1), Function 06
-
Wireshark display filter for analysts: `modbus.func_code == 6 || modbus.func_code == 5 || modbus.func_code == 15 || modbus.func_code == 16`
- Building a Decoy PLC with OpenPLC and Canary Tokens
Deception is a game changer. Deploy a low‑interaction honeypot that mimics a Siemens or Modbus device. Real engineers will never touch it; attackers will – and you’ll get an immediate alert.
Step‑by‑step guide:
- Install OpenPLC on a Raspberry Pi or VM (Ubuntu 22.04):
git clone https://github.com/thiagoralves/OpenPLC_v3.git cd OpenPLC_v3 ./install.sh
2. Configure Modbus slave on port 502:
- Edit `/opt/openPLC/webserver/core/hardware_layer.py` to set `MB_TCP_PORT = 502`
– Start service: `sudo systemctl start openplc`
-
Add a canary token that triggers on any Modbus read/write:
Using Canarytokens.org – generate a "TCP port token" for port 502, pointed to your decoy IP Or use local Python listener: python3 -c "import socket; s=socket.socket(); s.bind(('0.0.0.0',502)); s.listen(); while True: c,a=s.accept(); print(f'ALERT: Connection from {a}'); c.close()" -
Place decoy PLC in the same OT VLAN but with no real process I/O. Monitor logs – any interaction is hostile.
-
Secure Remote Access Architecture: VPN + Jump Host
Never expose raw ICS protocols. The correct model is: Engineer → VPN (with MFA) → Jump host / bastion → PLC via allowed protocol gateway.
Step‑by‑step guide using WireGuard (Linux) and Windows client:
- Set up WireGuard server on a hardened Linux VM inside the OT perimeter:
sudo apt install wireguard cd /etc/wireguard/ umask 077; wg genkey | tee privatekey | wg pubkey > publickey
2. Create server config `/etc/wireguard/wg0.conf`:
[bash] Address = 10.0.1.1/24 PrivateKey = <server_priv> ListenPort = 51820 PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
- Client config (Windows/macOS/Linux) – import tunnel, force all traffic or split‑tunnel.
-
Jump host – after VPN, engineer must SSH/RDP to a bastion host that has outbound access to PLCs. No direct VPN‑to‑PLC routing.
6. Continuous Monitoring with Protocol‑Aware DPI (Zeek)
Traditional IDS misses Modbus command anomalies. Use Zeek (formerly Bro) to parse OT protocols and detect abnormal sequences like writes to critical registers outside business hours.
Step‑by‑step guide:
1. Install Zeek on a span port mirror:
sudo apt install zeek export PATH=$PATH:/opt/zeek/bin
2. Enable Modbus analyser – edit `/opt/zeek/share/zeek/site/local.zeek`:
@load protocols/modbus
event modbus_write_single_register(c: connection, header: ModbusHeaders, register: count, value: count)
{
if ( register == 40001 ) Critical pressure register
print fmt("ALERT: Write to critical register %d from %s", register, c$id$orig_h);
}
3. Run Zeek:
sudo zeek -i eth0 local.zeek
- Integrate with SIEM – send logs via syslog or Zeek’s `notice` framework.
-
Hardening PLCs: Disabling Unused Protocols and Adding Authentication Wrappers
Most PLCs have debugging services, default credentials, and unprotected web servers. Turn them off. For legacy devices that cannot be upgraded, place an authentication gateway in front.
Step‑by‑step vendor‑specific commands (Siemens S7‑1200/1500 example):
1. Disable unprotected PUT/GET in TIA Portal:
- Device configuration → Protection & Security → “Permit access with PUT/GET communication” → Uncheck.
-
Change default password (no default “admin” or “ ”).
-
Close unused ports – disable web server (port 80/443), SNMP, and OPC UA if not used.
-
Use a secure proxy – e.g., `modbus-proxy` (Python) that enforces allowlist of register addresses and function codes:
from pymodbus.server import StartTcpServer from pymodbus.datastore import ModbusSlaveContext, ModbusServerContext Add custom filtering logic for writes
-
Deploy physical network segmentation – managed switch with ACLs that only allow specific engineering workstation MAC addresses.
What Undercode Say
Key Takeaway 1: Attackers don’t need exploits – unauthenticated OT protocols are their entry point. Shodan does the reconnaissance for free.
Key Takeaway 2: Deception (decoy PLCs) and protocol‑aware monitoring catch what firewalls miss – abnormal write commands and unauthorised connections.
Analysis: The OT security gap is not about patch management; it’s about basic hygiene – removing direct internet exposure, adding VPNs, and monitoring protocol commands. Most organisations spend millions on IT security but leave Modbus wide open. The physical consequences (pressure changes, valve manipulation, pump overspeed) are real and often have no safety alarm because the process “drifts” slowly. The post and comments correctly emphasise that “if it’s reachable, it’s already a target.” What’s missing in many shops is the feedback loop: continuous external scanning (weekly Shodan checks), internal deception, and SOC training to recognise Modbus function codes. AI can help baseline normal write frequencies and detect outliers, but even simple thresholds work. The bottom line: treat every OT protocol as hostile by default, segment relentlessly, and assume exposure until proven otherwise.
Prediction
Over the next 18 months, we will see a surge in OT‑targeted ransomware that doesn’t encrypt files – instead, it issues destructive write commands to PLCs (e.g., open all relief valves). Regulatory bodies (CISA, ENISA) will mandate monthly Shodan‑style exposure scans for critical infrastructure, with fines for any Modbus/S7 port open to the internet. Simultaneously, AI‑driven deception platforms will become standard – automatically deploying thousands of virtual decoy PLCs across OT networks, learning attacker TTPs in real time. Organisations that ignore network isolation will face physical asset damage and liability lawsuits. The OT hacker mindset is now the defender’s required mindset: assume your PLC is already indexed, and build your defences accordingly.
▶️ Related Video (64% Match):
https://www.youtube.com/watch?v=7wLkk7_QPXM
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Your Plc – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
