Programmable Logic Controllers sit at the heart of modern industrial infrastructure. From water treatment facilities to automobile assembly lines to nuclear power plants, PLCs are the silent workhorses keeping physical processes running. Yet despite their critical role, they were engineered for reliability and determinism, not security. That oversight has turned them into some of the most consequential attack surfaces in the world.
This is Part 1 of Redfox Cybersecurity's PLC Hacking series. In this installment, we walk through the physical setup, network configuration, and ladder logic programming of a Koyo CLICK C0-10DRE-D PLC. This foundation is essential before we move on to protocol-level attacks and memory manipulation in Part 2.
If you are new to ICS/OT security and want to build a structured skill set around this discipline, the Redfox Cybersecurity Academy offers courses specifically designed to take you from foundational networking knowledge into advanced industrial control system exploitation.
The Stuxnet worm, discovered in 2010, remains the most cited example of a PLC-targeted cyberattack. It specifically targeted Siemens S7-315 and S7-417 PLCs controlling centrifuges in Iran's uranium enrichment program. Stuxnet manipulated output frequencies while reporting nominal values back to operators, causing physical destruction while evading detection.
That attack proved a critical point: PLCs can be compromised with surgical precision, and the damage is not limited to data. It extends into the physical world.
More recent incidents, including attacks on water utility HMIs in the United States and ransomware campaigns that pivoted from IT into OT networks, confirm that this threat vector is growing. Security practitioners need hands-on exposure to these environments, not just theoretical knowledge.
If your organization operates industrial systems and wants a professional assessment of its OT security posture, the team at Redfox Cybersecurity provides specialized ICS penetration testing and advisory services.
Before touching any software, you need the right hardware and a controlled network environment. Using real PLCs in a lab setting is far more valuable than simulation alone because protocol behavior, timing characteristics, and firmware quirks only reveal themselves on physical hardware.
Hardware list:
The Koyo CLICK series is an excellent research target. It supports Modbus TCP natively, requires no proprietary licensing for its programming software, and is inexpensive relative to Siemens or Allen-Bradley hardware. It also lacks authentication on its communication interfaces by default, which makes it ideal for demonstrating the weaknesses inherent to legacy OT protocols.
Proper network segmentation mirrors what you would find in a real industrial environment following the Purdue Model. The Purdue Model divides OT networks into hierarchical zones, separating field devices (Level 0-1) from supervisory systems (Level 2) and enterprise IT (Level 3 and above).
For this lab, assign static IPs on a dedicated 10.0.1.0/24 subnet:
DeviceIP AddressSwitch10.0.1.1PLC10.0.1.10Windows PC10.0.1.20Kali Linux10.0.1.30
Set your Kali Linux VM's network adapter to Bridged Mode in VirtualBox so it receives a real IP on the same physical network segment as the PLC. This is important because many PLC protocols operate at Layer 2 and may not route cleanly through NAT.
Verify connectivity from Kali before proceeding:
ping -c 4 10.0.1.10
[cta]
If the PLC does not respond, check the subnet configuration using the CLICK programming software's Edit network settings dialog. Confirm the PLC's IP matches your target subnet before continuing.
You can also use Nmap to confirm the PLC is reachable and fingerprint its open ports:
nmap -sS -p 80,502,44818 -sV 10.0.1.10
[cta]
Port 502 is Modbus TCP. Port 44818 is EtherNet/IP. Both are common on CLICK-series PLCs and will be the focus of Part 2. Seeing them open here confirms the attack surface we will exploit later.
Download and install the free CLICK programming software on your Windows machine. On launch, select "Connect to PLC" and choose the correct Ethernet adapter. The software will attempt to discover the PLC on the local network.
Once connected, select "Read the project from the PLC" to pull any existing ladder logic currently loaded onto the device. On a fresh PLC this will return an empty project, which is what we want for this exercise.
This read operation happens over a proprietary protocol layered on top of TCP. In Part 2, we will capture and analyze this traffic using Wireshark to understand the packet structure and determine whether commands can be replayed or injected without authentication.
For teams working in production environments who want expert guidance on identifying exactly this type of exposure, Redfox Cybersecurity's OT security services include full protocol analysis and attack path mapping.
Ladder logic is the dominant programming language for PLCs. It was designed to resemble relay logic diagrams so that electricians already familiar with control panel wiring could read and write programs without learning traditional code. Understanding it is non-negotiable for any ICS security practitioner because it is what you will read when you pull a project off a live PLC.
A ladder diagram consists of two vertical rails representing power, connected by horizontal rungs. Each rung represents a logical statement. Contacts on a rung represent inputs (sensors, buttons, switches), and coils at the end of rungs represent outputs (actuators, lights, relays).
In the CLICK software, the instruction list panel on the right side contains all available function blocks. To create a basic input/output pair:
Repeat this across rungs 2 through 4, mapping X002 to Y002, X003 to Y003, and X004 to Y004. Each rung creates a direct logical relationship: when input X00N is energized (24V DC applied to that terminal), output Y00N activates.
From a security standpoint, this mapping matters. When an attacker gains access to the PLC's communication interface, they can force-set output coils regardless of what the physical inputs are doing. The PLC will activate Y001 even if X001 has no voltage applied, because the coil state is being written directly into the data table in memory.
All CLICK ladder programs must terminate with an END instruction, placed on the final rung. Without it, the program will either throw a syntax error or, on some PLC models, exhibit undefined scan cycle behavior.
From the Instruction List panel, navigate to Program Control and drag the END block to the NOP placeholder at the end of rung 5.
Before writing the project to the PLC, run the syntax checker under the Program tab. A clean syntax check will show zero errors in the output window. Any unresolved addresses or missing END instructions will be flagged here.
To write the project:
The PLC will now execute the ladder program continuously in a scan cycle, reading inputs, evaluating logic, and updating outputs on each pass.
With the PLC in RUN mode and the ladder program active, apply 24V DC to input terminals X1 through X4 individually. Each input should cause its corresponding output indicator LED (Y1 through Y4) to illuminate on the PLC's faceplate.
This confirms the program is executing correctly and the I/O mapping is functional. At this point, the PLC is behaving exactly as it would in a production environment: responding deterministically to physical inputs and producing physical outputs.
What it is not doing is authenticating any of the network commands it will receive. That is where Part 2 begins.
If you want to go deeper into industrial protocol security, memory manipulation, and coil forcing before Part 2 drops, the Redfox Cybersecurity Academy has dedicated ICS/SCADA modules that cover Modbus exploitation, DNP3 analysis, and OT network reconnaissance in structured, hands-on course formats.
Even at this setup stage, the lab reveals several structural weaknesses that are consistent across most deployed PLCs in the field:
These are not theoretical risks. They are the exact techniques that have been used in documented ICS intrusions. The goal of this series is to demonstrate them in a controlled environment so defenders understand what they are up against.
For organizations looking to close these gaps through professional testing and remediation, Redfox Cybersecurity provides tailored ICS vulnerability assessments that address both network-level and protocol-level exposure.
Setting up a PLC lab is the essential first step in understanding ICS security from both the offensive and defensive perspectives. The Koyo CLICK C0-10DRE-D provides an accessible, affordable, and realistic environment for exploring the protocols and weaknesses that affect real industrial deployments.
In this part of the series, we covered the physical and network setup, the basics of ladder logic programming, and the structural security weaknesses that are already visible before any active exploitation begins. The attack surface is wide, and it is almost entirely unauthenticated.
In Part 2, we will move from observation to interaction: capturing Modbus TCP traffic, crafting custom Modbus packets with tools like mbtget and Python's pymodbus library, forcing coil states remotely, and exploring EtherNet/IP enumeration with cpppo.
If you are serious about building expertise in ICS and OT security, start with the foundational courses at Redfox Cybersecurity Academy and pair that learning with real hardware practice. The combination of structured curriculum and hands-on lab work is what separates practitioners from readers.