Skip to content
Security
Skill

/testing-ics-ot-protocols

Test Industrial Control Systems and Operational Technology protocols — Modbus, DNP3, OPC UA, BACnet, EtherNet/IP, S7comm, MQTT — with safety-first methodology for SCADA and ICS environments. Use when assessing OT network security, testing ICS protocol authentication, reviewing

BOOST
From plugin
secskills
17094 skills
Install
$ npx -y skills add trilwu/secskills --skill testing-ics-ot-protocols --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/testing-ics-ot-protocols

Context preview

The summary Claude sees to decide when to auto-load this skill.

Test Industrial Control Systems and Operational Technology protocols — Modbus, DNP3, OPC UA, BACnet, EtherNet/IP, S7comm, MQTT — with safety-first methodology for SCADA and ICS environments. Use when assessing OT network security, testing ICS protocol authentication, reviewing

SKILL.md

testing-ics-ot-protocols.SKILL.md
name: testing-ics-ot-protocols
description: Test Industrial Control Systems and Operational Technology protocols — Modbus, DNP3, OPC UA, BACnet, EtherNet/IP, S7comm, MQTT — with safety-first methodology for SCADA and ICS environments. Use when assessing OT network security, testing ICS protocol authentication, reviewing IT-OT segmentation, or performing authorized ICS penetration testing.
verified: 2026-07-27

Testing ICS/OT Protocols

ICS/OT protocols were designed for reliability in isolated networks, not security on connected ones. Most have no authentication, no encryption, and no integrity checking. The danger is not that they are hard to exploit — it is that exploitation can have physical consequences, which is why safety constraints govern everything you do here.

When to Use

  • Assessing SCADA networks or ICS environments during an authorized engagement
  • Testing Modbus, DNP3, OPC UA, BACnet, EtherNet/IP, S7comm, or MQTT devices in scope
  • Performing an ICS-specific penetration test with OT safety requirements
  • Reviewing OT network segmentation and Purdue model compliance
  • Evaluating remote access pathways into control system networks
  • Inventorying ICS assets and identifying unauthenticated protocol exposure

When NOT to Use

  • **Standard IT network scanning** — use `enumerating-network-services`
  • **HMI web interfaces tested as regular web apps** — use `testing-web-applications`
  • **Writing ICS-specific detection rules** — use `engineering-detections`

Safety-First Principles

OT pentesting is not IT pentesting with different ports. The rules of engagement are fundamentally different because the targets control physical processes.

**Why active scanning is dangerous in OT:**

  • PLCs and RTUs run minimal embedded firmware. A malformed packet or unexpected connection can crash the device, halt a process, or cause it to fail to a dangerous state.
  • Restarting a PLC may require physical access, and the process it controls may not tolerate interruption.
  • Some devices interpret any TCP connection as a command session — connecting is acting.
  • Nmap's default service probes have crashed PLCs in production environments.

**Mandatory constraints:**

1. Always have an OT engineer or plant operator present or on immediate call during active testing. 2. Obtain written authorization that explicitly covers ICS/OT assets — general network pentest scope does not imply OT scope. 3. Test in maintenance windows whenever possible. Never test safety-instrumented systems (SIS) without explicit, separate authorization. 4. Start with passive observation. Move to active enumeration only after the passive phase confirms device types and the OT engineer approves. 5. Distinguish read-only operations (reading registers, querying device info) from write operations (setting coils, writing registers, issuing commands). Write operations require per-device approval. 6. Have a rollback plan for every write operation. Know the expected state before you change anything. 7. Document every interaction with every device, including timestamps and the exact commands sent.

Protocol Overview

| Protocol | Default Port | Auth by Design | Encryption | Notes | |---|---|---|---|---| | Modbus TCP | 502 | No | No | Most common ICS protocol; any host on the network can read/write | | DNP3 | 20000 | Optional (SA) | No | SCADA polling; Secure Authentication is rarely deployed | | EtherNet/IP (CIP) | 44818 | No | No | Rockwell/Allen-Bradley ecosystem | | OPC UA | 4840 | Yes (multiple modes) | Optional (TLS) | Modern; security depends entirely on configuration | | BACnet/IP | 47808 (UDP) | No | No | Building automation — HVAC, lighting, access control | | S7comm | 102 | No | No | Siemens S7 PLCs; replaced by S7comm-plus with some protection | | MQTT | 1883 / 8883 (TLS) | Optional | Optional (TLS) | IoT/ICS messaging; brokers often left open |

Passive Reconnaissance

Start here. Passive observation carries no risk of disrupting devices and provides the asset inventory you need before touching anything.

**Wireshark with ICS dissectors:**

# Capture on the OT network interface (mirror/span port or tap)
tcpdump -i eth0 -w ics_capture.pcap -n

# Wireshark filters for ICS protocols
# Modbus
modbus

# DNP3
dnp3

# EtherNet/IP
enip

# OPC UA
opcua

# BACnet
bacnet

# S7comm
s7comm

# MQTT
mqtt

**What to extract from passive captures:**

  • Device IP addresses and MAC addresses (OUI lookup identifies vendor — Siemens, Rockwell, Schneider, ABB)
  • Protocol distribution — which protocols are in use, on which segments
  • Polling patterns — master/slave relationships, polling intervals, which registers are read
  • Firmware versions visible in protocol banners or response fields
  • Unexpected traffic — IT protocols on OT segments, devices communicating outside expected patterns
  • Unencrypted credentials in MQTT CONNECT packets, OPC UA sessions, or HTTP-based HMIs

**Asset inventory from passive observation:**

Build a table: IP, MAC, vendor (from OUI), protocol(s) observed, role (master/slave/HMI/historian), firmware version if visible. This becomes the basis for active enumeration scope.

Active Enumeration (When Authorized)

Only proceed after: (1) passive recon is complete, (2) OT engineer has reviewed the asset list and approved active testing, (3) scope explicitly includes active ICS enumeration.

**Safe nmap usage for ICS:**

# NEVER use aggressive timing or default scripts against OT devices
# Use slow timing and specific ICS scripts only

# Modbus device discovery
nmap -Pn -sT -p 502 --script modbus-discover TARGET

# Siemens S7 device info (read-only query)
nmap -Pn -sT -p 102 --script s7-info TARGET

# BACnet device enumeration
nmap -Pn -sU -p 47808 --script bacnet-info TARGET

# EtherNet/IP enumeration
nmap -Pn -sT -p 44818 --script enip-info TARGET

# OPC UA discovery
nmap -Pn -sT -p 4840 --script opcua-endpoints TARGET

# IMPORTANT: Use -Pn (skip host discovery), -sT (full connect, not
Read more
Ships withsecskills

**Security skills for Claude Code that encode the judgment professionals bring, not another wrapper around a scanner.** Offense, defense, and the reverse-engineering and code-audit core both sides share. Every skill is fact-checked against primary sources.

Get the whole plugin

Other skills on secskills.