OT (Operational Technology) Penetration Testing

This phase is far more detailed and rigid than in any other type of test.

1.1. Define Objectives

• Primary Goal: To identify vulnerabilities that could allow an attacker to cross the IT/OT boundary and affect a physical process without causing an outage.
• Secondary Goals:

1.2. Define Scope

• In-Scope:
• Out-of-Scope (Strictly Enforced):

1.3. Establish Rules of Engagement (ROE)

• Testing Window: MANDATORY. Must be scheduled during a planned maintenance shutdown. Testing on a live, running process is forbidden.
• SME Escort: MANDATORY. A qualified plant engineer or OT operator with "stop-button" authority must be physically present with the tester at all times.
• Test Lab: The client must provide a non-production test rig (e.g., a "skid") with identical or similar PLCs, HMIs, and controllers for all "exploitation" and active-testing phases.
• "Stop" Command: A single verbal command from the SME escort (e.g., "STOP") will result in the immediate cessation of all testing activities.
• Tooling: All tools must be approved. Standard IT scanners (Nessus, nmap with default scripts) are forbidden on the production network. Use of specialized OT-safe tools is required.

The goal is to build an asset inventory without disrupting operations.

2.1. Passive Reconnaissance (OSINT)

• Identify vendor manuals, HMI screenshots, network diagrams, or system information that employees or vendors may have posted publicly.
• Search ICS-CERT advisories for known vulnerabilities related to the client's vendors.

2.2. Passive Network Reconnaissance (Network Tapping)

• This is the primary recon method.
• Connect to a SPAN or Tap port on a core switch to receive a mirrored copy of the network traffic.
• Tools: Wireshark (with OT protocol dissectors like Modbus, DNP3, S7comm), tcpdump.
• Goals:

2.3. Cautious Active Reconnaissance

• Performed only if the ROE allows, only during the maintenance window, and only with the SME present.
• Do not run a default nmap -sS -p- scan. This can and will crash fragile OT devices.
• Method:

3.1. Vulnerability Mapping

• Correlate the discovered asset inventory (from Phase 2) with known vulnerabilities (e.g., default credentials, insecure protocols, ICS-CERT alerts).
• Key Focus: Purdue Model Violations.

3.2. Test Rig Attack Planning

• Based on the vulnerabilities found, develop attack scenarios to be tested only in the offline test lab.
• Example Scenarios:

CRITICAL: THIS PHASE IS NEVER PERFORMED ON THE PRODUCTION NETWORK.

All activities in this phase are conducted in the isolated, non-production test lab.

Attack Simulation

• Gain Initial Access: (e.g., Exploit a vulnerability on the IT/OT jump-box).
• Protocol Abuse: Use OT-specific tools (modbus-cli, s7pclient) to interact with the test PLC.
• Read Commands: (Harmless) Read a coil or register (e.g., READ_COIL).
• Write Commands: (The "Exploit") Attempt to write to a register or coil (e.g., WRITE_SINGLE_COIL) to change a setting or stop the test PLC.
• Man-in-the-Middle (MITM): Use tools like ettercap (in the lab!) to intercept traffic between the test HMI and test PLC.
• Goal: Inject false data. Make the HMI show a "Normal" (e.g., 100 PSI) value while sending a "Danger" (e.g., 200 PSI) command to the PLC, or vice-versa.
• HMI Hijacking: Use default VNC/RDP credentials to take remote control of the test HMI.

5.1. Impact Analysis (Business Risk)

• Do not focus on data exfiltration. Focus on the physical consequences.
• Work with the SME to document the real-world impact of the lab-proven exploit.
• Examples:

5.2. Reporting

• Executive Summary: Must be focused on physical risk, safety, and business continuity. Use financial and operational impact language.
• Technical Report:

Remediation

• This is NOT like IT . You cannot just "patch the PLC." Patches are often vendor-dependent, require a full plant shutdown, and may not even exist.
• Focus on Compensating Controls: