Simulating Cyberattacks on PLCs: Safe Testing Techniques

Critical infrastructure owners, CISOs, IT Directors, network engineers, and operators are increasingly called to validate the resilience of programmable logic controllers (PLCs) and associated industrial control systems (ICS) to cyber threats. Given that PLCs form the backbone of automation in sectors like manufacturing, utilities, and energy, ensuring their secure and continuous operation is not just a technical concern—it is a matter of national and economic security.

Historical Overview: PLCs and Their Security Blind Spot

PLCs originated in the 1960s, transforming the nature of automation through digitization and flexibility. Early PLCs such as the Modicon 084 were designed to replace relay-based logic, focusing exclusively on functional reliability. Security, at this stage, was not in the architectural lexicon. As the decades progressed, network connectivity was layered atop legacy PLC designs with protocols such as Modbus (1979), DNP3 (1993), and more recently Ethernet/IP and PROFINET. The heritage of "security by obscurity,"—nonexistent in modern threat models—left a vast attack surface now exposed as industrial networking merged with enterprise IT and, by extension, the Internet.

Risks of Direct Cyberattack Testing on Industrial PLCs

While red-teaming and penetration tests are standard in enterprise IT, industrial environments introduce unique hazards. An improperly scoped test can trip safety interlocks, halt production, or even risk equipment integrity and human safety. Unlike virtualized IT assets, a PLC's physical output can have kinetic ramifications. Permanent device damage from firmware or protocol fuzzing, inadvertent process activation, or errant ladder logic injections pose significant risks.

Historically, real-world examples such as Stuxnet (2010) have underscored the havoc possible when sophisticated attackers subvert PLCs intentionally. This compels defenders to rigorously simulate attacks—but do so in a manner that respects the delicate interplay of safety, uptime, and asset preservation.

Safe Approaches to PLC Security Testing

1. Testbed Replication with Digital Twins

The most rigorous (and safest) testing approach employs testbeds—replicas of your live environment, built using either spare hardware or digital twins. Digital twins utilize simulation platforms such as Factory I/O, Siemens SIMIT, or emulation engines like OpenPLC, to virtually deploy PLC logic and connected components. While these platforms may not represent exotic device firmware or customized fieldbus variants, they enable representative attack scenarios: protocol fuzzing, brute force, command injection, and replay attacks without risking production assets.

2. Network Segmentation and Controlled Sandboxing

For organizations unable to fully replicate production environments, leveraging segmented network zones with robust access control lists (ACLs) enables testing on live PLCs within a tightly controlled sandbox. VLANs, firewalls, and data diodes can shield the test environment. Logical separation should be reinforced with physical airgaps when feasible, ensuring that test traffic cannot traverse into running operations. Here, leveraging out-of-band monitoring (e.g., a SPAN port feeding a protocol analyzer) allows observation of attack effects without operational interference.

3. Protocol-Level Simulation and Fuzzing

Modern ICS security research uses protocol-aware tools—such as Scapy (for crafting custom packets), Boofuzz, and frameworks like Defensics—that allow for precise simulation of malformed or malicious protocol interactions with PLCs. Running these tools against simulated or isolated physical PLCs allows the organization to assess how well the device deals with unexpected inputs. Historical vulnerabilities (such as buffer overflows in Modbus/TCP or SCADA-specific denial-of-service vectors) often emerge during such tests.

4. Logic Injection and Abuse Cases

Beyond network-layer exploits, adversaries often seek to modify the PLC’s user logic to illicit ends (e.g., logic bomb insertion, subtle process alteration). Safe simulation typically involves offline code review, use of version-controlled ladder/structured text logic, and manual insertion of malicious "test rung" scenarios into the sandbox or testbed. Assessing the efficacy of change management, detection, and recovery controls forms a keystone of resilient PLC environments.

IT/OT Collaboration: Key to Safe Security Assessments

A persistent historical division between IT security teams and OT engineering has often led to misunderstanding and resistance regarding testing. Success requires tightly integrated planning:

• Change management processes must be deeply respected.

• Asset owners should be directly involved in scoping, scheduling, and monitoring every test event.

• Incident response playbooks should be updated to include learnings/measures from simulated attacks.

Effective IT/OT collaboration is not just operational—it’s cultural. Automation and safety engineers bring irreplaceable device/process knowledge; security teams contribute threat intelligence, adversarial emulation tactics, and forensic rigor.

Network Architecture Considerations for Test-Ready Environments

Network architectures in ICS/OT domains are dictated by the Purdue Model (developed in the 1990s), which prescribes multi-layered segmentation from business networks down to device-level controllers. This model, when strictly implemented, enables test zones to be carved out at the Level 1–2 device/controller and Level 3 automation layers, insulated from corporate IT and safety-critical field connections.

Annotation: Implementing unidirectional gateways (data diodes), robust DMZs, and micro-segmentation ensures any injected test or “attack” traffic cannot escape the test environment. Firewall rule sets should be reviewed and provisioned specifically for the test period, with monitoring to revert to a secure baseline post-testing.

Conclusion: Building a Testing Program that Accelerates Security without Risk

Simulating cyberattacks on PLCs is a necessity for any defender of critical systems—but the techniques employed must be mature, methodical, and mindful of the engineering realities of industrial automation. Safe testing is enabled by rigorous planning, the embrace of modern testbed technologies, and uncompromising IT/OT partnership.

The lesson from recent decades—from early PLCs, the advent of Ethernet networking, to the catastrophic consequences of real-world ICS intrusions—is undeniable: security validation must be continuous, measured, and deeply integrated into operational practice. The organizations that build repeatable, safe, and technically sound test programs will be those most capable of defending their industrial future.

Further Reading

• ISA/IEC 62443 Series: Industrial Automation & Control Systems Security Standards

• NIST SP 800-82: Guide to Industrial Control Systems (ICS) Security

• SANS ICS Whitepapers—Practical Approaches to OT Network Security Monitoring