At the petrochemical facility in 2024, the task was specifically: to check whether the attacker from the corporate network will get to the PLC, which manages the refived convoy. After 14 hours, I read the hold-checks of the controller through the Modbus TCP - without a single alerte from the monitoring side. The path went through three DMZ jumps, one forgotten VPN-registering of the adjuster engineer and a lock with a password of three characters.
According to the IBM X-Force Thread Intelligence Index 2025, 70% of the recorded attacks in 2024 affected critical infrastructure. My experience confirms this: OT segments are the softest size of industrial enterprises. And the ICS pentest is the only way to prove it to the customer before the real incident. Not a report on 187-FZ, and a specific route to registers.
How the pentest OT-segment differs from IT at the level of tools and protection
The difference is not thesis “OT about accessibility, IT – about confidentiality”. For the penester, the key differences lie in three planes: protocols, detection and error price.
Protocols without authentication
Modbus TCP - de facto standard for industrial networks - does not provide authentication. Anyway. Any host that has reached the port of 502/TCP can send Function Code 03 (Read Holding Registers) or FC06 (Write Single Register) and receive a controller response. DNP3 in the basic configuration also does not encrypt traffic and does not require authorization: the Secure Authentication (SA) option exists, but on most of the objects where I worked, remains off. For comparison: even SMBv1 in the IT world implies identification. Industrial protocols were designed in an era of physical isolation, and authentication in them is an option, not a requirement.
Specific Function Codes Modbus, which is checked by the pentester when assessing the security of OT networks:
FC01 and FC03 - reconnaissance, mups on Network Service Discovery (T1046, Discovery) FC05, FC06, FC15, FC16 - impact: Transmitted Data Manipulation (T1565.002, impact) or Service Stop (T1489, Impact) On real testing for the penetration of industrial systems, we limit ourselves to Read-functions, and we demonstrate the possibility of recording in the report - without performing it on live equipment. Because the price of the error here is not a blue screen, but an emergency stop of the column.
Detecting: Claroty and Nozomi Networks instead of CrowdStrike
IT-SOC is accustomed to CrowdStrike Falcon, SentinelOne, Elastic 8.x with kernel ETW-TI. In OT networks, another zoo: Claroty (CTD / xDome), Nozomi Networks (Guardian / Vantage), Dragos Platform. They work differently - build baseline allowed communications between devices and generate an anomaly. The problem in the scale of baseline: thousands of tags with different refresh rates, and false positive is the daily reality. In practice, he met objects where Nozomi alleys are 80% ruled because of the noise. Standard IT-EDR on OT hosts are rare: engineering stations are rotated on Windows 7/10 LTSC without any agents, and an attempt to stick CrowdStrike on a SCADA server will cause panic among the shop engineer.
The conclusion for the pentester: evasion in the OT-network is built not on the bypass of EDR hooks, but on mimicry for legitimate traffic. If your Modbus query looks like a regular HMI survey cycle, Claroty won’t notice it.
Real incidents as a TTP benchmark
Sandworm (Industroyer2 - Energy Systems of Ukraine) and XENOTIME (TRITON / TRISIS - Safety Instrumented Systems petrochemical object) showed a full chain: adversary purposefully passes through the IT network, crosses DMZ, reaches the engineering stations and modifies the logic of controllers. According to frenos.io: "Real-world attacks by groups like Volt Typhoon, Sandworm, and XENOTOMIMES that SCADA systems are primary targets for cyberattacks"“Real attacks by factions such as Volt Typhoon, Sandworm and XENOTIME show that SCADA systems are the main targets of cyberattacks.”. The ICS pentest methodology reproduces this kill chain in controlled conditions - from initial access through the corporate network to demonstration of the impact at the process level.
Recon and fingerprinting OT perimeter
[Applicable: external pentest, black box]
Passive Intelligence
Shodan and Censys index industrial protocols. Request port:502 country:RU in Shodan returns Modbus-devices with Russian IP-addresses. More accurate filters: product:"Schneider Electric" or product:"Siemens" binding to ASN of the organization. In 30 minutes, OSINT intelligence is usually collected a list of externally available HMI, VPN gateways of engineers and forgotten web interfaces of SCADA servers. At one of the industrial cybersecurity projects, I found through the Shodan WinCC web panel with a default password – the object didn’t even know it was sticking out.
Active Scanning: Pivete Libertine or Dead PLC
Nmap (actively supported, regular releases) with a set of ICS scripts - the main tool fingerprinting. But aggressive scans kill the controllers: Siemens S7-300 (EOL, but widespread) is known for keeping with SYN-flood on non-standard ports. Put the controller - put the process. So the accuracy here is not politeness, but a necessity.
Limitation: Nmap NSE scripts for ICS cover only Modbus and S7comm. DNP3 and OPC UA need specialized tools - Metasploit modules or utilities from the ISF (Industrial Security Framework). ISF is an archival project (the last repository update around 2020), apply with caution and compatibility verification.
When the technique is NOT working: if the OT segment is really air-gapped (physically isolated, without a single IP route to the corporate network) - the external recon is useless. In reality, the full air gap is rare: in my experience, 9 out of 10 objects have at least one uncontrolled connectivity - a USB modem, a forgotten VPN tunnel, a history with a leg in both segments.
Initial access via DMZ: the path from IT to OT
In real projects, the audit of the ICS almost never begins from zero. The customer gives domain records, VPN access and formulates the task: "Show if you get to SCADA." The Grey box is a standard scenario, closer to the real threat model. According to the Verizon DBIR 2025, 38% of leaks are related to account theft, and 36% of incidents begin with phishing - adversary does not break the perimeter from scratch, but enters through a legitimate channel.
Purdue Model as an Attack Card
Purdue Model divides the infrastructure into levels - for a pentester this is a navigation card:
• Level 5–4 - Enterprise / IT (Corporate Network, Active Directory, mail)
• Level 3.5 - Industrial DMZ (historian, plast-server, jump-host)
• Level 3 - Site operations (SCADA-server, engineering worktation)
• Level 2 - Area Supery (HMI, Operating Stations)
• Level 1–0 – Basic control / Process (PLC, RTU, sensors, actuators)
The task is to pass from Level 5 to Level 1. Each transition is a verification of the IT OT network segmentation.
Typical chain
Step 1. Privilege escalation in AD (Level 5->4). Standard Techniques: Kerberoasting, AS-REP Roasting, DPAPI-dump. According to the Angara Security case, at a real industrial enterprise from low-privileged accounting to Domain Admin, reached “through the typical vulnerabilities of Microsoft Active Directory.” Default Accounts (T1078.001, Initial Access) - the first check: admin/admin, operator/operator, standard vendor passwords of controllers.
Step 2. Intelligence inside AD (Level 4). Looking for: file storage with network schemes (Agaria Security has discovered a “web server with analytical graphs for all segments of ACS TP”), accounts with access to DMZ, jump hosts to the OT segment. LDAP requests for groups containing SCADA, ICS, OT, MES - often give direct indications of target hosts. It's reconnaissance, not an attack - but it is it that determines the vector.
Step 3. Intersection DMZ (Level 4->3->3->3). Historian or jump host is a typical transition point. On many sites, historians are available from both segments: it needs data from SCADA and display them for corporate analysts. Exploit Public-Facting Application (T1190, Initial Access) - if a history has a web interface with a known vulnerability. Alternative: RDP via a jump host with intercepted credes. The security of the critical information infrastructure at this stage depends on one question: whether traffic is filtered between Level 4 and Level 3 by ports and protocols, or firewall is stored in a permit any mode. Spoiler: on most objects - any.
Step 4. Engineering workstation (Level 3->2). Exploitation of Remote Services (T1210, Lateral Movement) Engineering stations are often malnourished - AD records are not suitable. Angara Security described the working vector: “By circulating the data, it was possible to find those required to enter the target systems. The task made it easier to ensure that the local administrator used the same logins and passwords for multiple systems stored in the browser. DPAPI-dump from administrator workstations is the main source of credoers for malnourished hosts.
OPSEC: Why Aggression Kills Pentest
• Do not scan OT-subnets directly from the IT host. Any traffic from the IT host in OT is an anomaly for Claroty/Nozomi. Use pivoting through a compromised host in DMZ.
• Do not run credential dumping on OT hosts without approval. LSASS-dump on engineering worktation can hang the SCADA-client performance environment.
• Rate limiting. In OT-network packages are with a predictable frequency (HMI survey cycle: 500-2000 ms). Burst-traffic - instant alters. Keep payload at a speed indistinguishable from regular exchange.
• Do not install bacon/C2 on OT hosts. Outgoing traffic from the OT segment to the external IP is a red flag for any monitoring. Work through already captured IT hosts in DMZ.
Operation of industrial protocols: Modbus and not only
When you get to the network where the PLC lives, protocol work begins. It's different here - no NTLM hashes, no tokens. Naked registers and code functions.
Detection of devices via Metasploit
The Metasploit Framework (actively supported by Rapid7, regular updates) contains modules for ICS SCADA pentest:
Check-in-Charger reading and passive collection
Network Sniffing (T1040, Credential Access / Discovery) in OT - not only interception of passwords, but also passive collection of data of the process. Modbus traffic is transmitted in plain text: Wireshark with filter modbus will show all requests and responses between HMI and PLC. For active reading registers - Python scripts (library pymodbus) or GUI-tools like ModRSsim2.
Recording (write_register, write_coil) is demonstrated in the report as a theoretical possibility: on living equipment is performed only with the explicit permission of the process engineer and in the presence of a manual override on PLC. Because "I accidentally overwrote the pressure setup" - a phrase after which the career ends.
Impart Levels
• Transmitted Data Manipulation (T1565.002): a substitution of register values for operator misinformation - he sees normal readings, and the process goes beyond
• Service Stop (T1489): )recording of incorrect settings, leading to an emergency stop
• Component Firmware (T1542.002, Persistence/Defense )Evasion): Controller firmware modification is the most serious scenario implemented in the TRITON/TRISIS attack by XENOTIME
Other protocols
OPC UA (port 4840) is a more modern protocol with built-in encryption. But in practice, there are configurations with Security Policy = None (and are common). EtherNet/IP (port 44818), PROFINET, IEC 60870-5-104 - separate tools are needed for each. Universal Scanner of all OT-protocols does not exist: this is a limitation with which you will have to live and collect toys for a particular object.
Minilab for working out OT-pentest
Adjustments to the environment
• OS : Kali Linux 2024.x or Ubuntu 22.04+
• RAM : at least 8 GB (Kali + one VM simulator), recommended 16 GB for full stand
• Disk : 40 GB of free space
• Network : offline - all components local
• Software : VirtualBox 7.x or VMware, Metasploit 6.x, Nmap 7.9+, Wireshark, Python 3.10+ pymodbus
• Simulator : GRFICSv2 (Georgia Tech) - a virtual environment with OpenLC, ScadaBR HMI and simulation of the physical process
GRFICSv2 is deployed through VirtualBox: three VM (OpenpLC controller, HMI ScapaBR, flight station of the attacker). This stand is worked out a full chain: scanning, detection of Modbus devices, reading registers, recording demonstration - safe, on the virtual pressure management process in the reactor. The protocols are really felt when you see the response of the controller in Wireshark and can trace every FC03-request byte. Theory is one, and when the register returns 0x01F4 And you realize that it's 500 units of pressure - quite another.
According to the IBM X-Force Thread Intelligence Index 2025, 70% of the recorded attacks in 2024 affected critical infrastructure. My experience confirms this: OT segments are the softest size of industrial enterprises. And the ICS pentest is the only way to prove it to the customer before the real incident. Not a report on 187-FZ, and a specific route to registers.
How the pentest OT-segment differs from IT at the level of tools and protection
The difference is not thesis “OT about accessibility, IT – about confidentiality”. For the penester, the key differences lie in three planes: protocols, detection and error price.
Protocols without authentication
Modbus TCP - de facto standard for industrial networks - does not provide authentication. Anyway. Any host that has reached the port of 502/TCP can send Function Code 03 (Read Holding Registers) or FC06 (Write Single Register) and receive a controller response. DNP3 in the basic configuration also does not encrypt traffic and does not require authorization: the Secure Authentication (SA) option exists, but on most of the objects where I worked, remains off. For comparison: even SMBv1 in the IT world implies identification. Industrial protocols were designed in an era of physical isolation, and authentication in them is an option, not a requirement.
Specific Function Codes Modbus, which is checked by the pentester when assessing the security of OT networks:
FC01 and FC03 - reconnaissance, mups on Network Service Discovery (T1046, Discovery) FC05, FC06, FC15, FC16 - impact: Transmitted Data Manipulation (T1565.002, impact) or Service Stop (T1489, Impact) On real testing for the penetration of industrial systems, we limit ourselves to Read-functions, and we demonstrate the possibility of recording in the report - without performing it on live equipment. Because the price of the error here is not a blue screen, but an emergency stop of the column.
Detecting: Claroty and Nozomi Networks instead of CrowdStrike
IT-SOC is accustomed to CrowdStrike Falcon, SentinelOne, Elastic 8.x with kernel ETW-TI. In OT networks, another zoo: Claroty (CTD / xDome), Nozomi Networks (Guardian / Vantage), Dragos Platform. They work differently - build baseline allowed communications between devices and generate an anomaly. The problem in the scale of baseline: thousands of tags with different refresh rates, and false positive is the daily reality. In practice, he met objects where Nozomi alleys are 80% ruled because of the noise. Standard IT-EDR on OT hosts are rare: engineering stations are rotated on Windows 7/10 LTSC without any agents, and an attempt to stick CrowdStrike on a SCADA server will cause panic among the shop engineer.
The conclusion for the pentester: evasion in the OT-network is built not on the bypass of EDR hooks, but on mimicry for legitimate traffic. If your Modbus query looks like a regular HMI survey cycle, Claroty won’t notice it.
Real incidents as a TTP benchmark
Sandworm (Industroyer2 - Energy Systems of Ukraine) and XENOTIME (TRITON / TRISIS - Safety Instrumented Systems petrochemical object) showed a full chain: adversary purposefully passes through the IT network, crosses DMZ, reaches the engineering stations and modifies the logic of controllers. According to frenos.io: "Real-world attacks by groups like Volt Typhoon, Sandworm, and XENOTOMIMES that SCADA systems are primary targets for cyberattacks"“Real attacks by factions such as Volt Typhoon, Sandworm and XENOTIME show that SCADA systems are the main targets of cyberattacks.”. The ICS pentest methodology reproduces this kill chain in controlled conditions - from initial access through the corporate network to demonstration of the impact at the process level.
Recon and fingerprinting OT perimeter
[Applicable: external pentest, black box]
Passive Intelligence
Shodan and Censys index industrial protocols. Request port:502 country:RU in Shodan returns Modbus-devices with Russian IP-addresses. More accurate filters: product:"Schneider Electric" or product:"Siemens" binding to ASN of the organization. In 30 minutes, OSINT intelligence is usually collected a list of externally available HMI, VPN gateways of engineers and forgotten web interfaces of SCADA servers. At one of the industrial cybersecurity projects, I found through the Shodan WinCC web panel with a default password – the object didn’t even know it was sticking out.
Active Scanning: Pivete Libertine or Dead PLC
Nmap (actively supported, regular releases) with a set of ICS scripts - the main tool fingerprinting. But aggressive scans kill the controllers: Siemens S7-300 (EOL, but widespread) is known for keeping with SYN-flood on non-standard ports. Put the controller - put the process. So the accuracy here is not politeness, but a necessity.
Key flags: -sT instead of SYN-scan (full connecting more stable for PLC), -T2 (polite timing), --max-retries 1, --host-timeout 30s. Ports: 102 (S7comm/Siemens), 502 (Modbus TCP), 20000 (DNP3), 44818 (EtherNet/IP), 47808 (BACnet). Script modbus-discover sends FC17 (Report Slave ID) - a safe Reading Operation. Script s7-info reads the Siemens controller identification data without a record.
Limitation: Nmap NSE scripts for ICS cover only Modbus and S7comm. DNP3 and OPC UA need specialized tools - Metasploit modules or utilities from the ISF (Industrial Security Framework). ISF is an archival project (the last repository update around 2020), apply with caution and compatibility verification.
When the technique is NOT working: if the OT segment is really air-gapped (physically isolated, without a single IP route to the corporate network) - the external recon is useless. In reality, the full air gap is rare: in my experience, 9 out of 10 objects have at least one uncontrolled connectivity - a USB modem, a forgotten VPN tunnel, a history with a leg in both segments.
Initial access via DMZ: the path from IT to OT
In real projects, the audit of the ICS almost never begins from zero. The customer gives domain records, VPN access and formulates the task: "Show if you get to SCADA." The Grey box is a standard scenario, closer to the real threat model. According to the Verizon DBIR 2025, 38% of leaks are related to account theft, and 36% of incidents begin with phishing - adversary does not break the perimeter from scratch, but enters through a legitimate channel.
Purdue Model as an Attack Card
Purdue Model divides the infrastructure into levels - for a pentester this is a navigation card:
• Level 5–4 - Enterprise / IT (Corporate Network, Active Directory, mail)
• Level 3.5 - Industrial DMZ (historian, plast-server, jump-host)
• Level 3 - Site operations (SCADA-server, engineering worktation)
• Level 2 - Area Supery (HMI, Operating Stations)
• Level 1–0 – Basic control / Process (PLC, RTU, sensors, actuators)
The task is to pass from Level 5 to Level 1. Each transition is a verification of the IT OT network segmentation.
Typical chain
Step 1. Privilege escalation in AD (Level 5->4). Standard Techniques: Kerberoasting, AS-REP Roasting, DPAPI-dump. According to the Angara Security case, at a real industrial enterprise from low-privileged accounting to Domain Admin, reached “through the typical vulnerabilities of Microsoft Active Directory.” Default Accounts (T1078.001, Initial Access) - the first check: admin/admin, operator/operator, standard vendor passwords of controllers.
Step 2. Intelligence inside AD (Level 4). Looking for: file storage with network schemes (Agaria Security has discovered a “web server with analytical graphs for all segments of ACS TP”), accounts with access to DMZ, jump hosts to the OT segment. LDAP requests for groups containing SCADA, ICS, OT, MES - often give direct indications of target hosts. It's reconnaissance, not an attack - but it is it that determines the vector.
Step 3. Intersection DMZ (Level 4->3->3->3). Historian or jump host is a typical transition point. On many sites, historians are available from both segments: it needs data from SCADA and display them for corporate analysts. Exploit Public-Facting Application (T1190, Initial Access) - if a history has a web interface with a known vulnerability. Alternative: RDP via a jump host with intercepted credes. The security of the critical information infrastructure at this stage depends on one question: whether traffic is filtered between Level 4 and Level 3 by ports and protocols, or firewall is stored in a permit any mode. Spoiler: on most objects - any.
Step 4. Engineering workstation (Level 3->2). Exploitation of Remote Services (T1210, Lateral Movement) Engineering stations are often malnourished - AD records are not suitable. Angara Security described the working vector: “By circulating the data, it was possible to find those required to enter the target systems. The task made it easier to ensure that the local administrator used the same logins and passwords for multiple systems stored in the browser. DPAPI-dump from administrator workstations is the main source of credoers for malnourished hosts.
OPSEC: Why Aggression Kills Pentest
• Do not scan OT-subnets directly from the IT host. Any traffic from the IT host in OT is an anomaly for Claroty/Nozomi. Use pivoting through a compromised host in DMZ.
• Do not run credential dumping on OT hosts without approval. LSASS-dump on engineering worktation can hang the SCADA-client performance environment.
• Rate limiting. In OT-network packages are with a predictable frequency (HMI survey cycle: 500-2000 ms). Burst-traffic - instant alters. Keep payload at a speed indistinguishable from regular exchange.
• Do not install bacon/C2 on OT hosts. Outgoing traffic from the OT segment to the external IP is a red flag for any monitoring. Work through already captured IT hosts in DMZ.
Operation of industrial protocols: Modbus and not only
When you get to the network where the PLC lives, protocol work begins. It's different here - no NTLM hashes, no tokens. Naked registers and code functions.
Detection of devices via Metasploit
The Metasploit Framework (actively supported by Rapid7, regular updates) contains modules for ICS SCADA pentest:
Module modbusdetect sends FC17 (Report Slave ID) - read-only operation. THREADS 1 - critical: parallel requests to multiple PLCs simultaneously overload the network stack of the controller. Further auxiliary/scanner/scada/modbus_findunitid Determines Unit ID devices on each host.
Check-in-Charger reading and passive collection
Network Sniffing (T1040, Credential Access / Discovery) in OT - not only interception of passwords, but also passive collection of data of the process. Modbus traffic is transmitted in plain text: Wireshark with filter modbus will show all requests and responses between HMI and PLC. For active reading registers - Python scripts (library pymodbus) or GUI-tools like ModRSsim2.
Recording (write_register, write_coil) is demonstrated in the report as a theoretical possibility: on living equipment is performed only with the explicit permission of the process engineer and in the presence of a manual override on PLC. Because "I accidentally overwrote the pressure setup" - a phrase after which the career ends.
Impart Levels
• Transmitted Data Manipulation (T1565.002): a substitution of register values for operator misinformation - he sees normal readings, and the process goes beyond
• Service Stop (T1489): )recording of incorrect settings, leading to an emergency stop
• Component Firmware (T1542.002, Persistence/Defense )Evasion): Controller firmware modification is the most serious scenario implemented in the TRITON/TRISIS attack by XENOTIME
Other protocols
OPC UA (port 4840) is a more modern protocol with built-in encryption. But in practice, there are configurations with Security Policy = None (and are common). EtherNet/IP (port 44818), PROFINET, IEC 60870-5-104 - separate tools are needed for each. Universal Scanner of all OT-protocols does not exist: this is a limitation with which you will have to live and collect toys for a particular object.
Minilab for working out OT-pentest
Adjustments to the environment
• OS : Kali Linux 2024.x or Ubuntu 22.04+
• RAM : at least 8 GB (Kali + one VM simulator), recommended 16 GB for full stand
• Disk : 40 GB of free space
• Network : offline - all components local
• Software : VirtualBox 7.x or VMware, Metasploit 6.x, Nmap 7.9+, Wireshark, Python 3.10+ pymodbus
• Simulator : GRFICSv2 (Georgia Tech) - a virtual environment with OpenLC, ScadaBR HMI and simulation of the physical process
GRFICSv2 is deployed through VirtualBox: three VM (OpenpLC controller, HMI ScapaBR, flight station of the attacker). This stand is worked out a full chain: scanning, detection of Modbus devices, reading registers, recording demonstration - safe, on the virtual pressure management process in the reactor. The protocols are really felt when you see the response of the controller in Wireshark and can trace every FC03-request byte. Theory is one, and when the register returns 0x01F4 And you realize that it's 500 units of pressure - quite another.
