OT/ICS Security Home Lab: OpenPLC, Modbus, an HMI and a Honeypot

Part of our free Build Your Own Cyber Lab series. Work through it in order, or jump to the part you need.

1. Plan your lab: hardware, hypervisors and safe networking
2. VirtualBox and VMware basics, then Kali, Parrot and Windows 11
3. Beyond VirtualBox: Hyper-V, VMware Workstation and Proxmox
4. Dual boot Kali Linux and Windows safely
5. Ubuntu in your lab: desktop, server, SSH and Docker
6. Active Directory lab with Windows Server
7. Attack-and-defend network: firewall and vulnerable targets
8. Metasploitable 2 and 3: install and first exploits
9. Blue-team lab: Wazuh, Sysmon and Security Onion
10. Android app testing lab: emulator, MobSF, Frida and Burp
11. OT/ICS security lab: OpenPLC, Modbus and an HMI (you are here)
12. Network lab: build it in Packet Tracer or GNS3, read it in Wireshark

Why OT is different

Operational technology runs physical processes - pumps, valves, conveyors, power. In OT the priority order flips from confidentiality first to safety and availability first, and the protocols were designed decades ago for closed networks: many have no authentication at all. A home lab is the only safe place to see what that means in practice.

Never scan, probe or connect lab tools to real industrial equipment or networks, including anything at your workplace, without explicit written authorisation. Even a routine scan can crash a fragile controller.

The lab layout

Put them all on a dedicated isolated OT network, separate from your IT segments - which mirrors the zone-and-conduit separation in IEC 62443 and the Purdue model.

Step 1: Install the OpenPLC Runtime

OpenPLC is an open-source PLC that follows the IEC 61131-3 programming languages. On the PLC VM:

sudo apt install -y git
git clone https://github.com/thiagoralves/OpenPLC_v3.git
cd OpenPLC_v3
./install.sh linux

The install takes a while. Afterwards, start the runtime as the README describes and browse to http://<plc-ip>:8080. Log in with the default credentials from the project documentation and change them immediately - default credentials on real PLCs and HMIs are a classic OT finding.

Step 2: Write a tiny control program

Install the OpenPLC Editor on your workstation and build a simple ladder-logic program, for example a tank: a start button turns a pump on, a high-level sensor turns it off. Compile it, upload it through the runtime's web interface, and start the PLC. The runtime exposes the program's inputs, outputs and registers over Modbus TCP on port 502.

Step 3: Add an HMI

An HMI (human-machine interface) is the operator's screen. FUXA is an open-source web HMI/SCADA that runs in Docker:

docker run -d -p 1881:1881 frangoteam/fuxa:latest

Browse to http://<hmi-ip>:1881, add a Modbus TCP device pointing at the PLC's IP and port 502, map the pump coil and tank level register, and draw a simple screen with a button and an indicator.

Step 4: See why Modbus has no security

From Kali, read and write the PLC directly - no username, no password. With Python and the pymodbus library, or a command-line Modbus client, you can read coils and holding registers and write a coil to switch the pump. The PLC accepts it because Modbus has no concept of who is asking.

Watch the HMI as you do it: the operator's screen changes, but nothing tells them *why*. That is the core OT lesson - authentication and integrity have to come from network segmentation, monitoring and secure protocol variants, not from the legacy protocol itself.

Step 5: Monitor the OT network

• Wireshark has a Modbus/TCP dissector. Capture on the OT segment and filter with mbtcp to see function codes - reads (1-4) versus writes (5, 6, 15, 16).
• Zeek includes a Modbus analyser that logs function codes per connection. In Security Onion (part 9), watch for writes from any host that is not the HMI or engineering workstation.
• Build a baseline: which hosts normally talk to the PLC, and with which function codes? Anything else is worth an alert.

Step 6: A honeypot and a full simulated plant

• Conpot is a low-interaction ICS honeypot that emulates PLC services such as Modbus and S7. Run it on an isolated segment and scan it from Kali to see what attackers see - and what it logs.
• GRFICSv2 is a free, more complete virtual ICS environment with a 3D-visualised chemical process, PLC, HMI and engineering workstation, built for teaching ICS attacks and defence. It needs more resources but is the next step up.

Map it to the standards

Use the lab to make the frameworks concrete: draw your zones and conduits (IEC 62443), place each VM on a Purdue level, and compare your controls with NIST SP 800-82. Our ICS/OT field guide and OT security lab go deeper on both.

Keep it legal and contained

Only attack machines you own or have written permission to test. Vulnerable VMs and malware samples belong on an isolated network with no route to your home LAN or the internet, and never expose a deliberately vulnerable machine with a bridged adapter or a port forward.

Next step

Part 12 goes back to fundamentals: build a routed, switched network in Packet Tracer or GNS3 and read every protocol on it with Wireshark.