ICSSPulse: A Modular LLM-Assisted Platform for Industrial Control System Penetration Testing

1. Problem Statement

Industrial Control Systems (ICS) form the backbone of critical infrastructure (energy, water, manufacturing). While their convergence with Information Technology (IT) networks improves efficiency, it exposes them to cyber threats that are difficult to study safely in live environments.

• The Gap: Existing penetration testing (PT) tools (e.g., Metasploit, Nmap) are designed for general IT and lack the semantic understanding, timing constraints, and deterministic behavior required for ICS protocols like Modbus and OPC UA.
• The Challenge: Direct security testing on live industrial infrastructure is often impossible due to strict availability and safety requirements. There is a lack of open-source, modular tools that allow for safe, reproducible, and protocol-aware experimentation, particularly those that can automate the translation of technical findings into actionable reports.

2. Methodology and Architecture

The authors propose ICSSPulse, an open-source, web-based, modular platform designed to unify network scanning, protocol interaction, and AI-assisted reporting.

Core Architecture

The system is built on a lightweight Python backend (Flask) with a web-based Graphical User Interface (GUI). It follows a modular design where components operate independently but communicate via JSON artifacts.

• Centralized GUI: Orchestrates user interactions, target configuration, and result visualization.
• Network Scanning Module: Integrates RustScan (via Docker) for rapid host and port discovery. It handles command injection risks by securely parsing user inputs.
• Protocol Handlers:
  • Modbus Handler: Uses the pymodbus library. It supports all four data types (Coils, Discrete Inputs, Holding Registers, Input Registers). It features device discovery (scanning Unit IDs) and memory enumeration (scanning address ranges like 40001/30001).
  • OPC UA Handler: Uses the python-opcua library. It supports recursive namespace traversal, endpoint discovery, and node-based interaction (reading/writing variables, methods, and objects).
• LLM-Assisted Reporting Module: A novel component using GPT-4o-mini (via OpenAI API). It aggregates raw scan data, enumeration logs, and exploitation results to generate structured reports.

Penetration Testing Lifecycle Integration

ICSSPulse maps its capabilities to the standard PT lifecycle:

1. Planning/Reconnaissance: Configurable target IPs, ports, and protocols via GUI.
2. Scanning/Enumeration: Automated discovery of live hosts and protocol-specific assets (e.g., Modbus registers, OPC UA nodes).
3. Vulnerability Analysis: Manual interpretation of structured outputs (e.g., identifying unauthenticated access).
4. Exploitation: Controlled read/write operations and malformed request testing.
5. Post-Exploitation: Visual feedback on state changes (e.g., valve status changes).
6. Reporting: Automated generation of Executive and Technical reports.

3. Key Contributions

1. First Unified Web Platform: ICSSPulse is the first web-based platform to combine network scanning, protocol-aware Modbus/OPC UA interaction, and LLM-assisted reporting in a single ecosystem.
2. Protocol Fidelity: Unlike generic tools, it understands ICS semantics, allowing for safe enumeration of registers and nodes without risking physical hardware.
3. LLM-Driven Automation: The platform introduces an automated reporting engine that:
   • Aggregates technical evidence (scan results, register values).
   • Maps findings to the ICS MITRE ATT&CK matrix for mitigation strategies.
   • Generates two distinct report types: Executive (high-level business risk) and Technical (detailed analyst data).
4. Modular Extensibility: The architecture allows for the easy addition of new protocols (e.g., DNP3, MQTT) by adding handler modules without altering the core GUI or routing logic.

4. Experimental Evaluation

The authors evaluated ICSSPulse using three distinct scenarios:

• Scenario A: Synthetic Modbus Server: A Python-based server simulating a PLC, a sensor, and an actuator.
  • Result: Successfully identified active services, enumerated 1,000+ addresses per data type, and performed read/write operations (e.g., changing a fill valve register from 0 to 500, resulting in a 5% opening).
• Scenario B: Factory I/O Water Treatment: A 3D industrial simulator representing a water tank with inlet/outlet valves.
  • Result: The tool manipulated analog and digital signals (coils and registers) to control flow rates and valve states, demonstrating interaction with a realistic process environment.
• Scenario C: Custom OPC UA Production Line: A server modeling a factory with temperature sensors and motors.
  • Result: Successfully traversed the namespace hierarchy, identified read-only vs. writable nodes, and modified motor speed and status variables via anonymous authentication.
• Reporting Evaluation: The system successfully consolidated data from all scenarios into coherent reports. The LLM correctly mapped technical findings (e.g., "Unauthenticated Modbus access") to specific MITRE ATT&CK mitigations and generated readable executive summaries.

5. Significance and Limitations

Significance:

• Educational & Research Value: Provides a safe, reproducible environment for training cybersecurity professionals and researchers to understand ICS vulnerabilities without risking critical infrastructure.
• Bridging the Gap: Connects low-level protocol analysis with high-level management reporting, a critical step often missing in ICS security workflows.
• Open Source: Democratizes access to specialized ICS testing tools, which are often proprietary or expensive.

Limitations:

• Scalability: Being Python-based and relying on containerized tools, it is best suited for small-to-medium laboratory environments rather than large-scale industrial networks.
• Realism: The current evaluation relies on software-only, unauthenticated testbeds. It does not yet model physical actuation, firmware compromise, or complex multi-stage kill chains.
• Automation Scope: Vulnerability scoring is currently manual; automated scoring is planned for future work.

Future Work:
The authors plan to integrate additional protocols (DNP3, IEC 60870-5-104), offload performance-critical tasks to lower-level languages (e.g., C/C++), and extend testing to authenticated deployments and hardware-in-the-loop testbeds.