Date
March 9, 2026
Author
Karan Patel
,
CEO

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.

Why PLC Security Research Matters

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.

Lab Environment and Hardware Requirements

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:

  • Koyo CLICK C0-10DRE-D PLC with a 24V 2A DC power supply
  • Windows PC or VM with an Ethernet port (for CLICK programming software)
  • Kali Linux VM (attack machine, configured in VirtualBox bridged mode)
  • TP-LINK managed smart switch
  • Ethernet cables and electrical wiring

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.

Network Configuration and Segmentation

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.

Connecting to the PLC via CLICK Software

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.

Writing Ladder Logic: A Primer for Security Researchers

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).

Configuring Inputs and Outputs

In the CLICK software, the instruction list panel on the right side contains all available function blocks. To create a basic input/output pair:

  1. Drag a Normally Open (NO) Contact to rung 1
  2. Assign input address X001 (physical input terminal 1 on the PLC)
  3. Drag an Out coil to the end of rung 1
  4. Assign output address Y001 (physical output terminal 1 on the PLC)

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.

Adding the END Instruction

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.

Syntax Checking and Writing to the PLC

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:

  1. Set the PLC mode to STOP (required before any write operation)
  2. Select "Write Project into PLC" from the PLC menu
  3. Confirm the transfer dialog and wait for the "Transfer completed" confirmation
  4. Switch the PLC mode back to RUN

The PLC will now execute the ladder program continuously in a scan cycle, reading inputs, evaluating logic, and updating outputs on each pass.

Verifying Physical Operation

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.

Understanding the Attack Surface Before the Attack

Even at this setup stage, the lab reveals several structural weaknesses that are consistent across most deployed PLCs in the field:

  • No authentication on the programming interface. The CLICK software connected to the PLC without credentials. Any machine on the same network segment can read or write projects to this PLC using the same software, or by crafting raw packets that mimic the software's protocol.
  • No encryption on communication. All project read/write traffic between the Windows PC and the PLC is transmitted in plaintext. Wireshark on the Kali machine will capture all of it.
  • Mode changes require no authorization. Switching the PLC from STOP to RUN is a single unauthenticated command. An attacker who can reach the PLC on the network can stop its execution, replace its program, and restart it, all without credentials.
  • Physical outputs can be forced remotely. Modbus TCP, which is running on port 502, allows direct coil writes. An attacker can energize or de-energize any output coil by sending a Function Code 05 (Write Single Coil) command, bypassing the ladder logic entirely.

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.

Key Takeaways

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.

Copy Code