Modbus Isn’t Theoretical: Why Hands-On ICS Labs Matter

How OT Systems Began Talking to Each Other  

Imagine it’s 1979, and a company called Modicon needs a way for its programmable logic controllers to talk to other equipment on a factory floor. So they invent Modbus, a simple language that lets machines pass notes back and forth over a wire. The idea is straightforward: one device acts as the boss, asking questions like “what’s the temperature in tank three?” or telling another device “turn that valve off now,” and the other devices respond or obey.  

Modicon makes the protocol open and free for anyone to use, which turns out to be a brilliant move because every manufacturer starts building it into their gear, and Modbus quietly becomes the lingua franca of industrial automation. 

Fast forward to today, and Modbus is everywhere you’d never think to look. It’s running inside the HVAC system keeping your office at 72 degrees, the power meter on the side of your building, the sensors monitoring water treatment plants, the motor drives in factories making everything from cars to cereal boxes. It comes in a few flavors depending on how the devices are wired together, including Modbus RTU and ASCII for older serial connections and Modbus TCP for modern Ethernet networks, but the core idea hasn’t really changed in over forty years. Devices still send simple requests to read or write little chunks of data called registers and coils, and the whole system works because it’s almost stubbornly minimal. 

Modbus Limitations 

That minimalism is exactly what’s made Modbus both beloved and problematic. Engineers love it because you can implement it on a coffee budget, debug it with basic tools, and trust that it’ll just work, which is why it’s outlived plenty of fancier successors.  

But it was built in an era when the biggest threat to a factory network was someone tripping over a cable, so it has no encryption, no authentication, and no real way to verify that the device sending commands is actually who it claims to be. 

 Newer protocols like OPC UA and PROFINET have come along to address those gaps, but Modbus refuses to retire. It’s the industrial equivalent of that one old appliance in your grandmother’s kitchen that still runs perfectly, even as everything around it has been replaced three times over. 

Modbus During OT Security Training 

Most practitioners learn Modbus the same way. They see the frame format on a slide. Function code 3 reads holding registers. Function code 16 writes multiple registers. No authentication. No encryption. A packet capture is shown, the instructor moves on, and somewhere a learner writes ‘Modbus is insecure’ in their notes and considers the topic closed. 

That is not learning Modbus. That is learning about Modbus. The difference shows up the first time someone actually sits in front of a live controller with Wireshark running, writes a register, and watches a relay change state. Something shifts. The protocol stops being a diagram and becomes a system with latency, timeouts, retries, exception codes, and behaviors that do not match what the slides said. That shift is the point. 

What Slides Can’t Teach 

Consider what a defender needs to actually do during a Modbus-based intrusion. They need to distinguish between a legitimate HMI poll and an adversary enumerating coils. They need to understand why a sudden burst of function code 6 writes on a process-critical address matters more than a thousand function code 3 reads. They need to know that many PLCs will accept writes from any device on the network segment, including one that spoofed the HMI’s IP. None of this can be taught by a packet diagram. It is learned by watching traffic on a working system, trying to attack it, trying to detect the attack, and understanding why the detection worked or did not. 

The 2015 Ukraine attack is the clearest case study for why this matters. The attackers did not exploit a zero-day in the substation equipment. They used the utility’s own HMI software, logged in with stolen credentials, and issued legitimate commands over the utility’s own protocols. On the wire, almost every packet would have looked normal. The only way to distinguish the attack from routine operations was to understand, at a protocol level, what normal traffic looked like at those specific substations, what times of day writes typically occurred, and which register addresses were safe to write and which would open a breaker. That understanding does not come from a course. It comes from time in the lab. 

Advantages of a Hands-On ICS Lab 

A proper lab environment puts learners in front of real equipment, or a high-fidelity simulation of it, and lets them break things. A small PLC. A simple HMI. A few I/O points wired to lights or motors. Wireshark. A protocol fuzzer. Within a few hours, learners discover things no slide deck can communicate. That the PLC will accept a write to a safety-critical output with no warning. That the HMI’s update rate creates a window in which a crafted write will flip an output and flip back before the operator sees it. That restarting the PLC during an incident might be the worst possible response, because the process state is in the controller, not the engineering workstation. 

These are not edge cases. They are the everyday reality of ICS operation. A defender who has never sat in front of a running PLC will make decisions during an incident based on assumptions that are subtly wrong, and those assumptions will cost time when time is the one thing an incident response team does not have. 

So Why is There a Training Gap? 

Hands-on ICS training is harder to deliver than framework training. It requires hardware, space, instructors who have actually operated control systems, and the patience to let learners make mistakes that would be unacceptable in production. Most training programs, under pressure to certify large numbers of people quickly, have optimized for throughput rather than depth. The result is a workforce that can pass an exam on IEC 62443 but has never watched a PLC fault, never traced a Modbus transaction from HMI to field device, and never had to reason about what happens when the engineering workstation is compromised but the controllers are still running. 

Stuxnet is the reference case that is often invoked and rarely understood. The worm targeted specific Siemens S7-300 and S7-400 controllers, injected code into a specific cyclic interrupt block, and manipulated variable frequency drives in a very specific frequency range while reporting normal values back to the operator. To defend against something like Stuxnet, or even to recognize its traffic signature, a practitioner needs to understand Step 7, organization blocks, and how the engineering workstation talks to the controller. That is a set of skills that requires time on the hardware. 

Getting Time to Understand the Hardware 

The CyberEd.io ICS/OT curriculum is built on this principle. Rather than treating protocols as slideware, courses use hands-on labs and simulation environments that can mirror real industrial equipment, with Modbus, DNP3, and other ICS protocols running over live traffic that learners can capture, analyze, and manipulate. CTF-style exercises drawn from ICS and SCADA scenarios let practitioners test their detection and response skills against attacks modeled on real campaigns, including the legitimate-credential, legitimate-protocol pattern used against the Ukrainian grid. 

Part of the OT skills shortage is self-inflicted, because the training pipeline produces certificate-holders rather than practitioners. Closing it requires getting practitioners as close to the operating environment as possible.  

Learn more about CyberEd.io OT training solutions. 

References: SANS and E-ISAC, Analysis of the Cyber Attack on the Ukrainian Power Grid (2016); Symantec, W32.Stuxnet Dossier (2011); Langner, To Kill a Centrifuge (2013); ICS-CERT advisories on Modbus/TCP exposure.