An LLM-Driven Fuzzing Framework for Detecting Logic Instruction Bugs in PLCs

An LLM-Driven Fuzzing Framework for Detecting Logic Instruction Bugs in PLCs

Speakers: Jiaxing Cheng

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=VhJMMNgZft8

Overview

This talk presents LogicFuzz, an LLM-driven fuzzing framework designed to detect logic instruction bugs in Programmable Logic Controllers (PLCs) -- the core control devices in industrial control systems (ICS). Logic instructions are vendor-developed library routines in PLC firmware that engineers invoke in control programs. Bugs in these routines can silently break many control programs, leading to physical hazards in critical infrastructure.

LogicFuzz addresses three key challenges: generating valid PLC test programs that invoke target instructions, efficiently mutating the large input parameter space, and detecting anomalies beyond simple crashes. The framework was evaluated on six PLC models from Siemens, Rockwell, and WAGO (CodeSys) covering over 300 logic instructions, discovering 19 logic instruction bugs. The researchers demonstrated real-world exploitability by showing how an attacker can deliver an instruction payload via an industrial communication protocol, crash a PLC, and halt a slide rail in motion.

Background

▶ Watch: ICS attacks: Stuxnet, Triton, Industroyer and the role of PLCs (0:00)

Industrial control systems underpin critical infrastructure including oil and gas, smart grids, rail transportation, and manufacturing. The historical precedent for PLC-targeting attacks is well-established: Stuxnet damaged nuclear facilities by compromising PLCs, Triton risked explosions by attacking safety controllers, and Industroyer triggered outages by manipulating power system devices. These incidents demonstrate that cyber-physical attacks can escalate from data issues to real physical hazards.

In the Purdue model, PLCs sit close to the physical process, operating in a continuous control loop: sensors send signals, the PLC computes control values, and actuators execute actions. PLCs execute control programs using logic instructions -- vendor-developed library routines encapsulated in firmware. These instructions read input parameters from PLC memory, execute the vendor routine, and write results back to the program data or output image for actuator execution.

Logic instruction bugs are defects in the instruction library where, under specific inputs and runtime contexts, the procedure produces output that deviates from specification. Two common trigger patterns exist: crafted parameter values that hit edge cases (e.g., overlapping memory ranges in a copy routine) and specific program contexts where invocation order matters (e.g., specific call sequences between instructions causing failures or PLC crashes).

Key Findings

▶ Watch: Controllable and resettable test structure for PLC fuzzing (4:00)

19 logic instruction bugs discovered across six PLC models from three major vendors (Siemens, Rockwell, WAGO/CodeSys).

Real-world exploitability demonstrated: An attacker can deliver an instruction payload via industrial communication protocols, crash the PLC, and halt physical equipment (slide rail) in motion. Compared to control logic injection, exploiting logic instruction bugs is significantly easier.

Controllable and resettable test structure: Using the vendor-provided enable signal parameter with rising/falling edge logic enables stable, repeatable fuzzing that aligns with PLC scan cycles and avoids state leakage across runs.

LLM-generated test programs outperform baselines: LogicFuzz outperforms AgentForPLC and PromptFuzz in test program generation because it generates instruction-tailored programs with strong validation and repair loops.

Coverage-guided mutation using multi-armed bandit: Online learning treats each parameter as an arm, rewarding parameters that increase coverage or produce suspicious logs, enabling efficient exploration of large parameter spaces.

Comprehensive anomaly detection beyond crashes: Monitoring three sources -- runtime logs, PLC status LEDs, and active probes for communication services (Modbus) -- enables detection of hangs, watchdog timeouts, and other abnormal behaviors that crash-only detection would miss.

Technical Deep Dive

▶ Watch: LLM-based test program generation with four-level validation (8:00)

LogicFuzz operates in three stages:

Stage 1 -- Static Analysis and Semantic Dependency Graph: Given a target instruction, the framework constructs a Semantic Dependency Graph (SDG) from vendor documentation and a CWE list. The SDG captures usage relations between instructions and potential bug-triggering patterns. An LLM infers parameter usage constraints, and a CWE-informed analysis derives candidate triggering programs.

Stage 2 -- Seed Program Generation: An iterative loop of SDG mutation, LLM generation, and validation/repair produces qualified test programs. The key innovation is the controllable and resettable structure: when the enable signal (EN) rises, the instruction executes exactly once; when EN falls and reset is true, internal state is cleared. This prevents state leakage between fuzzing iterations, which is critical because many PLC instructions are stateful (managing handles, buffers, timers).

Validation occurs at four levels:

1. Syntax validation
2. Semantic validation
3. Baseline validation (skeleton execution)
4. Functionality validation: normal invocation with valid parameters, repeated execution for latent leaks/timeouts, and falling-edge reset validation

Only programs passing all four levels become fuzzing seeds.

Stage 3 -- Logic Instruction Fuzzing: Two-step mutation strategy:

• Coverage-guided mutation scheduling using multi-armed bandit: Each parameter is an arm; mutations that increase coverage or produce suspicious logs receive rewards. The algorithm balances exploitation (prioritizing rewarding parameters) with exploration (still mutating others).
• Bug-oriented mutation using LLM: Beyond random mutations, the LLM generates parameter values with exploit-oriented semantics based on extracted bug clues, combining breadth (random) with depth (targeted) coverage.

Comprehensive monitoring oracle using three sources:

• Runtime logs from PLC and engineering tools
• PLC status LEDs with diagnostic meanings
• Active probes for communication services (Modbus)

This multi-source monitoring detects crashes, hangs, watchdog timeouts, and communication failures.

Demo / Proof of Concept

▶ Watch: Multi-armed bandit coverage-guided mutation and anomaly detection (10:00)

The researchers demonstrated real-world exploitability using a slide rail control system. An attacker delivers an instruction payload via an industrial communication protocol that exploits a discovered logic instruction bug, causing the PLC to crash. With the PLC crashed, the slide rail remains in motion without control -- a physically dangerous condition.

The evaluation covered over 300 logic instructions across six PLC models from Siemens, Rockwell, and WAGO (CodeSys-based), discovering 19 logic instruction bugs. Compared to existing systems (ICS-Quartz, ICS-Fuzzer), LogicFuzz is more general (not limited to CodeSys-based PLCs) while maintaining practical efficiency.

Defensive Implications

▶ Watch: Real-world exploit: crashing PLC to halt slide rail in motion (11:30)

This research exposes a significant and underexplored attack surface in industrial control systems. Logic instruction bugs in PLC firmware affect all control programs that invoke the vulnerable instructions, making them a high-leverage target for attackers.

For ICS asset owners: The discovery of 19 bugs across major vendors (Siemens, Rockwell, WAGO) demonstrates that logic instruction libraries should not be assumed correct. Organizations should work with vendors to obtain patches and consider adding runtime monitoring for anomalous PLC behavior (watchdog timeouts, communication failures, unexpected state changes).

For PLC vendors: The LogicFuzz framework provides a systematic testing methodology that vendors should integrate into their firmware development and validation processes. The controllable/resettable test structure is a reusable pattern for PLC instruction testing.

For ICS security teams: The finding that exploiting logic instruction bugs is easier than control logic injection is particularly concerning. Traditional ICS security focuses on preventing unauthorized program downloads, but logic instruction bugs can be triggered via industrial communication protocols without modifying the control program itself.

Limitations acknowledged: The framework requires privileged runtime visibility (debug interfaces), cannot work on locked-down devices, has noisy oracles requiring manual triage, depends on documentation quality and LLM capability, and faces scaling costs when adding PLC families from different vendors.

Key Takeaways

• Logic instruction bugs in PLC firmware are a high-leverage attack surface that can silently affect all control programs invoking the vulnerable instruction
• LogicFuzz discovered 19 bugs across six PLC models from Siemens, Rockwell, and WAGO using LLM-driven test program generation and coverage-guided fuzzing
• Exploiting logic instruction bugs is easier than control logic injection and can be delivered via industrial communication protocols
• The controllable/resettable test structure using enable signal rising/falling edges enables stable, repeatable PLC fuzzing
• Multi-armed bandit coverage-guided mutation efficiently explores large parameter spaces
• Comprehensive monitoring (logs, LEDs, active probes) detects anomalies beyond crashes including hangs, watchdog timeouts, and communication failures

About the Speaker(s)

Jiaxing Cheng is the lead researcher, but could not attend due to visa issues. The work was presented by a proxy speaker (Jeffrey P) from UC Riverside. The research targets the intersection of industrial control system security and automated vulnerability discovery, with practical implications for critical infrastructure protection.