Man-In-The-Middle

What is a Man-in-the-Middle (MitM) attack?

A Man-in-the-Middle (MitM) attack is an attack in which an adversary covertly places themselves between two communicating parties in order to eavesdrop on, alter, block or add to their traffic, while both parties believe they are talking to each other directly. MITRE now calls this Adversary-in-the-Middle (AiTM). In OT environments it is a critical risk for traffic between PLCs, HMIs, SCADA and field devices, because classic protocols such as Modbus, DNP3 and OPC Classic send messages without authentication or integrity checks.

🧠 How does a MitM attack work?

A MitM attack almost always runs in three phases:

1. Gaining position - the attacker makes sure traffic flows through their own system. On a local network this is usually done with ARP poisoning: forged, unsolicited ARP replies bind the IP address of the PLC or gateway to the attacker’s MAC address.
2. Forwarding - intercepted traffic is passed on, so the connection keeps working and nobody notices.
3. Exploiting - the attacker listens passively (passwords, process data, configurations) or intervenes actively: changing measured values, suppressing alarms, inserting their own commands or replaying old messages.

Without encryption, message authentication and network monitoring, such an attack is practically invisible from the endpoints.

🔧 Which techniques do attackers use to get in the middle?

MITRE ATT&CK for ICS describes this behaviour as technique T0830 Adversary-in-the-Middle under the Collection tactic. Its documented procedure examples include the TRITON campaign, in which the attackers changed phone numbers in a contact list to capture login codes sent by text message. In the Enterprise matrix (T1557), ARP Cache Poisoning, DHCP Spoofing and Evil Twin are separate sub-techniques.

🏭 Why is MitM especially dangerous in OT?

In IT, a MitM attack is usually about stolen data. In OT, the attacker can influence the physical process and hide what is happening at the same time. A few characteristics of industrial networks make this possible:

• No built-in security in classic protocols - a Modbus device executes any valid request, regardless of who sends it.
• Flat networks - HMIs, PLCs and engineering workstations often share one broadcast domain, where ARP spoofing works directly.
• Long lifecycles - controllers run for twenty years or more and often do not support TLS or certificates.
• Trust in the screen - operators act on what the HMI shows. Whoever falsifies the values effectively steers the operator.

Stuxnet is the best-known example of this principle. The worm hooked the communication library s7otbxdx.dll that sits between Siemens engineering software and the PLC. This let it hide modified PLC code, while a man-in-the-middle routine fed back normal-looking process data, so operators saw nothing of the centrifuges being driven to 1,410 Hz and down to 2 Hz instead of their normal 1,064 Hz.

🔐 Which OT protocols are vulnerable, and which secure variants exist?

Note that secure variants exist but are still rarely used in existing installations. DNP3 Secure Authentication also only protects against tampering and forgery, not against eavesdropping, because it encrypts nothing.

🛡️ How do you prevent and detect a MitM attack?

MITRE also lists static ARP entries, disabling unnecessary legacy protocols and an out-of-band channel for checking critical values by a second route. Where a legacy controller cannot support authentication, MITRE recommends a bump-in-the-wire device or VPN gateway that provides the protection on the device’s behalf. In IEC 62443-3-3, protection against MitM falls mainly under SR 3.1 Communication integrity and SR 4.1 Information confidentiality.

🧭 How do you tackle MitM risks step by step?

1. Map the communication flows - which HMI talks to which PLC, over which protocol and port? Passive monitoring produces this list without touching the process.
2. Identify the critical paths - write traffic to controllers and connections from the engineering workstation have the highest priority.
3. Harden the layer 2 environment - enable DHCP Snooping and Dynamic ARP Inspection on managed switches, disable unused ports and, where possible, use static ARP entries for fixed OT devices.
4. Segment - separate zones and conduits per IEC 62443 and only allow the protocols you need.
5. Enable secure protocol variants - for example OPC UA SignAndEncrypt, Modbus/TCP Security or DNP3 SAv5, and never disable certificate validation “to get it working”.
6. Detect - have an OT IDS alert on ARP anomalies, new devices and unexpected write commands.
7. Secure remote access - with a VPN, MFA and a jump server, so vendor connections cannot be intercepted or hijacked.

For Dutch organisations covered by the Cybersecurity Act, the Dutch implementation of NIS2 in force since 15 August 2026, these measures are part of the duty of care to secure network and information systems appropriately. NIST SP 800-82 Rev. 3 (September 2023) gives comparable recommendations for OT.

🔁 How does MitM relate to similar attacks?

❓ Frequently asked questions

What is the difference between man-in-the-middle and adversary-in-the-middle?

Man-in-the-middle and adversary-in-the-middle describe the same attack: an attacker sits between two parties and can read and alter their traffic. MITRE ATT&CK uses the more neutral term adversary-in-the-middle (AiTM). In practice both names are used interchangeably.

Does TLS always protect against a man-in-the-middle attack?

TLS only protects against a man-in-the-middle attack if the other party’s certificate is actually validated. If a client accepts any certificate, or validation has been switched off, an attacker can present their own certificate and still intercept the encrypted traffic. Sound certificate management is therefore just as important as the encryption itself.

How do you recognise a man-in-the-middle attack on an OT network?

A man-in-the-middle attack on an OT network shows up mainly as network anomalies: unsolicited ARP replies, an IP address that suddenly belongs to a different MAC address, or extra latency between HMI and PLC. An OT IDS that has learned the normal communication can alert on these. On the HMI itself, a well-executed attack is usually not visible.

Is Modbus vulnerable to man-in-the-middle attacks?

Classic Modbus is highly vulnerable to man-in-the-middle attacks because it has no encryption, authentication or integrity checking. An attacker in the path can read register values and alter write commands without the PLC noticing. Modbus/TCP Security with TLS on port 802 solves this, but device support is still limited.

Can a man-in-the-middle attack happen over Wi-Fi?

A man-in-the-middle attack over Wi-Fi is often carried out with an evil twin: a fake access point with the same network name to which tablets or laptops connect. From then on, all their traffic flows through the attacker. WPA3-Enterprise with 802.1X and certificate validation makes this much harder.

Does network segmentation help against man-in-the-middle attacks?

Network segmentation helps against man-in-the-middle attacks because an attacker first has to gain access to the same segment as the target devices. ARP spoofing only works within one broadcast domain, so small zones greatly limit its reach. Segmentation does not, however, replace encryption and message authentication on critical connections.

📌 In summary

A Man-in-the-Middle attack places an attacker invisibly between two parties, allowing them to eavesdrop on, alter or inject traffic. In OT this is especially dangerous because classic protocols such as Modbus and DNP3 have no authentication, and falsified values mislead the operator. Layer 2 protection, segmentation, secure protocol variants with validated certificates and an OT IDS make a MitM attack much harder and far more visible.