DET0764: Detection of Adversary-in-the-Middle
DET0764 is an ATT&CK ICS detection strategy for identifying adversary-in-the-middle behavior, where an actor with privileged network access may intercept,...
Analyst context for executives and security teams
DET0764 is an ATT&CK ICS detection strategy for identifying adversary-in-the-middle behavior, where an actor with privileged network access may intercept, block, log, modify, or inject traffic between devices. The business issue is trust in operational communications: if defenders cannot validate whether device-to-device traffic is authentic and unaltered, incident responders may have less confidence in process integrity, safety decisions, and recovery evidence.
Executive priority
Treat this as a control-assurance question for critical networks: can the organization prove that important ICS communications are being monitored well enough to spot unauthorized interception or modification? Leaders should ask whether network visibility, segmentation, privileged access governance, and incident response procedures cover the communications paths that matter most to operations. Because the ATT&CK object provides no official detection text or platforms, prioritization should be driven by local criticality, network architecture, and the consequences of manipulated traffic.
Technical view
For SOC, detection engineering, and IR teams, the relationship to T0830 points to real-time manipulation of network traffic in ICS environments. Validate whether monitoring can observe traffic to and from important devices, compare expected communication patterns against actual flows, and investigate signs that traffic is being blocked, altered, replayed, or injected. Because ATT&CK does not specify platforms, tactics, or analytics for DET0764, teams should avoid assuming coverage from generic network logging alone and instead test visibility on the relevant ICS network segments and communication paths.
Likely telemetry
- Network traffic captures or flow records for communications to and from critical ICS devices
- Baseline records of expected device-to-device communication paths, timing, and message patterns
- Network access and privileged access evidence showing who or what can reach sensitive network paths
- Alerts or logs indicating unexpected traffic interruption, redirection, injection, or modification where such monitoring exists
- Incident response packet evidence and change records needed to reconstruct whether communications were altered
Detection direction
- Map the detection strategy to T0830 and identify the specific ICS communication paths where interception or modification would create material operational risk.
- Validate that monitoring points can see both sides of important device communications; a blind spot between sensors and endpoints can hide adversary-in-the-middle behavior.
- Tune analytics against local baselines, because unusual traffic patterns may also result from maintenance, engineering changes, network troubleshooting, or legitimate failover.
- Correlate network anomalies with privileged access and network change evidence to separate misconfiguration from potentially unauthorized manipulation.
- Document what cannot be inspected due to architecture, encryption, proprietary protocols, or lack of sensor placement, since those gaps directly affect confidence in detection.
Mitigation priorities
- Start by identifying the most safety- or continuity-critical ICS communication paths and the accounts or systems with privileged network access to them.
- Ensure segmentation, access control, and change governance reduce unnecessary opportunities to intercept or alter traffic.
- Place or validate monitoring where it can observe relevant device communications, not only perimeter traffic.
- Maintain baselines for normal ICS communication behavior so detection engineering has a defensible comparison point.
- Update IR playbooks to preserve packet, flow, access, and change evidence when traffic manipulation is suspected.
Analyst notes and limits
The supplied ATT&CK detection strategy is sparse: it has a name and a relationship indicating it detects ICS technique T0830, but no official description, detection logic, tactics, platforms, or data sources. The take therefore focuses on decision value: visibility, control validation, and response readiness for potential manipulation of ICS network communications.
This summary does not assert active exploitation, affected products, specific platforms, or guaranteed detection coverage. Local architecture, protocols, sensor placement, and operational baselines are required to determine practical detectability and business risk.
Detection of Adversary-in-the-Middle
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0830 | Adversary-in-the-Middle | This object detects Adversary-in-the-Middle. |
All related ATT&CK context
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 | 1.0 | Current bundle | cc9091aa5f52… |
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]
mitre-attack DET0764Open 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.