Industrial Control Vulnerability Research

Bundled with Unleash skills pack. Source: C:\Users\Admin.agents\skills\industrial-control-vulnerability-research\SKILL.md

Industrial Control Vulnerability Research

Target Priorities

Prefer broadly deployed products with one or more:

• internet/enterprise-facing remote access, VPN, web, OPC, MQTT, or management service;
• engineering workstation that ingests untrusted project/device data;
• HMI/historian/SCADA server running with high privilege;
• gateway translating untrusted IT protocols into control protocols;
• centralized fleet/device management and signed update distribution;
• default credentials are not the sole issue;
• reproducible latest firmware/software available for lab validation.

Focus first on RCE and enterprise/server compromise. Treat process manipulation or safety impact as separate downstream consequences after software-boundary proof.

Phase 1: Exact Product and Deployment Identity

Record:

• vendor, model, hardware revision, region/SKU;
• latest stable firmware and release date;
• bootloader, OS/kernel, web stack, protocol libraries, and application versions;
• engineering/HMI/server software and patches;
• licensed modules and default-enabled services;
• field deployment evidence and typical topology;
• update path and whether firmware differs by hardware revision;
• hashes and provenance for firmware/installers.

Do not assume the highest version string applies to every hardware revision. Verify the vendor's current image for the exact model.

Completion criterion: the lab target matches a currently deployed hardware/software line and latest stable release.

Phase 2: Build a Safe Digital Twin

Use, in order:

1. vendor simulator/emulator;
2. isolated hardware bench with no process connection;
3. extracted service in a container/chroot/QEMU system emulation;
4. protocol mock implementing only required state;
5. full controller/HMI pair on an isolated switch.

Instrument power/reset recovery and keep a known-good firmware restore path. Stub physical outputs or use simulation mode. Capture baseline traffic before mutation.

Completion criterion: crashes and state changes cannot affect production or physical processes, and recovery is tested.

Phase 3: Attack-Surface Map

Enterprise/management plane

• web/API, VPN, SSH, proprietary admin services;
• OPC UA/DA gateways, MQTT brokers, database and historian interfaces;
• update, backup, restore, project import/export;
• fleet enrollment, certificates, licensing, and remote support;
• report generation, alarm/event ingestion, and connectors.

Control/field plane

• Modbus/TCP, DNP3, IEC 60870-5-104, IEC 61850, EtherNet/IP/CIP, PROFINET, BACnet, vendor protocols;
• discovery, routing, diagnostics, firmware download, program upload/download;
• cyclic/acyclic messages and fragmented transfers;
• controller-to-engineering-workstation callbacks.

File and supply interfaces

• project files, ladder/function-block assets, symbol databases;
• recipes, trends, reports, HMI graphics, scripts, fonts/images;
• firmware packages, modules, drivers, and device descriptions;
• removable media and automatic project synchronization.

For each surface record default exposure, auth, parser, process privilege, safety role, and updateability.

Phase 4: Protocol-State Research

Capture valid sessions and model:

discovery -> capability negotiation -> session/auth -> object addressing
 -> read/write/execute/download -> completion/error -> disconnect/recovery

Mutate with state awareness:

• length/count/fragment relationships;
• object class/instance/attribute identifiers;
• transaction/session sequence numbers;
• duplicate, reordered, late, and unsolicited messages;
• connection teardown during async work;
• route/path nesting and encapsulated protocols;
• compression and certificate structures;
• diagnostic and maintenance opcodes;
• version/capability downgrade.

Use grammar-aware clients and snapshots. Separate read-only parser campaigns from state-changing commands.

Completion criterion: every mutation is replayable and labels whether it can alter controller state.

Phase 5: Engineering-Workstation and Server RCE

Trace untrusted data arriving from:

• controller/device discovery responses;
• uploaded project/symbol/configuration;
• historian/alarm records;
• imported project archives;
• web dashboards and report templates;
• device-description/plugin packages;
• remote support bundles.

High-yield sinks:

• native parsers and image/font/document libraries;
• unsafe deserialization;
• script/template/expression engines;
• archive extraction and path handling;
• dynamic plugin/library loading;
• database queries and command helpers;
• privileged service IPC from unprivileged UI.

A malicious field device that compromises the engineering workstation is a valuable server-side/client-of-device boundary even without internet exposure.

Phase 6: Firmware and Update Trust

Inspect:

• signature coverage and verification order;
• encrypted but unauthenticated packages;
• rollback/downgrade controls;
• signed outer archive with unchecked inner files;
• hardware-revision and model binding;
• bootloader recovery/update channels;
• update extraction paths, symlinks, permissions, and hooks;
• management server redistribution to fleets;
• delta update integer/parsing paths.

Distinguish signature bypass from parser RCE before verification. Both can be high impact but require different evidence.

Phase 7: Embedded Service Analysis

For extracted firmware:

• inventory architecture, filesystem, init/services, listeners, users, capabilities, and writable roots;
• identify third-party versions and vendor patches;
• emulate individual daemons with realistic config and filesystem;
• fuzz parsers in-process when semantics are preserved;
• test on hardware after minimization;
• inspect watchdog/restart and fail-open behavior.

Do not claim hardware applicability solely from emulation; verify the shipped binary and configuration on the exact latest image.

Phase 8: Impact and Resilience

Classify separately:

• management/HMI/historian code execution;
• controller code execution;
• credential/certificate compromise;
• cross-zone pivot;
• fleet update compromise;
• loss of view/control;
• persistent device denial;
• process/safety consequence.

For the PoC, stop at a harmless marker, controlled crash with automatic recovery, or simulated output. Record watchdog and reboot behavior.

Variant Hunting

Search:

• product families sharing protocol stacks;
• engineering software and device firmware copies of the same parser;
• old hardware branches missing newer fixes;
• gateway translations that validate only one side;
• project import and controller upload implementations;
• management-server and local-tool versions of update logic;
• OEM-rebranded devices and licensed third-party components;
• recovery bootloader and normal firmware parsers.

Common Pitfalls

1. Testing latest software against old device firmware.
2. Inferring deployment from internet scans alone.
3. Mutating live control networks or physical outputs.
4. Calling default credentials a novel software vulnerability.
5. Ignoring malicious-device-to-engineering-workstation paths.
6. Assuming encrypted firmware is authenticated.
7. Claiming hardware impact from an emulated daemon only.
8. Mixing software compromise with speculative safety impact.

Verification Checklist

• Exact model/hardware revision/latest firmware proven
• Deployment evidence and typical topology documented
• Safe digital twin and restore path verified
• Management, field, and file surfaces mapped
• Stateful protocol harness reproduces valid sessions
• State-changing tests separated and controlled
• Engineering/server hostile-input paths traced
• Update signature and model-binding boundaries tested
• Finding reproduced on shipped latest image/hardware where required
• Impact, physical consequence, and resilience reported separately
• Novelty gate passes