Lateral Movement from IT to OT: Industrial Network Pentest Techniques

Depov

Activist
ULTIMATE
SUPREME
PREMIUM
MEMBER
Joined
Feb 18, 2025
Messages
126
Reaction score
116
Deposit
0$
At the audit of the energy enterprise, we received domain admin in four hours - Kerberoasting plus a weak password for service earnings AD. Standard story, nothing interesting. But between the enterprise network and the SCADA segment there was a firewall that only passed the Modbus TCP to the port 502 and HTTPS on 443 historians for data. Pass-the-Hash is useless, RDP is locked, SSH is missing. The whole classic set of lateral movement techniques that work perfectly inside the IT domain, on the border with the OT segment turned into a dead load.

And here begins a real pentest of industrial networks - at the junction of the corporate domain and industrial controllers, where the rules are completely different.
The business logic of the attack: why the attacker goes to OT
The attacker, who gained control of the IT domain, goes to the OT segment not out of curiosity. Reasons specific: encryption of SCADA servers for maximum pressure at ransomware (starting production - hundreds of thousands of dollars per hour), sabotage of physical processes (case TRITON/TRISIS 2017XENOTIME Group attacked Schneider Electric Triconex’s anti-emergency protection systems at a petrochemical plant, or the creation of a long-term bridgehead in critical infrastructure (the Volt Typhoon group, according to CISA, sat in infrastructure for months without a single active action).

According to the IBM X-Force Threat Intelligence Index 2025, 70% of X-Force attacks targeted critical infrastructure. CrowdStrike in Global Threat Report 2025 captures the average time of the lateral movement after initial access - 62 minutes, the record is 51 seconds. For the OT environment, the output is direct: if the IT network is compromised, the defenders have critically little time before the attacker is on the border with the industrial segment.

Kill chain for IT->OT pivot:
1. Initial access - phishing, VPN operation, compromised contractor
2. AD compromise - Kerberoasting,NTLM relay, AS-REP.rosating
3. Lateral movement to engineering stations - jump hosts, shared credentials
4. Intersection of IT/OT-limits - via DMZ, dual-homed hosts, VPN hubs
5. Interaction with PLC/SCADA - reading and writing registers, modification of logic
Each step has its own techniques, limitations and detectance. Next, let’s look at them specifically, starting with why the usual tools break at the IT/OT boundary.
How the OT network differs from IT at the level of protective measures
If you have only worked with corporate networks, the OT segment will present several unpleasant surprises that directly affect the choice of tools and techniques in the pentest of industrial networks.

Protocols without authentication. Modbus TCP - a workhorse of industrial communications - does not have built-in authentication at all. Any host capable of sending a TCP packet to port 502, can read and write PLC registers. Function codes are divided into reading: FC1 (Read Coils), FC2 (Read Discrete Inputs), FC4 (Read Input Registers) - and a record: FC5 (Write Single Coil), FC6 (Write Single Register), FC15 (Write Multiple Coils), FC16 (Write Multiple Register). DNP3 has an optional Secure Authentication, but in practice it is deployed at a single percentage of installations. The UA OPC supports encryption and certificates, but is often configured to be None/None mode for fittings. According to the documents, a secure protocol. In practice, naked as a socket.

Legacy-systems. Engineering stations for Windows 7 or XP are not an anomaly, but everyday life cycle of equipment 20-30 years (Siemens S7-300, Allen-Bradley PLC-5). Installing an EDR agent to a station that manages the process is not a technical issue, but an organizational one: the vendor can cancel the guarantee. CrowdStrike Falcon or SentinelOne on HMI panel under Windows XP Embedded - forget.

The Purdue model. The architecture is built by Purdue Reference Model: Level 0 (physical processes, sensors, actuators) -> Level 1 (PLC, RTU) -> Level 2 (SCADA-servers, HMI) -> Level 3 (MES,) -herist <or Level 3.5 (DMZ) -> Level 4-5 (corporate IT). Your task with SCADA pentest is to pass from Level 4-5 to Level 2 or even Level 1. Each transition is a separate task with separate restrictions.

Monitoring. Corporate SIEM (Splunk, Elastic, MaxPatrol SIEM) in OT are blind: they do not disassemble Modbus or DNP3 at the level of function codes. Specialized OT-IDS - Claroty, Dragos Platform, Nozomi Guardian - work differently: build a baseline of normal industrial traffic and detect anomalies. A new IP that accesses PLC, atypical function code, changing the frequency of the survey - all this is an alter. That is why the usual tactic “threw the Cobalt Strike and went for a walk” here will not ride.
Recon at the border IT/OT: fingerprinting industrial segment
[Applicable: Inland Pentest, Grey Box - Access to IT Segment Received]
Adjustments to the environment
• Kali Linux 2024.x or Parrot OS
• Nmap 7.94+ (modbus-discover, s7-info are included in standard delivery)
• Wireshark or tcpdump for passive grip
• RAM: from 4 GB, recommended 8 GB
• Connection to IT segment with RO cancellation to OT DMZ
Step 1: Passive Collection. Start with traffic capture - Network Sniffing (T1040, Credential Access / Discovery) When accessing the span port of a switch in DMZ or at the IT/OT border, run tcpdump -i eth0 -w capture.pcap 'port 502 or port 102 or port 44818 or port 20000'. Even without a span-port of the ARP-table on the compromised host will show which IP from the OT-subnett communicate with IT servers: data hangers, antivirus servers, WSUS. Quiet, without a single package sent.

Step 2: careful active scanning. Network Service Discovery (T1046, Discovery) - only after consultation with the customer. PLC with processors of the 1990's can go into fault from an aggressive SYN scan. There was a case on one audit: colleagues from another company put the Allen-Bradley SLC 500 PLCs as usual nmap -T4. The controller went to hard fault, the process stood up for two hours.
Bash:
nmap -sT -Pn -p 502,102,20000,44818 \
--script modbus-discover,s7-info \
--scan-delay 500ms -oA ot_recon 10.10.20.0/24
Ports: 502 (Modbus TCP), 102 (S7comm - Siemens), 20000 (DNP3), 44818 (EtherNet/IP - Allen-Bradley/Rockwell). Flag --scan-delay 500ms - not a recommendation, but a requirement: without it, you risk causing equipment failure. Script s7-info returns the PLC model, the firmware version, the name of the project - is enough to select exploits and understand the appointment of the controller.

Step 3: Search for dual-homed hosts. Machines with two interfaces - one in IT, the other in OT - your main priority. These are engineering stations, data stories, jump servers. In AD they are visible through DNS records with two A-records or through netstat -rn on compromised hosts. Each dual-homed host is a ready-made bridge for the lateral movement OT. Found this - count, half the battle is done.
Lateral movement via IT/OT-border: vector selection

1781214181044.png

Shared credentials - the most frequent vector
Valid Accounts (T1078, Initial Access / Persistence / Privlege Escalation) it works in the vast majority of OT audits. The reason is banal: SCADA-soft service records (WinCC, FactoryTalk, Citect) are created in AD with passwords that have not changed for years. Local administrator accounting at engineering stations - often with the same password on all cars; LAPS in the OT segment I have never met.

Grey Box: if the customer has issued the ACTED data of the SCADA operator, first of all the found OT-segment hosts. One password often works for HMI, an engineering station and a VPN contractor. Classic genre.

Limitation: if the OT segment is isolated from AD (separate workgroup), domain accounting is useless. Then look for local credentials via LSASS dump on dual-homed hosts or in SCADA hardware configuration files - many store passwords in plaintext or with reversible encryption. WinCC, for example, has historically sinned.
Pass the Hash at the Border
Pass the Hash (T15500.002, Lateralal Movement) applicable if the engineering stations are included in the general AD domain with NTLM-authentication.

Works if: Engineering Station - a member of AD domain, NTLM enabled, SMB/RPC is available via firewall between zones.

Does not work if: The OT segment in a separate workgroup without domain trust is allowed on the firewall only, Modbus TCP (port 502) is allowed, or on engineering worktation, Windows Defender Credential Guard is activated (which is rarely available in OT but is found on the latest Siemens TIA Portal installations under Windows 10/11).
Protocol Tunneling through permitted ports
When the firewall at the IT/OT border passes only specific ports (502, 443), Protocol Tunneling (T1572, Command and Control) - the main way to get full access to OT. Compromise the dual-homed host (historian, jump server) through the IT interface, deploy the tunnel and get access to the OT subnet.

Chisel (GitHub - jpillora/chisel: A fast TCP/UDP tunnel over HTTP, actively supported) throws SOCKS-proxy through HTTPS - merges with legitimate horror traffic. Ligolo-ng is an alternative to a TUN interface for a more transparent pivoting. In practice, I prefer Chisel: the binary is small, adjusts in a minute, in traffic it looks like a regular HTTPS.

Limitation: if an DPI is at the border, sharpened on industrial protocols, tunneling of arbitrary traffic through port 502 will be noticed. The Modbus package has a rigid MBAP header structure (7 bytes: Transaction ID, Protocol ID, Length, Unit ID), and DPI will distinguish it from encapsulated HTTP/SOCKS. After 443 chances are higher - HTTPS is HTTPS.
Exploitation of Remote Services in DMZ
Exploitation of Remote Services (T1210, Lateral Movement) is aimed at services in DMZ: data stories (OSIsoft PI, Aveva Historian), WSUS servers, antivirus servers. These systems often run under Windows Server with known vulnerabilities and have network access in both directions.

Applicable to: internal pentest, grey box, found unstoppable in the DMZ. Historian is the perfect goal: it is connected to the IT network for data transmission to BI and at the same time collects tags from OT via OPC or Modbus. Two interfaces, one unstucky Windows Server - what can go wrong?
Working with industrial protocols: from registers to understanding the process
After receiving network access to the OT segment - through the pyvot or compromised engineering station - the specifics of the SCADA penccupation begin. Metasploit contains modules for industrial protocols. Reading Modbus-registers:
Code:
use auxiliary/scanner/scada/modbusclient
set RHOST 10.10.20.100
set DATA_ADDRESS 0
set ACTION READ_HOLDING_REGISTERS
set NUMBER 10
run
The module sends FC3 (Read Holding Registers) and returns the check-in values from the address 0 to 9. By the values, you can determine the current state of the process: temperature, pressure, position of the valves - depends on the configuration of a particular PLC and the binding of tags. Without documentation for the project (and it usually does not exist) - you will have to guess the values. Does the register show 350? It can be a temperature of °C, the pressure in the kPa or the recipe number.

Entry in registers (FC6, FC16) - action with physical consequences. On a real pentest, the entry in the PLC is performed strictly with the express agreement with the customer and in the presence of an operator capable of transferring the process into manual mode. The difference between “read the register” and “wrote the register” is the difference between the display of access and the potential shutdown of the turbine.

Additional tools: PLCScan (Python, detection and fingerprinting PLC - the project has not been updated actively from 2018-2019, use with an understanding of limitations) and Redpoint NSE scripts for Nmap. For Siemens S7 script s7-info returns the CPU model, serial number and project name - information sufficient to assess the criticality of the controller.
Evasion and OPSEC for OT-net rate
Specialized OT monitoring platforms don’t work like a corporate SOC. Dragos Platform and Claroty use DPI for industrial protocols and dismantle Modbus to a function code plus register address. The Nozomi Guardian builds a network interaction graph and profiles every device. Deceive them is more difficult than corporate SIEM.

What is guaranteed will cause an alterth:
• The appearance of a new IP that communicates with PLC (your Kali or pivot host, missing in baseline)
• Modbus recording teams (FC5, FC6, FC15, FC16) from the host that used to read
• Scanning ports - even slow, with --scan-delay
• S7comm-functions Stop CPU or Download Block
• Any change in the controller configuration
How to minimize detection:
• Passive traffic capture is invisible to OT-IDS - start with it
• For active reconnaissance, use an IP compromised engineering station, not your own
• Limit the read-only to operations (FC1, FC3) - they are not distinguished against the background of a regular SCADA survey
• Scan during process windows when traffic is higher than usual
• Let the tunnel through the legitimate, historian whose traffic is already in baseline
When stealth doesn't help: if the object is deployed by Dragos or Claroty with a configured asset and you use inventory to communicate with PLC - analt is inevitable. The only way is to work through a legitimate engineering station that normally addresses the right controllers. There is no other way.
 
Top Bottom