T0830: Adversary-in-the-Middle
Adversaries with privileged network access may seek to modify network traffic in real time using adversary-in-the-middle (AiTM) attacks. [1] This type of attack allows the adversary to intercept traffic to and/or from a particular device on the network. If a AiTM attack is established, then the adversary has the ability to block, log, modify, or inject traffic into the communication stream. There are several ways to accomplish this attack, but some of the most-common are Address Resolution Protocol (ARP) poisoning and the use of a proxy. [2]
An AiTM attack may allow an adversary to perform the following attacks: Block Reporting Message, Spoof Reporting Message, Modify Parameter, Unauthorized Command Message
Analyst context for executives and security teams
Adversary-in-the-Middle in ICS matters because a party with privileged network access can sit between control-system devices and alter what operators, controllers, historians, or gateways send and receive. In practical terms, this can undermine trust in operational data and commands: messages may be blocked, logged, modified, spoofed, or injected. For leaders, the issue is not just network confidentiality; it is whether critical process communications can be trusted during operations and incidents.
Executive priority
Prioritize this where ICS networks connect HMIs, workstations, control servers, PLCs, RTUs, IEDs, data historians, gateways, VPN servers, jump hosts, routers, switches, safety controllers, and field I/O. The business decision is whether critical operational paths have authenticated, integrity-protected communications and segmented access, or whether dynamic network behaviors such as ARP, DHCP, or DNS could be abused to redirect traffic. This technique should drive questions about operational resilience, incident response playbooks for data-integrity attacks, and audit evidence that critical communication paths are segmented, authenticated, and monitored without disrupting real-time control or safety functions.
Technical view
MITRE provides no official detection text for T0830, but a related ATT&CK detection strategy exists: DET0764, Detection of Adversary-in-the-Middle. SOC and IR teams should validate visibility across ICS communication paths rather than only endpoint logs. Focus on signs that traffic forwarding, addressing, or proxying has changed between critical assets, especially where ARP poisoning or proxy use could place an adversary between devices. Detection should be evaluated against relationship-driven follow-on behaviors named by MITRE: Block Reporting Message, Spoof Reporting Message, Modify Parameter, and Unauthorized Command Message.
Likely telemetry
- Packet capture or network sensor data from ICS segments and inter-segment boundaries
- ARP, DHCP, DNS, routing, switching, and gateway configuration/change evidence where available
- Network flow records showing unexpected intermediaries, proxies, or changed communication paths
- ICS protocol traffic between HMIs, control servers, PLCs, RTUs, IEDs, historians, gateways, and field devices
- Logs or alerts from network intrusion detection/prevention systems deployed at ICS boundaries
Detection direction
- Validate whether DET0764 or equivalent local analytics are mapped to the specific ICS network paths that matter most, not just the enterprise perimeter.
- Baseline normal device-to-device communications and investigate unexpected changes in source, destination, MAC/IP association, gateway, proxy, or protocol translation behavior.
- Tune carefully in control environments: network intrusion prevention is a listed mitigation, but MITRE notes it should be configured so it does not disrupt protocols and communications responsible for real-time control or safety.
- Look for correlated evidence of downstream effects, including blocked reporting, spoofed reporting, parameter modification, or unauthorized command messages.
- Account for blind spots where legacy embedded devices, unmanaged switches, protocol translators, or limited logging prevent direct endpoint evidence; compensate with passive network monitoring and architecture reviews.
Mitigation priorities
- Prioritize communication authenticity for critical paths: use secure network protocols that authenticate message senders and verify message integrity through MACs or digital signatures where supported.
- Require device and software-process authentication where appropriate, especially for remote connections and API access.
- Use network segmentation to isolate critical systems, functions, and resources; restrict access to only required systems and services, and prevent enterprise networks or other business functions from directly accessing critical process control systems.
- Use static network configuration where possible, recognizing MITRE’s caveat that this may be limited by device features or operational complexity.
- Maintain out-of-band communication methods for communication failures and data-integrity attacks.
Analyst notes and limits
This ATT&CK object is broad and asset-centric. The relationship context shows it can target many ICS assets, including operator workstations, HMIs, controllers, gateways, remote access infrastructure, and network devices. That breadth makes local architecture essential: the highest-risk paths are the ones carrying operational commands, telemetry, alarms, safety-related communications, or remote access into control environments.
MITRE does not specify tactics, platforms, or official detection guidance for this object, and the supplied fields do not identify active exploitation, attribution, or sector-specific prevalence. Any assessment of exposure or coverage requires local network diagrams, asset inventories, protocol details, segmentation rules, and available telemetry.
Adversary-in-the-Middle
Adversaries with privileged network access may seek to modify network traffic in real time using adversary-in-the-middle (AiTM) attacks. [1] This type of attack allows the adversary to intercept traffic to and/or from a particular device on the network. If a AiTM attack is established, then the adversary has the ability to block, log, modify, or inject traffic into the communication stream. There are several ways to accomplish this attack, but some of the most-common are Address Resolution Protocol (ARP) poisoning and the use of a proxy. [2]
An AiTM attack may allow an adversary to perform the following attacks: Block Reporting Message, Spoof Reporting Message, Modify Parameter, Unauthorized Command Message
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Groups, software, and campaigns
S1010: VPNFilter
VPNFilter is a multi-stage, modular platform with versatile capabilities to support both intelligence-collection and destructive cyber attack operations. VPNFilter modules such as its packet sniffer ('ps') can collect traffic that passes through an infected device, allowing the theft of website credentials and monitoring of Modbus SCADA protocols. [1] [2] VPNFilter was assessed to be replaced by Sandworm Team with Cyclops Blink starting in 2019.[3]
C0030: Triton Safety Instrumented System Attack
Triton Safety Instrumented System Attack was a campaign employed by TEMP.Veles which leveraged the Triton malware framework against a petrochemical organization.[1] The malware and techniques used within this campaign targeted specific Triconex Safety Controllers within the environment.[2] The incident was eventually discovered due to a safety trip that occurred as a result of an issue in the malware.[3]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 096e776e79dd… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Gabriel Sanchez October 2017
Gabriel Sanchez 2017, October Man-In-The-Middle Attack Against Modbus TCP Illustrated with Wireshark Retrieved. 2020/01/05
Open source URL -
[2]
Bonnie Zhu, Anthony Joseph, Shankar Sastry 2011
Bonnie Zhu, Anthony Joseph, Shankar Sastry 2011 A Taxonomy of Cyber Attacks on SCADA Systems Retrieved. 2018/01/12
Open source URL -
[3]
mitre-attack T0830Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.