Module 5 · IoT/OT Lab Walkthrough

Last updated: April 29, 2026

This module is the IoT/OT track capstone — a hands-on walkthrough of building a small lab and running a complete assessment cycle. Use it to practice safely before approaching real environments. Everything here is reproducible on a single workstation with VirtualBox or VMware and a few hundred rupees in hardware.

The lab — components

• Attacker box: Kali Linux VM
• Engineering workstation: Windows 10/11 VM with TIA Portal demo (Siemens) and a SCADA HMI demo
• Simulated PLC: OpenPLC (open-source IEC 61131-3 runtime) on a Raspberry Pi or in a Linux VM
• Simulated SCADA / HMI: ScadaBR or Rapid SCADA
• Honeypot to study: Conpot (low-interaction ICS honeypot)
• Network: isolated bridge between VMs; no internet routing
• Optional hardware: a real Modbus TCP gateway (~₹3000 used on OLX), Raspberry Pi running a simulated process

Phase 1: Set up OpenPLC

# On Linux VM
git clone https://github.com/thiagoralves/OpenPLC_v3.git
cd OpenPLC_v3
sudo ./install.sh linux
# Web interface on http://<ip>:8080 (default: openplc / openplc)

# Upload a sample ladder logic program (Programs tab)
# Configure Modbus TCP slave on port 502
# Run the PLC

Phase 2: Connect a SCADA

# Install ScadaBR on engineering Windows VM (or another Linux VM)
# Configure data source: Modbus TCP, IP of OpenPLC, port 502
# Add data points reading specific registers
# Build a simple HMI page showing the values

You now have a complete chain: simulated process (OpenPLC) → SCADA (ScadaBR) → operator HMI.

Phase 3: Run the assessment

Step 1 — passive observation

# From attacker box, capture traffic between SCADA and PLC
sudo tcpdump -i <bridge> -w ot-traffic.pcap host <plc-ip>

# Open in Wireshark; ICS dissector enabled
wireshark ot-traffic.pcap

# Observe Modbus function codes used, registers polled, polling interval

Step 2 — identify the PLC

# Single targeted scan, only port 502
nmap -sT -Pn -p 502 --script modbus-discover <plc-ip>

# Modbus discovery script reveals slave IDs and basic identity

Step 3 — read PLC registers (read-only, safe)

python3 -c "
from pymodbus.client import ModbusTcpClient
c = ModbusTcpClient('192.168.56.10', port=502)
c.connect()
for addr in [0, 100, 200, 1000]:
    r = c.read_holding_registers(addr, 10, slave=1)
    print(f'addr {addr}: {r.registers if not r.isError() else \"err\"}')
c.close()
"

Step 4 — write a register (lab only — would be DESTRUCTIVE in production)

# In our LAB:
python3 -c "
from pymodbus.client import ModbusTcpClient
c = ModbusTcpClient('192.168.56.10', port=502)
c.connect()
c.write_register(0, 9999, slave=1)        # set register 0 to 9999
c.close()
"

# Watch the SCADA HMI: the value should change.
# In the real world this is the action that ranges from "no effect"
# to "shut down the plant" — never test on production.

Step 5 — pivot from engineering workstation

Set up a phishing scenario in your lab:

1. From attacker box, send an email (use a local SMTP catcher) to the engineering Windows VM with a payload
2. Detonate the payload in the engineering VM — gets a beacon
3. From the beacon, observe network reachability — can you reach the PLC?
4. From the engineering workstation context, can you run TIA Portal-style commands against the PLC?

This demonstrates the most common real-world OT compromise path.

Phase 4: Defensive hardening

Now defend the lab:

1. Add a firewall (pfSense VM) between the engineering workstation and the PLC subnet. Allow only the specific source IP and port
2. Move OpenPLC behind the firewall; verify SCADA still works
3. Repeat the attack — now blocked at the firewall
4. Demonstrate the value of segmentation

Phase 5: Detection

Add monitoring:

1. Install Suricata on the network bridge; load Emerging Threats ICS rules
2. Run unauthorized read attempts; observe alerts
3. Tune false positives
4. Document detection coverage

Lessons from the lab

• Most real-world OT compromises start with IT (phishing, weak vendor remote access) and pivot inward
• Once inside the OT segment, traditional auth doesn’t apply — anyone who can route to a PLC can talk to it
• Segmentation is the single highest-impact control
• Detection is hard without OT-specific tooling
• Engineering staff understand process; they need security awareness more than security training

Where to go from here

• SANS ICS courses — ICS410 (essentials), ICS515 (active defense), ICS612 (advanced)
• GICSP / GRID certifications — vendor-neutral ICS certs
• Dragos OT-CERT — free advisory and threat intel
• Open-source projects — OpenPLC, ScadaBR, Conpot, GRFICSv2
• India-specific: NCIIPC engagements, CEA cybersecurity guidelines, sectoral CERTs (CERT-In, CERT-Fin)

Reporting template

For your lab report (and real-world equivalent):

1. Executive summary — what was tested, what was found, business impact
2. Methodology — phases executed, tools used, scope adherence
3. Findings by severity (Critical / High / Medium / Low) with each:
   • Description (what’s wrong)
   • Evidence (screenshots, packet captures, logs)
   • Operational impact (what could happen to the process)
   • Cyber impact (what attacker capability this enables)
   • Remediation (specific, actionable; with compensating controls if patch not viable)
4. Detection gaps observed
5. Architecture-level recommendations
6. Tabletop scenarios discussed and outcomes
7. Appendix — full tool output, configuration recommendations

Closing the track

IoT/OT security is a discipline of restraint. The cool techniques from IT pentesting must be used carefully — or not at all — in an environment where systems control physical processes. The most respected OT security practitioners spend more time understanding the engineering than running tools. With the foundations from M1-M5, you are equipped to start building that engineering understanding while staying technically credible.