From Relay Logic to Software-Defined Mayhem: Why Structured Text Is OT’s Biggest Security Blind Spot (And How to Fix It) + Video

Listen to this Post

Featured Image

Introduction:

Programmable Logic Controllers (PLCs) have been the backbone of industrial automation for decades, traditionally programmed using graphical languages like Ladder Logic that mimic electrical relay circuits. However, the industry’s shift toward IEC 61131-3 Structured Text (ST)—a high-level, Pascal-like language—has transformed PLCs from simple relay replacements into sophisticated software-defined controllers. This evolution brings immense power and flexibility, but as Zakhar Bernhardt’s upcoming Labshock Masterclass makes clear, it also introduces a new attack surface where malicious logic can be hidden in plain sight, and where “bad ST nobody can read” becomes a critical operational and security risk.

Learning Objectives:

  • Understand the fundamental syntax and control structures of IEC 61131-3 Structured Text, including IF, FOR, and CASE statements.
  • Learn how to read plant state from PLC memory, write conditional logic, and deploy code to a runtime environment with real HMI feedback.
  • Identify the unique security risks introduced by Structured Text, including obfuscated logic, hidden behaviors, and the challenges of detecting malicious modifications.

You Should Know:

  1. Structured Text Fundamentals: From Relay Logic to Software

Structured Text (ST) is a textual programming language defined by the IEC 61131-3 standard. Unlike Ladder Logic, which visualizes control flow as electrical circuits, ST resembles modern programming languages like C, Java, or Python. This makes it far more powerful for complex mathematical operations, data handling, and algorithmic control—but also far more opaque to operators and security analysts trained on relay logic.

Step‑by‑step guide to reading plant state and writing logic:

Step 1: Declare variables and tags. In ST, you first define variables with specific data types (BOOL, INT, REAL, etc.) and optionally assign them to physical I/O addresses or memory locations.

PROGRAM MainProgram
VAR
TankLevel : REAL; ( Analog input from level sensor )
PumpSpeed : INT; ( Output to variable frequency drive )
HighLevelAlarm : BOOL; ( Internal flag )
CycleCount : INT := 0; ( Counter with initial value )
END_VAR

Step 2: Read plant state from PLC memory. Use direct assignment or input mapping to capture real-world process data.

TankLevel := %IW0; ( Read from input word 0 - the level transmitter )
PumpSpeed := %QW1; ( Read current pump speed from output word 1 )

Step 3: Write logic with IF, FOR, and CASE. Implement decision-making and iterative control.

( IF statement: conditional action based on tank level )
IF TankLevel > 75.0 THEN
HighLevelAlarm := TRUE;
PumpSpeed := 0; ( Stop pump to prevent overflow )
ELSIF TankLevel < 20.0 THEN
HighLevelAlarm := FALSE;
PumpSpeed := 80; ( Increase pump speed to draw down level )
ELSE
PumpSpeed := 50; ( Maintain moderate speed )
END_IF;

( FOR loop: iterate through a sequence, e.g., checking multiple sensors )
FOR i := 1 TO 10 BY 1 DO
SensorArray[bash] := %IW[bash]; ( Read 10 analog inputs )
END_FOR;

( CASE statement: multi-branch selection based on an integer value )
CASE ModeSelector OF
1: PumpSpeed := 30; ( Low speed mode )
2: PumpSpeed := 60; ( Medium speed mode )
3: PumpSpeed := 100; ( High speed mode )
ELSE
PumpSpeed := 0; ( Default: stop )
END_CASE;

Step 4: Move setpoints with math. ST excels at calculations that would be cumbersome in Ladder Logic.

Setpoint := (TankLevel  0.75) + (FlowRate  2.5); ( PID-like calculation )
PumpSpeed := REAL_TO_INT(Setpoint / MaxSpeed  100);

Step 5: Bind tags to the real process. Ensure your variables are mapped to physical I/O or internal memory tags that the HMI can read.

%QW1 := PumpSpeed; ( Write speed to output )
%MX0.0 := HighLevelAlarm; ( Set alarm bit for HMI display )

Step 6: Deploy to runtime and watch output move on HMI. Compile the code, download it to the PLC, and monitor the HMI to see the process respond in real time.

  1. The Security Blind Spot: Why Structured Text Is a Hacker’s Playground

Modern PLCs programmed in IEC 61131-3 ST were not designed with security as a core priority. This legacy design, combined with the expressive power of ST, creates a perfect storm for attackers. ST programs are prone to subtle logic vulnerabilities that are difficult to detect through traditional static analysis or fuzzing. As Bernhardt warns, “Bad ST nobody can read is risk for operations. Hidden logic is risk for defense.”

Step‑by‑step guide to identifying and mitigating ST-based attacks:

Step 1: Recognize common attack vectors. Attackers can upload malicious code to a PLC, manipulate the currently running logic, or even upload new firmware entirely. Because ST is textual, malicious code can be obfuscated more easily than graphical ladder diagrams.

Step 2: Look for obfuscated logic. In ST, attackers can hide malicious behavior using:
– Complex nested IF statements that are difficult to follow.
– Unnecessary mathematical operations that mask the true intent.
– Unused or dead code that contains trigger mechanisms.
– Manipulation of timer and comparison functions to introduce subtle delays or overrides.

Example of suspicious ST code:

( Seemingly innocent temperature control )
IF Temperature > 100 THEN
CoolantValve := OPEN;
ELSE
CoolantValve := CLOSE;
END_IF;

( Hidden logic: if a specific condition is met, override safety )
IF (Temperature > 95) AND (SecretCounter > 1000) THEN
SafetyBypass := TRUE; ( This could disable emergency shutdown )
END_IF;

Step 3: Implement secure coding practices. The Top 20 Secure PLC Coding Practices provide guidelines for creating more resilient control logic. Key practices include:
– Use cryptographic hashes (SHA-2, SHA-3) instead of weak CRCs or checksums for firmware and logic verification.
– Restrict who can program or modify PLC logic through strict access controls and role-based permissions.
– Isolate control networks from business networks using firewalls and DMZs.
– Never connect programming software to any network other than the intended device network.

Step 4: Perform regular code reviews and audits. Treat PLC code like any other software—review it for logic errors, backdoors, and compliance with security standards. Use tools like IronPLC, which provides IEC 61131-3 ST language support for VS Code with real-time error checking and syntax highlighting.

Step 5: Monitor for unauthorized changes. Implement change management and logging. Any transfer of control logic over the network should be treated as potentially malicious, especially in environments where logic updates are rare.

3. Live Training: The Thunderwatch Zone

“You do not learn control from PDF. You learn it by writing logic and watching machine react.” This philosophy is at the heart of the Labshock Masterclass series. Labshock is a practical, environment-driven platform for learning and practicing OT and ICS security using real industrial components, real protocols, and real telemetry.

Step‑by‑step guide to getting hands-on with Labshock:

Step 1: Access the Labshock environment. The platform is available as an open-source project on GitHub (github.com/zakharb/labshock) and can be set up locally or accessed through guided learning paths.

Step 2: Start with the pre-built labs. The easiest way to begin is by taking the 10 pre-built labs. The first three labs will get you comfortable with Kali Linux and basic OT security concepts.

Step 3: Analyze industrial protocols. Use tools like Wireshark to capture and analyze Modbus/TCP, OPC UA, and Profibus traffic.

Step 4: Simulate cyber attacks. Practice offensive techniques such as man-in-the-middle attacks, logic injection, and denial-of-service in a safe, virtualized setting.

Step 5: Test defensive strategies. Implement intrusion detection systems (IDS), firewalls, and secure coding practices to defend against the attacks you’ve simulated.

  1. Linux and Windows Tools for OT Security Analysis

Linux Commands for Network Analysis:

 Capture Modbus traffic on interface eth0
sudo tcpdump -i eth0 -1 port 502 -w modbus_traffic.pcap

Analyze PCAP with Wireshark (GUI)
wireshark modbus_traffic.pcap

Scan for open PLC ports (Modbus 502, S7 102, etc.)
nmap -p 502,102,44818,2222 192.168.1.0/24

Check for vulnerable services using Nessus or OpenVAS
openvas-start

Windows Tools:

  • CODESYS – A popular IDE for PLC programming that supports ST and allows online monitoring.
  • TIA Portal – Siemens’ engineering framework for programming and diagnosing S7 PLCs.
  • Modbus Poll / ModScan – Simple tools for reading and writing Modbus registers.
  • Wireshark for Windows – Network protocol analyzer with full OT protocol support.
  1. API Security, Cloud Hardening, and the Future of OT

As OT environments become increasingly connected to IT networks and cloud platforms, the attack surface expands dramatically. APIs are now used to expose PLC data to enterprise systems, and cloud-based SCADA solutions are becoming more common.

Step‑by‑step guide to hardening OT-IT integration:

Step 1: Secure all APIs. Use strong authentication (OAuth 2.0, API keys), encrypt data in transit (TLS 1.3), and implement rate limiting to prevent abuse.

Step 2: Harden cloud connections. Use VPNs or dedicated secure tunnels (e.g., AWS Direct Connect, Azure ExpressRoute) to connect on-premises OT networks to cloud services. Never expose PLCs directly to the internet.

Step 3: Implement network segmentation. Place control and safety system networks behind firewalls and isolate them from business networks. Use DMZs to host any externally accessible services.

Step 4: Apply least privilege principles. Restrict access to programming functions, enforce strong authentication, and maintain firmware integrity through signed updates.

Step 5: Continuously monitor and audit. Use SIEM tools to collect and analyze logs from both IT and OT systems. Implement anomaly detection to spot unusual behavior.

What Undercode Say:

  • Structured Text is a double-edged sword. Its power and flexibility make it invaluable for complex control logic, but its textual nature makes it far easier to hide malicious code than in graphical languages like Ladder Logic. Security teams must adapt their monitoring and review processes accordingly.
  • Hands-on training is non-1egotiable. Theory alone cannot prepare you for the realities of OT security. Platforms like Labshock that provide real hardware, real protocols, and real-time feedback are essential for building practical skills.
  • The threat is real and growing. With the increasing integration of OT and IT, the number of potential attack vectors is exploding. Attackers are already exploiting logic-level vulnerabilities in PLCs. Defenders must be proactive, not reactive.

The shift from relay logic to software-defined control is irreversible. As Bernhardt’s masterclass demonstrates, the future of OT security lies in understanding the code that runs our critical infrastructure—and in being able to write clean, readable, and secure Structured Text. The skills you develop today will determine whether you’re prepared for the “AI hell” that’s coming—or whether you become another statistic in the growing list of industrial cyber incidents.

Prediction:

  • +1 The demand for OT security professionals with hands-on PLC programming skills will skyrocket over the next 3–5 years, creating significant career opportunities for those who invest in practical training now.
  • -1 As AI-assisted coding tools become more prevalent, the risk of inadvertently introducing or failing to detect malicious logic in PLC code will increase, especially if proper code review and auditing practices are not adopted.
  • +1 Open-source platforms like Labshock will democratize OT security training, making it accessible to a wider audience and accelerating the development of a skilled workforce.
  • -1 The convergence of IT and OT will continue to expose critical infrastructure to sophisticated cyber attacks, with logic-level vulnerabilities in PLCs becoming a primary target for state-sponsored actors and cybercriminals alike.
  • +1 The development of specialized fuzzing tools for IEC 61131-3 ST and the application of LLMs to PLC code security will provide new capabilities for identifying and mitigating vulnerabilities before they can be exploited.

▶️ Related Video (68% Match):

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: Zakharb Otsecurity – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky