T0830 Adversary-in-the-Middle: Detecting Traffic Interception on OT Protocols

Adversary-in-the-Middle (T0830) is an attacker placing themselves between two OT devices so they can read, block, change or inject the messages that run a process. Most legacy industrial protocols, including classic Modbus TCP and DNP3 without Secure Authentication, carry no message authentication, so a device has no way to tell a forged value or command from a real one. MITRE ATT&CK for ICS lists T0830 under the Collection tactic for Embedded, Windows, Linux and Network Devices platforms. This guide is for OT network engineers, control engineers and OT SOC analysts: what the technique enables in a control network, what ATT&CK records about real use, how its v20 analytics detect it, and which protocol and network controls make interception useless. For the enterprise version of the technique see the MITRE ATT&CK T1557 Adversary-in-the-Middle.

Key takeaways

• Interception is a means, not an end. ATT&CK lists AiTM as the enabler for blocking and spoofing reporting messages, sending unauthorised command messages and modifying parameters.
• ARP poisoning and proxies are the common routes. ATT&CK names both; on a flat Layer 2 control network, any compromised host can attempt the first.
• Protocol authenticity is the real fix. ATT&CK's Communication Authenticity mitigation (M0802) makes tampering detectable; segmentation and static ARP only shrink the opportunity.
• Detection depends on knowing the normal path. The v20 analytics alert on MAC address changes, redirect rules and path deviations that the documented communications profile does not explain.
• Operators need a second opinion. Out-of-band checks (M0810) let operators confirm what the HMI shows when the main channel may be compromised.

What T0830 covers in an OT network

ATT&CK for ICS describes T0830 as adversaries with privileged network access modifying network traffic in real time, intercepting traffic to or from a particular device. Once established, the adversary can block, log, modify or inject traffic. ATT&CK names Address Resolution Protocol (ARP) poisoning and the use of a proxy as the most common methods. In ATT&CK v20 the follow-on techniques it enables map as below (three of the IDs originally listed on the technique were revoked and replaced in v20).

T0830 differs from Network Sniffing (T0842), which only observes. In the middle, the adversary forwards traffic and can change it, so both ends keep working and nothing obviously breaks. That is what makes it dangerous in OT: the HMI can show a normal process while the process is not normal.

Why OT protocols are exposed

Classic Modbus TCP, DNP3 without Secure Authentication, IEC 60870-5-104 and many vendor protocols were designed for closed serial or LAN networks. They identify peers by address only, carry no cryptographic integrity check and accept a well-formed message from whoever sends it. The protocol-level protections that now exist are:

The OPC UA Security Model (OPC 10000-2) is a useful reference for the threat itself: it lists message spoofing, message alteration, message replay, message suppression, downgrade attack and network infrastructure attacks as separate threats, and notes that ARP spoofing on the network can enable eavesdropping, alteration, replay and suppression. A secure protocol only helps when it is enforced: a server that still accepts security mode None, or a DNP3 outstation that accepts unauthenticated critical requests, leaves the downgrade path open.

What ATT&CK records about real use

• VPNFilter (S1010): ATT&CK records that VPNFilter's ssler module configured a compromised device's iptables to redirect traffic destined for port 80 to a local service on port 8888, where requests could be inspected and manipulated before being passed on. The lesson for OT is that a compromised router or gateway is an ideal middle point, which is why the v20 network device analytic watches for NAT and routing changes.
• Triton Safety Instrumented System Attack (C0030): ATT&CK records that during this campaign TEMP.Veles changed phone numbers tied to specific accounts in a contact list and used them to redirect traffic, so they could capture login codes sent by text message. This is interception of an authentication channel rather than a control protocol, but it shows the same actor treating AiTM as a route to OT access.

ATT&CK lists no procedure example of AiTM against a control protocol in a named campaign.

Detection: ATT&CK v20 analytics

ATT&CK's detection strategy for T0830 (DET0764) has four analytics. All share an OT operational fidelity gate: alert only when the asset's documented role does not permit the connection and the destination, proxy or service is outside the approved communications profile, while suppressing approved vendor support, update repositories, remote operations, failover paths and documented temporary connectivity.

Two practical additions: alert on gratuitous ARP or duplicate IP to MAC bindings for controllers, HMIs and SCADA servers, and on certificate or key changes on secure protocol sessions that do not match a planned renewal. Both rely on an accurate asset inventory. See the OT Network Security Monitoring Guide.

Prevention: ATT&CK mitigations in practice

• M0802 Communication Authenticity: ATT&CK notes this makes tampered messages detectable but does not prevent eavesdropping. Turn on the secure variant of each protocol where devices support it, starting with links that carry commands.
• M0813 Software Process and Device Authentication: credentials should not cross the network in plaintext, and authentication should resist replay, for example with nonces, timestamps or challenge-response.
• M0814 Static Network Configuration: statically defined ARP entries prevent the spoofed ARP messages many AiTM methods rely on. Use them on small, stable segments such as a controller to HMI link, or use switch features that bind IP to MAC on access ports.
• M0930 Network Segmentation: isolate components that do not need broad network access, which limits where an adversary can sit.
• M0931 Network Intrusion Prevention: detect and block traffic patterns indicative of AiTM at the network level.
• M0942 Disable or Remove Feature or Program: disable legacy network protocols that can be used for AiTM where they are not needed.
• M0947 Audit: limit access to the network infrastructure that could be used to reshape traffic.
• M0810 Out-of-Band Communications Channel: use a separate channel, such as a local panel reading or a hardwired signal, to validate data from the primary channel for critical values.

Segmentation design is covered in the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

Where identity fits

Every secure OT protocol replaces "trust the address" with a machine identity: a TLS certificate for Modbus/TCP Security, update keys for DNP3 Secure Authentication, application instance certificates for OPC UA. These are non-human identities and they fail the same way as in IT: shared keys across sites, certificates that expire and get replaced by security mode None, and trust lists nobody owns. Give each device and application its own credential, record who issues and renews it, and alert when a peer presents a certificate you did not issue. See the Device and IoT Identity Guide.

How to implement

1. Inventory paths: record which devices talk to which, over which protocol, and the MAC and IP of each controller, HMI and SCADA server.
2. Turn on monitoring first: passive protocol-aware monitoring with alerts for ARP anomalies, MAC changes and unexpected talkers, tuned through a maintenance cycle.
3. Harden Layer 2 and the network devices: static ARP or switch IP to MAC binding on critical segments, locked-down management of switches and routers, and configuration change logging.
4. Enable secure protocol variants in a test environment with the vendor, checking latency and scan time impact, then on one link in production with the old configuration ready to restore.
5. Enforce: once both ends work securely, disable the insecure mode on that link so a downgrade fails rather than silently succeeding.
6. Add out-of-band checks for the few values whose falsification would matter most to safety or quality.

Decision guidance

• Devices that support a secure protocol: use it and enforce it; this is the only control that stops in-transit tampering being silent.
• Legacy devices that cannot: combine small segments, static ARP or port security, protocol-aware monitoring and out-of-band validation, and plan replacement.
• Wide-area links (substations, pump stations): protect the path with encrypted tunnels between sites, and still authenticate messages end to end where the protocol allows.
• Small sites: segmentation and static configuration on a handful of devices gives most of the benefit without new tooling.

Responding to suspected AiTM

Treat a confirmed MAC change on a controller or an unexplained redirect rule as a possible loss of view. Start with operations: verify key process values through an independent reading before trusting the HMI. Preserve evidence before cleaning up: packet captures from the affected segment, switch ARP and MAC tables, network device configurations and the suspect host's process history. Remove the intercepting host or rule, then check whether any setpoints or controller values changed while the adversary was in place. See the OT Incident Response Guide.

Detection and measurement

• Secure protocol coverage: percentage of command-carrying links using an authenticated protocol variant, with insecure modes disabled.
• Layer 2 protection: percentage of critical segments with static ARP or IP to MAC binding.
• Inventory accuracy: percentage of controllers and HMIs whose MAC and IP are recorded and match observed traffic.
• Alert triage time: median time to explain an ARP or MAC change alert.
• Network device change control: percentage of NAT, route and ACL changes matched to an approved change.

Framework mapping

Common failure patterns

• Secure mode enabled but not enforced: devices still accept the insecure variant, so the adversary simply downgrades.
• Flat control networks: one compromised HMI or laptop can ARP poison every controller on the segment.
• Unmonitored network devices: routers and gateways in OT are rarely logged, yet they are the easiest place to redirect traffic.
• Asset inventory without MAC addresses: MAC change detection is impossible without a baseline.
• Trusting the HMI completely: no out-of-band check exists for values whose falsification would matter.

Practitioner checklist

• Map OT communication paths and record MAC and IP for every controller, HMI and SCADA server.
• Monitor ARP anomalies, MAC changes and unexpected talkers on control segments.
• Apply static ARP or IP to MAC binding on critical, stable segments.
• Log and change-control NAT, route and ACL changes on OT network devices.
• Enable authenticated protocol variants where supported, test, then disable insecure modes.
• Issue per-device certificates or keys and track their renewal.
• Define out-of-band validation for safety-relevant values.
• Preserve packet captures and switch tables as first evidence in any AiTM investigation.

Standards and references

• MITRE ATT&CK for ICS: Adversary-in-the-Middle (T0830)
• MITRE ATT&CK: VPNFilter (S1010)
• MITRE ATT&CK: Triton Safety Instrumented System Attack (C0030)
• OPC Foundation: OPC 10000-2, Security Model, security threats
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• NIST: SP 800-53 Rev. 5
• CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · Modbus TCP and Modbus Security Guide · DNP3 and DNP3 Secure Authentication Guide · MITRE ATT&CK T1557 Adversary-in-the-Middle · OT Network Security Monitoring Guide · MITRE ATT&CK for ICS T0842 Network Sniffing