Why OT Pen Testing Is Not IT Pen Testing

In a typical IT penetration test, the tester can run aggressive Nmap scans, exploit vulnerabilities, crash and restart services, and use automated exploitation frameworks freely. The worst outcome of a misconfigured test is a crashed Windows server that reboots in 5 minutes. In an OT environment, the constraints are fundamentally different: a crashed PLC may trip a production process worth tens of thousands of dollars per minute of downtime, trigger a safety system response, or — in extreme cases — cause a physical consequence. A Modbus TCP packet with an unexpected function code can cause some PLCs to enter a fault state that requires on-site engineer intervention to clear. A malformed EtherNet/IP CIP packet has been demonstrated to crash older Rockwell ControlLogix controllers (e.g., CVE-2012-6435). The OT penetration tester must operate with a safety-first, minimum-footprint discipline that IT testers are not accustomed to.

Pre-Engagement Scoping and Safety Constraints

Before any technical activity, the OT penetration testing engagement must produce a formal scoping document that defines: the IP ranges and device types that are in scope for active testing, the IP ranges that are passive-observation-only (no active packets), the IP ranges that are strictly out of scope (live safety instrumented systems, systems without authorized maintenance windows), the timing constraints (testing only during planned maintenance windows when production is off, or during normal operations with specific restrictions), and an emergency stop procedure — who to call and what to do if any process anomaly is observed during testing. A safety officer from the OT operations team should be present or on-call for the duration of active testing. The engagement kick-off meeting must include the CISO, OT operations manager, and site safety officer — not just the IT security team.

Passive Reconnaissance: Network Sniffing and Asset Discovery

The OT pen test begins with passive network observation. A laptop with Wireshark and a mirror port on the OT core switch captures traffic for 24–48 hours. This reveals: all communicating IP addresses and protocols, communication patterns (who talks to whom on what protocol), potential rogue devices (IPs not in the asset register), and protocol anomalies (plaintext credentials in Telnet or FTP sessions). From Wireshark captures, the tester builds a manual asset map. Tools like Redpoint NSE scripts (Nmap Scripting Engine scripts designed for ICS protocols, available on GitHub) can perform lightweight active enumeration using protocol-native queries — reading the identity object of an EtherNet/IP device or querying a Modbus device identity register — with much lower risk than generic port scanning. PLCScan (a Python tool) identifies Siemens S7 and Modbus devices on a network using targeted protocol queries. These queries are low-risk because they use standard protocol functions that devices are designed to respond to, unlike generic TCP SYN scans that may confuse OT devices.

OT Protocol Exploitation Techniques

Many industrial protocols were designed without authentication or encryption, making them inherently exploitable by any device on the OT network. A tester with network access can demonstrate:

  • Modbus TCP function code abuse: Modbus has no authentication. Any device that can reach TCP port 502 on a PLC can send function codes. FC 5 (Write Single Coil) and FC 6 (Write Single Register) can modify output states and setpoints. FC 16 (Write Multiple Registers) can push a block of data values. The tester demonstrates this by writing a benign value to a pre-agreed non-critical register with operations staff monitoring, then restoring the original value — proving that unauthenticated write access exists without causing a process upset.
  • EtherNet/IP CIP identity object read: The CIP (Common Industrial Protocol) Identity Object (Class 0x01, Instance 0x01) returns vendor ID, product type, product code, revision, and serial number — a complete device fingerprint — without authentication. This enables precise vulnerability targeting against specific firmware versions.
  • DNP3 unsolicited responses: DNP3 supports unsolicited response mode where the outstation proactively sends data to the master. A tester with DNP3 master capability (using the OpenDNP3 library or Aegis) can send DNP3 Unsolicited Response Enable/Disable commands to some RTUs without authentication, potentially disrupting the data collection that operators rely on for situational awareness.
  • BACnet Read Property scan: BACnet (used in building automation) has no authentication in its standard form. The BACnet Read Property service can enumerate all objects on a controller — exposing every HVAC zone, VAV box, and temperature sensor — and the Who-Is/I-Am broadcast can discover all BACnet devices on a network segment.

Common OT Vulnerabilities Found in Real Assessments

Across real-world OT penetration tests, the most consistently found vulnerabilities are: default credentials on PLCs, HMIs, historian servers, and managed switches — the tester can log into the Siemens S7 engineering interface or the Wonderware InTouch license server with vendor default passwords. Unencrypted protocols — Telnet to managed switches (instead of SSH), HTTP to HMI web interfaces (instead of HTTPS), FTP for historian data export (instead of SFTP). Exposed engineering workstations — EWS with RDP exposed to the OT network with no NLA required, or with accounts shared among multiple engineers (no individual accountability). Direct IT-OT connectivity — a network trace reveals that the OT historian is directly reachable from corporate workstations with no IDMZ in between. Stale accounts — contractor accounts from a vendor project two years ago remain active and have not been reviewed.

Lateral Movement from IT to OT

The most valuable demonstration in an OT pen test is the IT-to-OT kill chain: starting from a simulated phishing compromise of a corporate workstation (Levels 4/5), traverse through the IDMZ or a missing DMZ into the OT environment (Levels 2/3), and reach a PLC or safety system (Level 1/0). Common paths include: corporate workstation → directly reachable historian (misconfigured firewall) → historian has SMB access to engineering workstation → EWS has RSLogix 5000 installed → RSLogix can connect directly to production PLCs. Alternatively: corporate workstation → VPN or RDP to OT jump server with shared credentials → jump server has direct RDP to all HMIs → HMI can issue commands to PLCs. Demonstrating this kill chain with screenshots and packet captures — stopping before any actual PLC command is sent — is the highest-impact finding the assessment can produce for executive decision-making.

Reporting, Remediation Prioritization, and ICS-CERT Disclosure

OT pen test reports must be structured for two audiences: the technical OT engineering team (who needs specific remediation steps: change this default password, configure this firewall rule, update this firmware version) and operational and executive leadership (who needs to understand business risk: what could an attacker do, what is the consequence, what is the remediation cost vs. the risk reduction). Findings are prioritized by a combination of CVSS environmental score, exploitability (demonstrated vs. theoretical), and operational impact (process upset potential vs. data confidentiality only). Where a vulnerability affects a widely-used OT product and has not been publicly disclosed, responsible disclosure to ICS-CERT (CISA ICS-CERT at cisa.gov/ics-cert) is the appropriate channel — ICS-CERT coordinates with vendors on patch development and advisory publication while providing the reporter CVE assignment credit.