noorqureshi/security-skills/hardware-ot-ics

OT / ICS security assessment (passive-first)

When it applies

The engagement touches an industrial environment — PLC/RTU controllers, SCADA/DCS, HMIs, engineering workstations, historians, jump hosts, or the IT/OT boundary (firewall rules, data diodes). A misstep here can cause physical harm, not just downtime. Load tradecraft-scope-roe and require the written authorization to spell out: the site and network segments, whether active scanning is allowed, and whether writing coils/registers is allowed — the default for both is NO. Work passive-first; nothing touches a PLC's state until the scope explicitly says so.

Why it works

Industrial protocols (Modbus, S7comm, DNP3, EtherNet/IP) predate hostile networks: they run in cleartext with no authentication (CWE-306), so anyone who can reach the port can read process state — and usually write it. That's exactly why the assessment itself is the risk: a high-rate scan or a stray write can trip a control loop or a safety instrumented system (SIS). Mirrored traffic and offline artifacts reveal the same exposure with zero packets injected.

Iron rules (MUST)

• Never write coils/registers to a PLC unless the authorization explicitly permits it.
• No high-rate scanning of production OT segments — low rate, maintenance window only.
• Never touch SIS paths or anything in a safety loop.
• Prefer, in order: read-only identification → traffic mirroring → offline firmware/config analysis.
• An anomaly or unexpected device response → stop immediately and notify the site contact.

Method

1. Zone and inventory (paper-first). Sketch the Purdue levels L0–L5: field devices → basic

control → supervisory → site DMZ → enterprise. Build the asset list — PLC/RTU/HMI/engineering workstation/historian/jump host — and the expected protocol/port baseline for the authorized segments only (identification, not exploitation): Modbus/TCP 502, S7comm 102, EtherNet/IP 44818, DNP3 20000.

1. Passive capture. Take a SPAN/mirror-port PCAP from an authorized tap:

tshark -i <iface> -w ot-mirror.pcap. Dissect it with Wireshark's ICS dissectors (modbus, s7comm, enip, dnp3) — you learn the live devices, the masters/slaves, the function codes in use, and any cleartext credentials without sending a single packet. A proprietary protocol on the wire goes to reverse-eng-protocol.

1. Offline audit. Review exported controller configuration and engineering projects (TIA

Portal, RSLogix/Studio 5000 exports) offline. Record default credentials and unauthenticated cleartext protocols (Modbus has none) as findings — observe and document; change nothing.

1. Limited active checks — only if the scope says yes. During the agreed maintenance window,

at low rate (nmap -Pn -n --max-rate 20 -p 502,102,44818,20000 <host>, plus targeted NSE identification such as --script modicon-info,s7-info,enip-info), prefer read-only function codes, capture evidence for every step, and stop + escalate at the first anomaly.

1. Firmware and patch surface. Map controller firmware versions to known CVEs (never blind-flash

firmware). Pull images for offline analysis with reverse-eng-firmware and reverse-eng-binary-triage rather than probing the live controller.

1. Report with physical consequence. Every OT finding states its process/physical impact

(what an attacker could make the plant do), and distinguishes remotely exploitable issues from ones requiring physical or control-network access. Lateral movement into the IT side follows network-pivoting-tunneling and the ad domain skills as usual.

Gotchas

• A port scan is an active act on OT. Some PLCs fault or reboot under ordinary scan rates —

mirrored traffic first, always. Don't run default-parameter web/network scanners against OT segments; the profiles are wrong and the risk is real.

• "No response" may mean you hurt something, not that nothing's there — if a device goes quiet

mid-test, stop and notify; check with the site before resuming.

• Most ICS tooling assumes an isolated lab network — stage and rehearse tools in a lab VLAN or

on a mirrored feed, not on the production segment.

• Default creds and no-auth protocols are findings, not invitations — log them, prove reachability

minimally, never exercise a write "to demonstrate".

• Confirm the emergency contact and rollback plan exist before any active phase — including the

maintenance window and who can halt the test.

Verify success

You can produce: the Purdue-zone sketch with a reconciled asset inventory, the observed protocol/port baseline from passive capture, a findings list with physical-impact framing (remote vs physical reachability stated per finding), and — for any authorized active step — a step-by-step evidence trail showing read-only behavior and zero unplanned state changes.

References

NIST SP 800-82 (ICS security); ATT&CK for ICS; Wireshark ICS dissector docs; reverse-eng-firmware.

_Portions adapted from reverse-skill by zhaoxuya520, MIT License._