ICS Penetration Testing

Why ICS Penetration Testing Requires Specialized Methodology

The fundamental constraint that separates ICS penetration testing from every other form of security testing is this: the test itself must not cause the harm it is meant to simulate protecting against. In a standard IT penetration test, a failed or uncontrolled exploit crashes a web server or corrupts a database record. In an ICS environment, the equivalent failure can cause a safety incident, damage equipment worth millions of dollars, or produce a production loss that cascades across critical infrastructure. A misconfigured Modbus write command to a live PLC controlling a chemical reactor mixing ratio is not an inconvenience. It is a process safety event. This reality governs every decision in ICS penetration testing methodology.

The contrast with IT penetration testing runs across every dimension of the engagement:

The protocol knowledge requirement deserves particular emphasis. Modbus, DNP3, OPC UA, EtherNet/IP, PROFINET, BACnet, and IEC 61850 are not simply alternative versions of web protocols. Each was designed for a specific set of physical process control requirements: real-time determinism, specific master-slave architectures, and command semantics tied directly to physical actuator states. Understanding how a DNP3 master station spoofing attack differs from a Modbus function code injection attempt, and understanding the physical process consequences of each in a specific installation, requires hands-on experience that cannot be derived from IT security training alone.

The methodology follows the SANS ICS613 course framework, which trains engineers and security professionals with the mindset, methodologies, and techniques required to safely conduct ICS penetration tests. Our analysts hold GICSP, GRID, OSCP, and ISA/IEC 62443 certifications and have hands-on experience with the industrial protocols and hardware architectures found across energy, utilities, water, chemical, manufacturing, and transportation sectors.

GDF's ICS Penetration Testing Methodology

Each engagement follows a structured five-phase methodology developed specifically for operational technology environments. Operational safety is prioritized at every stage without sacrificing the technical rigor necessary to produce definitive findings about exploitability and impact.

Phase 1: Planning and Scoping

ICS penetration test scoping is substantially more complex than IT scoping because the consequences of scope errors are potentially severe. GDF begins every engagement with an extended planning phase that establishes the precise boundaries of the test, the safety measures in place during testing, and the emergency procedures that govern the engagement throughout.

• Emergency halt procedures: Written and agreed-upon procedures for immediately suspending any testing activity are established before any work begins. These procedures define who can call a halt, how the signal is communicated to the test team, and what actions the test team takes to ensure no active exploit is left in a partial state.
• Out-of-scope system documentation: Safety instrumented systems (SIS), active protective relays, and other safety-critical assets are explicitly documented as out-of-scope. Testing near these systems requires additional review and approval processes beyond what applies to general OT assets.
• Coordination with operations and safety teams: GDF works directly with operations staff, control engineers, and safety officers to understand the process context of each in-scope system. Pre-test coordination with operations staff is far more extensive than the scoping calls typical in IT penetration testing because the operational consequences of each test action must be fully understood before execution.
• Testing window establishment: Maintenance windows and off-peak production periods are identified for any testing activity that will involve active network interaction, even limited active reconnaissance on the production network.
• Documentation and written authorization: All agreed scope, constraints, emergency procedures, and testing windows are documented in signed form before testing begins.

Phase 2: Passive Discovery

Once planning and coordination are complete, GDF begins with an exclusively passive discovery phase that produces no active probe traffic on the production network. Passive discovery produces the detailed environmental picture needed to design safe and targeted exploitation scenarios.

• Network traffic observation: Network TAPs or SPAN port captures are deployed to collect ICS protocol traffic without generating any outbound probe packets. GDF analyzes this traffic using specialized ICS protocol analysis tools to identify assets, enumerate communications, and characterize the control network topology.
• Purdue Model layer mapping: Traffic analysis maps identified assets to their position in the Purdue Model hierarchy: enterprise network (Level 4-5), site operations and control (Level 3), supervisory control and SCADA (Level 2), and field control (Level 1). Purdue Model layer mapping is critical for understanding attack paths from IT-side entry points down to process control assets.
• IT/OT junction analysis: GDF specifically characterizes the points where IT and OT networks connect, including DMZ architectures, data diodes, jump servers, and historian connections. The IT/OT boundary is the most frequently exploited attack path: 96% of OT security incidents originate from IT-level compromises, according to TXOne Networks 2026 research.
• Protocol identification: Each protocol observed on the OT network is identified and characterized, including the specific function codes, device addresses, and command types in use. This informs the protocol-specific exploitation scenarios developed in Phase 3.
• Configuration documentation review: In parallel with network observation, GDF reviews any existing architecture diagrams, asset inventories, and configuration documentation provided by the client. Documentation review supplements the passive network view with configuration-level detail not observable from traffic analysis alone.

Phase 3: Threat Modeling

With the environment fully characterized, GDF develops a threat model specific to the client's sector, asset types, and observed security posture. This phase translates intelligence about real ICS adversaries into targeted exploitation scenarios relevant to the specific environment under test.

• Adversary mapping by sector: GDF maps threat actors documented in public ICS threat intelligence reporting to the client's sector. For energy sector clients, VOLTZITE (linked to China's Volt Typhoon activity) is a relevant actor that has compromised electric utilities and exfiltrated OT network diagrams and GIS data. For power grid clients, ELECTRUM has demonstrated capabilities targeting grid operations directly. For broader critical infrastructure clients, BAUXITE has exploited internet-exposed PLCs with default credentials. Each adversary profile informs the capabilities and techniques modeled in the subsequent exploitation phase.
• Assumed-breach scenario development: Many ICS attacks begin from the enterprise IT network, not from a direct OT-network attack. GDF develops assumed-breach scenarios that simulate an adversary who has already established access on the corporate IT network and is moving toward OT assets. Assumed-breach scenarios accurately reflect how ICS attacks actually unfold and test the IT/OT boundary controls most relevant to real risk.
• Vulnerability mapping: Findings from the passive discovery phase are mapped to known vulnerability classes: authentication weaknesses on HMIs and engineering workstations, protocol-level weaknesses in the observed ICS protocols, segmentation gaps identified from traffic analysis, and remote access configuration issues. Vulnerability mapping produces a prioritized set of exploitation scenarios for Phase 4.

Phase 4: Safe Exploitation Testing

GDF executes exploitation testing exclusively in safe environments, using one or more of the three methodologies described in detail in the Safe Testing Environments section below. Within these environments, the test team pursues the full attack chain: initial access, lateral movement through the environment, protocol-specific exploitation of control system assets, and documentation of the physical process impact that successful exploitation would produce.

• Living-off-the-land techniques: GDF prioritizes techniques that use legitimate industrial protocols and native engineering tools rather than specialized attack tools where possible. This approach mirrors how sophisticated adversaries operate in ICS environments, using Modbus function codes, DNP3 master station commands, or CIP requests that appear identical to legitimate engineering traffic.
• Protocol-specific testing: Each in-scope ICS protocol is tested for the attack vectors specific to that protocol, as detailed in the Protocol-Specific Penetration Testing section below.
• IT/OT boundary traversal: The test team attempts to demonstrate a complete attack path from an IT-side entry point through the boundary into the OT network, reaching control system assets and achieving a defined end-state objective such as unauthorized command execution or disruption of a simulated process view.

Phase 5: Reporting and Remediation Planning

GDF's reporting for ICS penetration test engagements goes substantially beyond a standard vulnerability listing with CVSS scores. ICS environments require a reporting approach that connects technical findings to operational consequences and provides actionable guidance that accounts for the remediation constraints specific to production control systems.

• Operational impact analysis: Each finding is documented with an analysis of the physical process impact that successful exploitation would produce in the production environment, expressed in terms that operations leadership can understand alongside the technical details.
• Compensating control recommendations: For findings that involve vulnerabilities that cannot be patched, GDF documents specific compensating controls: network segmentation changes, protocol command allow-listing, monitoring detections, or physical access restrictions that reduce exploitability without requiring changes to the production system itself.
• Executive summary: A separate executive-level summary presents findings in business and operational terms, without requiring technical expertise to understand the significance of identified risks.
• Prioritized remediation roadmap: Remediation items are organized by a combination of operational impact, exploitation difficulty, and maintenance window compatibility. Items requiring immediate compensating controls are separated from those appropriate for the next scheduled maintenance window, and from those that can be addressed over longer timeframes without elevated risk.
• Regulatory framework mapping: Findings and remediation items are mapped to applicable regulatory requirements, including NERC CIP controls, TSA directive requirements, IEC 62443 security level specifications, and NIST SP 800-82 Rev. 3 guidance, producing documentation that serves both the security program and compliance needs simultaneously.

Protocol-Specific Penetration Testing

Industrial control systems use protocols designed for reliability and real-time determinism, not security. Most were developed before networked OT environments were considered a realistic attack surface. As IT/OT convergence has eroded the network isolation that once protected these protocols, the authentication and integrity weaknesses built into their designs have become directly exploitable by adversaries with access to the OT network. GDF's protocol-specific testing methodology addresses each major ICS protocol with techniques tailored to its specific architecture and the attack vectors relevant to production installations.

Modbus TCP and RTU

Modbus provides no authentication, no message integrity verification, and no command authorization. Any device on the network with the correct Modbus function code and device address can read coils and registers or write to them. GDF's Modbus testing covers:

• Unauthenticated read commands targeting coil and register addresses associated with process setpoints, control outputs, and status flags
• Unauthenticated write commands to output coils and holding registers to demonstrate unauthorized process state modification
• Memory map enumeration to characterize what process parameters are exposed through the Modbus interface and identify control-relevant register addresses
• Replay attacks capturing and retransmitting legitimate command sequences to demonstrate that recorded traffic can be used to reproduce commands outside authorized engineering sessions

DNP3

DNP3 is used extensively in electric utilities, water systems, and pipeline operations for master station to remote terminal unit (RTU) communication. Its authentication mechanisms, where implemented, have documented weaknesses. GDF's DNP3 testing covers:

• Master station spoofing to send unauthorized control commands to RTUs and outstations using crafted DNP3 master station frames
• Unauthorized outstation control to demonstrate the ability to alter output states through DNP3 direct operate or select-before-operate commands
• Replay attacks capturing legitimate control sequences and retransmitting them to confirm that DNP3 replay protection is absent or inadequate
• Unsolicited response flooding to characterize denial-of-service potential against DNP3 master stations
• DNP3 Secure Authentication weakness analysis where SA version 2 or version 5 is implemented, examining the cryptographic implementation and authentication bypass potential

OPC UA

OPC UA has been adopted as the primary standard for secure, platform-independent data exchange in modern ICS environments. Despite its security design, OPC UA implementations frequently contain configuration weaknesses that undermine its security model. GDF's OPC UA testing covers:

• Authentication bypass attempts targeting OPC UA servers configured with anonymous access, inadequate certificate validation, or weak credential policies
• Certificate trust abuse to demonstrate whether the OPC UA trust model can be exploited by presenting a certificate that the server incorrectly accepts as valid
• Session hijacking attempts targeting OPC UA session establishment protocols
• Access control misconfiguration review to identify whether server-side access control allows unauthorized read or write access to nodes representing sensitive process variables

EtherNet/IP and CIP

EtherNet/IP and the Common Industrial Protocol (CIP) are used extensively in Rockwell Automation PLCs and Allen-Bradley control systems. CIP provides a rich command set for device configuration and programming that, without adequate network segmentation, is accessible to any host on the network. GDF's EtherNet/IP and CIP testing covers:

• CIP command injection to demonstrate unauthorized read and write access to PLC I/O data, control tags, and process parameters via native CIP service requests
• Unauthorized PLC programming by attempting to download modified ladder logic or function block programs to target PLCs using native CIP programming commands, demonstrating the full control impact available to an adversary with network access
• Device enumeration using CIP list identity services to characterize the device population without specialized scanning tools

PROFINET

PROFINET is used in Siemens and other European-manufactured automation systems. Its Device Configuration Protocol (DCP) operates at Layer 2 and is not subject to IP-level access controls. GDF's PROFINET testing covers:

• DCP enumeration to identify PROFINET devices on the network and collect device configuration details including device names, IP addresses, and device types
• Device manipulation using DCP services to demonstrate whether device configuration can be altered by an adversary with Layer 2 network access
• PROFINET IO traffic analysis to characterize process data flows and identify opportunities for unauthorized access to process variable data

BACnet

BACnet is the primary protocol for building automation and control systems, including HVAC, lighting, access control, and fire suppression systems. As building systems have been connected to enterprise networks, BACnet's lack of authentication has become a significant exposure. GDF's BACnet testing covers:

• Unauthenticated property read access to enumerate building system devices and read process variable values including setpoints, occupancy data, and alarm states
• Unauthenticated property write access to demonstrate unauthorized modification of building system parameters such as temperature setpoints, damper positions, and lighting control states
• BACnet Who-Is and I-Am service exploitation for device enumeration without authentication

IEC 61850 and GOOSE

IEC 61850 is the standard communication protocol for substation automation and protection relay coordination in electric power systems. GOOSE (Generic Object Oriented Substation Event) messages carry protection relay tripping commands that operate in sub-millisecond timeframes. IEC 61850 and GOOSE testing is accordingly the most safety-sensitive work in GDF's protocol portfolio.

GOOSE message spoofing causes immediate relay operation in live substations. A spoofed GOOSE trip command sent to a live protection relay will cause the relay to operate and may de-energize power system equipment. For this reason, IEC 61850 and GOOSE testing is conducted exclusively in isolated laboratory environments with hardware relay test sets, never on or near live substation equipment. Within isolated environments, GDF's testing demonstrates:

• GOOSE message spoofing to characterize the ability of an adversary with Layer 2 network access to inject unauthorized GOOSE frames that trigger protection relay operation
• GOOSE replay attacks to demonstrate that captured relay coordination messages can be retransmitted to trigger relay operations outside scheduled test windows
• Sampled Values (SV) manipulation for environments using IEC 61850-9-2 process bus architectures

Safe Testing Environments

GDF uses three safe environment methodologies for ICS penetration testing, selected based on the client's available resources, the specific assets under test, and the type of exploitation scenarios to be executed. In many engagements, GDF uses a combination of these approaches, matching the most appropriate methodology to each portion of the test.

Digital Twin

Digital twin testing creates a software simulation of the target ICS environment that accurately replicates the production network topology, protocol configuration, PLC logic, and HMI setup. The test team executes the full attack chain against this virtual replica, including destructive exploitation scenarios that would be unsafe to execute against live equipment.

• Full attack surface replication: The digital twin is configured to reflect the actual production environment, including the specific firmware versions, communication paths, and process parameters observed during the passive discovery phase. Vulnerabilities exploited in the twin are documented with technical specificity sufficient to confirm exploitability against the production system.
• Destructive testing capability: Scenarios that would carry unacceptable operational risk on live systems, such as unauthorized PLC logic downloads, process setpoint modification outside safe operating ranges, or safety system bypass attempts, can be executed in the digital twin environment without operational consequence.
• Multiple scenario iterations: Digital twin testing allows the same scenario to be run repeatedly with different parameters, testing variations in attacker capabilities or network positioning, without scheduling production downtime for each iteration.
• Architecture change validation: Proposed security architecture changes, such as new network segmentation or updated firewall rules, can be modeled in the digital twin and tested before deployment in the production environment.

Hardware-in-the-Loop (HIL)

Hardware-in-the-loop testing places physical ICS hardware, including PLCs, RTUs, and HMIs, in an isolated laboratory environment with simulated process signals replacing the physical field connections. This approach provides the highest fidelity available short of testing on live production equipment.

• Physical hardware fidelity: HIL testing uses actual device firmware rather than software emulation. Protocol-specific exploitation techniques are executed against real device firmware, producing findings that accurately characterize the production device's actual vulnerability rather than a simulated approximation.
• Safety system testing capability: HIL is the preferred methodology for testing safety instrumented systems and protection relays, where firmware behavior differences between physical hardware and simulation could affect the accuracy of findings. Physical hardware in an isolated environment provides the necessary fidelity without operational risk.
• Simulated process signals: Process simulation software provides realistic input signals to the physical hardware, allowing the test team to execute scenarios that require the target device to be processing actual control data rather than sitting in an inactive state.
• Spare hardware utilization: Organizations with spare hardware from maintenance stock or decommissioned equipment can contribute this hardware to GDF's HIL configuration at reduced cost, as the spare hardware eliminates the need to procure duplicate equipment specifically for the engagement.

Isolated Test Network

Isolated test network testing uses decommissioned production equipment or identical spare hardware reassembled in a secure, isolated laboratory environment that replicates the production network architecture. This approach provides a good balance of testing fidelity and cost.

• Production equipment replication: Decommissioned equipment retains the same firmware, configuration, and hardware characteristics as its production counterparts. Testing against this equipment produces findings that are directly applicable to the production environment without the expense of procuring new hardware.
• Full network architecture reconstruction: The isolated test network replicates the relevant portions of the production network architecture, including firewall configurations, segmentation boundaries, jump server configurations, and the IT/OT junction architecture. This allows IT/OT boundary traversal testing and lateral movement scenarios to be executed with realistic network conditions.
• Cost-effectiveness: Isolated test networks represent the most cost-effective HIL option for organizations with available decommissioned hardware. The primary investment is in the time required to rebuild the environment and validate that it accurately reflects the production system.

IT/OT Boundary Penetration Testing

The boundary between IT and OT networks is the most frequently exploited attack path in ICS security incidents. Research by TXOne Networks found that 96% of OT security incidents originate from IT-level compromises, not from direct attacks against OT network assets. Adversaries establish access on the corporate enterprise network, then move laterally through inadequately segmented DMZ zones, vendor remote access channels, and engineering workstations that bridge both networks to reach the control network. By the time an adversary is executing commands against a PLC, the initial compromise typically occurred weeks or months earlier on an endpoint that was never considered part of the critical infrastructure security perimeter.

GDF's IT/OT boundary penetration testing explicitly models this attack path. Starting from an assumed-breach position on the enterprise network, the test team attempts to traverse the IT/OT boundary and reach OT network assets. This approach tests the controls that matter most to real ICS security risk, and frequently identifies paths from corporate networks to safety-critical OT assets that the organization's security architecture was intended to prevent.

GDF's standard IT penetration testing services cover the enterprise network side of this equation. The IT/OT boundary test connects the enterprise IT findings to the OT network impact, demonstrating whether vulnerabilities on the IT side can be chained with OT boundary weaknesses to reach control system assets.

IT/OT boundary testing covers:

• Firewall rule validation: Testing whether firewall rules as documented in policy are actually enforced by the deployed firewall configuration. Firewall rule sets accumulate over time; rules added for temporary operational needs are frequently never removed. GDF's testers validate each rule category against the actual firewall behavior, identifying rules that permit traffic the security architecture was intended to block.
• DMZ architecture testing: Verifying that DMZ hosts serving as data exchange points between IT and OT networks cannot be used as pivot points to reach the OT network directly. Historian servers, data diodes, and OPC gateways in DMZ architectures are common pivot targets if not correctly configured.
• Jump server security testing: Assessing whether administrative access to OT systems through jump servers is adequately controlled. Jump server testing covers authentication controls, session isolation, clipboard and file transfer restrictions, session recording, and whether the jump server itself can be used as a lateral movement vector to OT assets.
• Vendor remote access testing: Examining the security of persistent or on-demand remote access channels established by equipment vendors. Vendor remote access is among the most common initial access vectors in OT incidents, particularly when vendor accounts use shared credentials, lack multi-factor authentication, or maintain persistent always-on connections to the OT network.
• Engineering workstation dual-homing: Identifying and testing engineering workstations that maintain network connections to both IT and OT environments. Dual-homed engineering workstations represent a direct IT-to-OT network path that bypasses all boundary security controls.

Physical Security Testing of ICS Facilities

Network-level security controls protect only the attack surface that is visible from the network. Physical access to ICS facilities creates attack paths that are entirely invisible in network architecture diagrams. The Stuxnet attack, the most sophisticated ICS malware documented to date, required a USB-based initial access path to cross the air gap at the Natanz uranium enrichment facility. Stuxnet did not defeat the network security controls protecting the facility; it bypassed them entirely through physical media. Industrial ransomware incidents have consistently originated from service technician laptops brought into OT environments for scheduled maintenance, and from portable devices used to transfer files between air-gapped networks.

Physical security testing of ICS facilities examines these vectors in coordination with facility security and operations staff. Testing covers:

• USB port access controls: Verifying whether device control policies prevent execution of unauthorized code or data transfer from removable media on engineering workstations and HMIs. Testing examines both technical controls (USB device blocking policies, executable allow-listing) and physical controls (port blockers, physical case security).
• Physical access to network infrastructure: Testing whether an adversary with brief physical access to a control room or field panel location could attach a network device, extract credentials from an accessible engineering workstation, or obtain information sufficient to conduct a subsequent network-based attack.
• Control room access controls: Assessing the physical access control posture for control rooms, equipment rooms, and DCS and PLC cabinet locations. Review covers access logging, tailgating potential, and whether access logging is actively reviewed.
• Portable device policy enforcement: Assessing whether service technician and contractor devices are examined for malware and policy compliance before connecting to OT networks. This testing directly addresses the attack vector responsible for the majority of ransomware initial access events in industrial environments.
• Cellular modem and unauthorized wireless access points: Identifying cellular modems installed in field devices for ad-hoc remote access, and unauthorized wireless access points that bridge OT network segments to accessible wireless networks.

ICS Penetration Testing for Legal and Regulatory Purposes

Regulatory frameworks applicable to ICS environments increasingly require not just that security controls be in place, but that their effectiveness be demonstrated through active testing. ICS penetration testing documentation produced by GDF is structured from the outset to satisfy these requirements, making regulatory compliance documentation a byproduct of the security engagement rather than a separate documentation effort.

NERC CIP Compliance

NERC CIP-010 requires registered entities subject to the North American Electric Reliability Corporation Critical Infrastructure Protection standards to complete an annual cybersecurity assessment plan. This plan must include active assessment of BES Cyber Systems across all required NERC CIP asset categories. Engagements for electric utilities are structured to produce findings and documentation that map directly to CIP-010 assessment requirements, CIP-005 Electronic Security Perimeter controls, and CIP-007 System Security Management requirements. NERC's 2026 CIP Roadmap identified supply chain security, ransomware, and IT/OT segmentation as the top risk priorities for regulated utilities, areas that GDF's methodology addresses directly.

TSA Pipeline Security Directives

TSA Security Directive SD Pipeline-2021-02F, effective May 2025, requires pipeline operators to submit annual Cybersecurity Assessment Plans to TSA and to assess 100% of Critical Infrastructure Protection elements every three years, with 30% assessed annually. GDF's assessment methodology and reporting structure align to these requirements, producing documentation suitable for TSA submission and audit review.

IEC 62443

IEC 62443 defines security levels (SL1 through SL4) and foundational requirements (FR1 through FR7) for industrial automation and control system security. Active penetration testing provides evidence of the security level achieved in practice against the level specified in design documentation. GDF's findings map to the relevant IEC 62443-3-3 system requirements, supporting certification programs and self-assessment reporting under this standard.

NIST SP 800-82 Rev. 3

NIST Special Publication 800-82 Revision 3, published September 2023, provides updated guidance for OT security programs. The revision aligns to NIST CSF 2.0, expands coverage to cloud-connected OT and IIoT architectures, and incorporates lessons from post-2015 ICS-specific malware including TRITON/TRISIS, INDUSTROYER2, and PIPEDREAM/INCONTROLLER. GDF's penetration testing findings are documented with references to applicable NIST SP 800-82 Rev. 3 guidance and the OT overlay for NIST SP 800-53 Rev. 5 controls.

Court-Admissible Documentation and Expert Witness Testimony

Documentation produced throughout the engagement maintains evidentiary integrity. Chain of custody documentation for digital evidence collected during testing, detailed testing logs with timestamped actions, and reproducible finding documentation support the use of GDF's analysis in legal proceedings where the security posture of an ICS installation is at issue. GDF's analysts provide expert witness testimony in litigation involving ICS security, vendor liability disputes, and regulatory enforcement matters. For post-incident forensic analysis of ICS environments, see GDF's SCADA Security Testing service page.