# Industrial Control Vulnerability Research

> Use when hunting new vulnerabilities in latest stable, widely deployed SCADA/IIoT, PLC, HMI, historian, engineering workstation, OPC, industrial gateway, remote-access appliance, safety system, or device-management product. Prioritizes server-side RCE and trust-boundary flaws in management, protocol, firmware-update, project-file, and controller workflows using safe simulation and reproducible ...

- Skill: `netvar1337/industrial-control-vulnerability-research` (Agent Skill)
- Install (CLI): `npx skillmds@latest add netvar1337/industrial-control-vulnerability-research`
- Raw SKILL.md: https://api.skillmd.com/api/skills/netvar1337/industrial-control-vulnerability-research/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- License: MIT
- Author: netvar1337 (https://skillmd.com/u/netvar1337)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/netvar1337/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:

```text
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