How Attackers Cross the IT-OT Boundary: Techniques and Detection Signals

Why the IT-OT boundary is the critical point

In nearly every industrial cybersecurity incident documented with enough technical detail, there is a precise moment that separates an IT attack from an attack with real operational impact: the moment the attacker crosses the boundary between the corporate network and the OT network.

Before that moment, it is an IT incident like many others: credential compromise, malware on an endpoint, unauthorized access to a server. After it, the risk perimeter changes completely: the attacker has access to systems that control physical processes, machinery, and plants. The potential for damage rises in a discontinuous step.

This boundary exists in most manufacturing organizations, but it is rarely impenetrable. It exists for historical reasons (OT networks were separate before they became connected to corporate IT) and is maintained with varying degrees of rigor. The problem is that operational pressure, namely the need for remote monitoring, data transfer to ERP systems, and vendor access for maintenance, continuously creates openings in this boundary, many of which are legitimate but not adequately monitored.

Technique 1: abuse of jump servers and historians

The most common path into the OT network does not go through a vulnerability in industrial firewalls: it goes through the systems that, by design, have a foot in both networks.

Historians are databases that collect process data from the OT network and make it available for analysis and reporting on the IT side. Systems such as OSIsoft PI, GE Historian, and similar are designed to straddle the boundary: they have connections to the OPC-UA servers of the control network and interfaces that can be queried from the IT network. An attacker who compromises the historian often gains the ability to query process values directly, but in some cases also to write toward the OT network, depending on how the bidirectional communication is configured.

Jump servers, or bastion hosts, are systems from which operators and technicians access OT assets in a controlled way. They are access aggregation points: whoever compromises the jump server gains the same visibility as all the users who connect to it. In poorly segmented environments, a jump server can have visibility over dozens or hundreds of OT assets with no further internal control mechanisms.

The typical attack pattern: compromise of an IT endpoint (phishing, application vulnerability), privilege escalation, search for credentials to jump servers or historians, access to the OT network through these systems.

Technique 2: tunneling over legitimate remote-access channels

Vendor remote-access channels are a critical and often underestimated vector. Almost all manufacturers of industrial machinery provide the ability to connect remotely to their systems for maintenance and diagnostics. These accesses typically occur through dedicated VPNs, proprietary software clients, or RDP/SSH connections to field devices.

The security problem is not the existence of these channels, since remote maintenance has real operational benefits, but how they are managed. Some frequent configurations that create risk:

• Credentials shared among multiple vendor technicians: if vendor A always uses the same credentials to access the customer's plant, and a technician takes them outside the company, the access is compromised without anyone knowing.
• Always-on connections: VPN tunnels to OT networks that remain open even when not needed, instead of being activated on request and monitored.
• Broader access than necessary: the technician of a PLC supplier is given a VPN connection that grants visibility over the entire control network, not just their own devices.
• No session logging: the remote technician's activity is not recorded, so it is impossible to reconstruct what they did.

An attacker who compromises a vendor technician's workstation, typically a system with a weaker security posture than the corporate standard, inherits all the remote-access channels configured on that system.

Technique 3: credentials shared between the IT network and the OT network

In many manufacturing organizations, especially those that have grown without any OT security planning, the credentials used on the IT network are the same ones used to access OT systems. An operator uses the same Windows password for both their office PC and the HMI terminal in production. A system administrator uses the same credentials for the IT servers and for the OT jump server.

This sharing turns any IT credential compromise into an automatic OT problem. A credential stuffing attack that obtains an operator's password might also work for the SCADA system, without the attacker having to do anything specific to the OT environment.

Separating credentials between the IT domain and OT systems is one of the security improvements with the best cost-benefit ratio available to industrial organizations, and one of the least implemented.

Detection signals in network traffic

Lateral movement between IT and OT, even when it happens through technically legitimate channels, leaves detectable traces in network traffic if you know what to look for.

Connections to OT subnets from IT systems that do not normally communicate with OT: in most production environments, only a limited and known subset of IT systems (the historian, specific interface servers, the jump servers) communicates with the OT network. A connection that starts from a user workstation or an IT application server toward an address in the OT subnet is anomalous and must be investigated.

Authentications outside normal hours or from unusual locations toward jump servers: jump servers have predictable access patterns: certain users, certain hours, certain source IPs. A successful authentication to an OT jump server at 3 a.m. from a previously unseen IP is a strong signal.

Internal scans from the OT network: if a device that normally communicates only with its reference PLC starts sending ARP requests to addresses it does not know, or attempts connections to unusual ports on other devices, it is probably performing discovery, which suggests that something unauthorized is moving in the network.

Variations in traffic volume to and from historians: a significant spike in the volume of data the historian transfers to the IT network, outside normal patterns, may indicate exfiltration of process data or improper use of the system as a relay.

First connections between previously silent host pairs: in mature OT environments, the communication matrix is stable. Every communication between a pair of addresses that have never communicated before deserves attention.

The role of passive monitoring in detecting the pivot

The advantage of passive network traffic monitoring for detecting IT-OT lateral movement is that it requires no changes to endpoints: no agents, no additional configuration on OT devices, no impact on running processes. You place a network sensor at a strategic point, typically near the firewall that separates IT and OT, and you observe all the traffic that crosses the boundary.

This approach has clear limits: it does not see what happens internally within a single device, it does not capture communications that occur entirely inside a subnet without crossing the sensor, and it cannot block traffic (it is passive by definition). But for detecting the IT-OT pivot, which by definition crosses the boundary where the sensor is placed, the coverage is direct.

The key is to have an accurate baseline of what is normal on that boundary, namely which systems communicate, on which ports, with what frequency, at what hours, so that you can detect the deviations that characterize lateral movement. This requires an initial observation period and a calibration process, but once the baseline is established, the anomalies emerge clearly from the curtain of legitimate traffic.

What to do after detection

Detecting the IT-OT pivot in progress poses an immediate operational problem: the OT environment is in production, and you cannot simply block all traffic to the control network without verifying the consequences.

The correct response is not the IT one, that is, isolate everything and then investigate. In OT the sequence is different: gather as much information as possible before acting, coordinate with the operations manager before touching anything that could affect the process, identify the scope of the compromise and the systems involved, and build a clear narrative of what happened and what risks happening.

Only with this visibility, and with explicit agreement between security and operations on how much risk you are willing to accept during the response, can you act effectively without causing operational damage in the attempt to contain an attack.

The MON5 angle

Detecting the IT-OT pivot requires exactly what this article describes: an accurate baseline of the boundary and a sensor that observes the traffic without touching it. The PROTECT phase of MON5 does this with passive, out-of-band NDR, which decodes native OT protocols (Modbus, Siemens S7, OPC UA, PROFINET, EtherNet/IP) and flags, through ML anomaly detection, the first connections between hosts that had never communicated, anomalous accesses to jump servers, and traffic spikes toward historians.

Before monitoring the boundary, however, you need to know where it actually runs. To map the contact points between IT and OT in your plant, you can start with an OT assessment.

Analysis and commentary by MON5 based on public-domain research and data from the OT/ICS sector.