312-50 Question 427
Single answer▪ OT Hacking MethodologyYou are conducting an authorized security assessment of a power utility's OT environment that includes an engineering workstation, a historian, HMIs, and several PLCs controlling a water treatment process. Operations has stated that production must not be interrupted and that active testing against controllers is prohibited unless explicitly approved. During initial reconnaissance, you discover that the engineering workstation has vendor software installed and can communicate with the PLC network. What is the MOST appropriate next step in an OT hacking methodology that balances validation of risk with operational safety?
- A
Launch a high-speed vulnerability scan directly against the PLC IP range to quickly identify firmware weaknesses before the maintenance window ends
- B
Use the engineering workstation to perform passive asset identification and configuration review, then validate findings in a lab or during an approved maintenance window before any active interaction with PLCs
- C
Send malformed Modbus and DNP3 packets to each controller at a low rate so the testing remains safe while still proving exploitability
- D
Attempt to upload a modified ladder logic project to a non-critical PLC because controlled code changes are the most reliable way to confirm impact
Show answer and explanation
Correct answer: B
Explanation
In OT environments, the assessment methodology differs from traditional IT testing because safety and availability take priority over aggressive proof-of-exploit techniques. A sound CEH-aligned approach is to begin with passive discovery, review of engineering workstations and historian data, examination of controller project files and firmware versions, and correlation with known vulnerabilities. Where direct testing is necessary, it should occur only with formal approval, compensating controls, operator awareness, and preferably in a lab or during a maintenance window. This aligns with widely accepted OT/ICS guidance from NIST SP 800-82, which emphasizes minimizing impact to industrial processes, and with common vendor guidance that discourages indiscriminate scanning or malformed protocol testing on production controllers.
- A. Incorrect.
This is incorrect because high-speed or conventional vulnerability scanning against PLCs and other OT devices can cause instability, communication loss, or process disruption. OT assessment methodology emphasizes safety, passive discovery where possible, and coordination with operations before any intrusive action. Treating controllers like standard IT hosts is a common mistake.
- B. Correct.
This is correct because OT methodology prioritizes process safety, availability, and change control. Reviewing the engineering workstation, installed project files, firmware inventories, logic backups, network configurations, and vendor software can identify exposure without directly stressing controllers. If active validation is needed, best practice is to use a representative lab, digital twin, or an approved maintenance window with operator coordination.
- C. Incorrect.
This is incorrect because intentionally sending malformed industrial protocol traffic is still active testing and can destabilize PLCs, RTUs, gateways, or serial-to-IP converters even at low volume. The misconception is that low-rate traffic is automatically safe in OT; in reality, many industrial devices are sensitive to unexpected protocol behavior regardless of rate.
- D. Incorrect.
This is incorrect because uploading modified logic to a PLC changes the control state and introduces unacceptable operational risk unless it is specifically planned, approved, and tested under tightly controlled conditions. Even on a so-called non-critical PLC, dependencies and interlocks can have process-wide effects. OT methodology does not use logic modification as an initial validation step.