Simulating Industrial Control System Attacks with Custom Hardware Testbeds

TLDR: Researchers at DEF CON 2024 demonstrated a realistic attack chain against a hydroelectric power plant using a custom-built ICS Firing Range. By combining Siemens PLCs, Raspberry Pi I/O, and a Unity-based simulation, they mapped the path from initial phishing to physical process manipulation. This setup proves that building high-fidelity testbeds is the only way to truly understand the impact of lateral movement in OT environments.

Operational Technology (OT) security often suffers from a disconnect between theoretical risk and physical reality. While IT security focuses on data exfiltration, OT security is about the integrity of physical processes—water levels, turbine rotation, and grid stability. The recent research presented at DEF CON 2024 by the team from NVISO and Verbund highlights exactly why we need to stop treating OT like a static, air-gapped environment. They built a physical, functional testbed to simulate a hydroelectric power plant, proving that the path from a standard phishing email to a catastrophic physical failure is shorter than most operators believe.

The Anatomy of the Attack Chain

The research team focused on a multi-stage attack that mirrors real-world threats targeting critical infrastructure. The attack begins in the IT network, where a phishing email delivers a malicious payload to a workstation. Once the attacker gains an initial foothold, they move laterally to a poorly configured workstation. From there, the goal is to escalate privileges and pivot into the OT network, specifically targeting the Jump Host in the Control Technology (DMZ).

The technical brilliance of this research lies in how they bridged the virtual and physical worlds. The testbed uses Siemens S7-A8000 PLCs as the "brains" of the operation. These PLCs are connected to a network of Raspberry Pis that act as remote I/O, driving the physical components of the model—the weirs and turbine shutters.

When the attacker reaches the Jump Host, they don't just look for passwords; they target the project files used to program the PLCs. By modifying these files and re-uploading them to the PLCs, the attacker can manipulate the physical process. In the demo, this resulted in an "immense flood" simulation, where the water levels were forced to dangerous heights, demonstrating a complete loss of control over the physical environment.

Technical Deep Dive: Bridging the Gap

For a pentester, the most interesting part of this setup is the communication protocol stack. The team utilized Modbus to handle the communication between the PLCs and the Raspberry Pi I/O. Because Modbus is inherently insecure and lacks authentication, it is a goldmine for anyone who has already breached the internal network.

The team also used the Havoc Framework to manage the C2 infrastructure. During the engagement, they performed the following steps:

# Initial enumeration of the network
nmap -sS -p- <target_ip>

# Analyzing traffic to identify PLC communication
tshark -r capture.pcap -Y "modbus"

# Modifying project files to alter physical setpoints
# This involves interacting with the Siemens Toolbox
# to re-upload logic to the S7-A8000

The use of Wireshark and TShark for forensic analysis is standard, but the team noted a critical lesson: not every OT operator is comfortable with TShark. They had to switch to Wireshark for the training modules because the GUI is significantly more accessible for teams that are not full-time security researchers. If you are running a red team engagement in an OT environment, don't assume the local engineers have the same tool proficiency as your team.

Real-World Applicability

If you are conducting a penetration test on a utility or manufacturing facility, you will likely encounter this exact architecture. The "IT-to-OT" pivot is the most common vector. You aren't looking for a SQL injection in a public-facing web app; you are looking for a misconfigured Jump Host or a domain-joined workstation that has a direct line of sight to the OT management network.

The impact of this research is clear: once an attacker has access to the PLC project files, the game is over. You can change the logic that governs safety limits, effectively disabling the physical safeguards that prevent equipment damage. During an engagement, focus your efforts on identifying where these project files are stored and who has write access to them. If you can modify the logic, you can control the process.

Defensive Considerations

Defenders must prioritize the segmentation of the OT network. If your Jump Host is domain-joined and shares credentials with the IT network, you have already failed. Implement strict access controls and ensure that PLC project files are stored in a read-only repository with strict version control. Monitoring for unauthorized changes to PLC logic is not just a "best practice"—it is a necessity for preventing physical damage.

This research serves as a wake-up call for anyone who thinks their OT environment is secure because it is "old" or "isolated." The tools to simulate these attacks are accessible, and the techniques are well-documented. If you aren't testing your OT defenses with the same rigor you apply to your web applications, you are leaving the door wide open for someone who will. Start by mapping your own network, identifying the critical PLCs, and asking yourself what happens if someone else decides to change the logic.