DET0623: Detection of Adversary-in-the-Middle
DET0623 is a mobile ATT&CK detection strategy for identifying Adversary-in-the-Middle behavior related to T1638. The business significance is that mobile t...
Analyst context for executives and security teams
DET0623 is a mobile ATT&CK detection strategy for identifying Adversary-in-the-Middle behavior related to T1638. The business significance is that mobile traffic interception can undermine trusted communications and may enable follow-on outcomes such as transmitted data manipulation or endpoint denial of service, as described in the related ATT&CK technique. For leaders, the key question is whether mobile network visibility, device configuration oversight, and incident response procedures are strong enough to recognize when Android or iOS communications are being redirected or intercepted.
Executive priority
Prioritize this where mobile devices carry sensitive business data, support executive communications, or participate in operational workflows. Because the ATT&CK object provides no official detection text or platform detail beyond its relationship to Android and iOS technique T1638, executives should treat this as a coverage-validation item: confirm who owns mobile network monitoring, mobile device configuration assurance, and response decisions when interception or traffic redirection is suspected.
Technical view
SOC, detection engineering, and IR teams should map DET0623 to T1638 and validate detection coverage for mobile Adversary-in-the-Middle conditions on Android and iOS. The related technique notes that adversaries may position themselves between networked devices and that one mechanism can involve a malicious application registering as a VPN client to redirect device traffic. Practical validation should focus on whether teams can observe suspicious mobile VPN configuration changes, unexpected traffic redirection, abnormal certificate or network trust events where available, and user/device reports consistent with degraded or manipulated connectivity. Because MITRE did not provide official detection logic for this object, local telemetry and control implementation determine coverage.
Likely telemetry
- Mobile device management or enterprise mobility management records for Android and iOS configuration changes
- Mobile VPN profile creation, activation, or modification events where collected
- Mobile application inventory and permission/configuration data, especially applications capable of routing traffic
- Network security logs showing unusual mobile traffic paths, proxying, or unexpected destinations
- Certificate, TLS inspection, or trust-store related events where available
Detection direction
- Validate whether Android and iOS devices under management generate auditable events for VPN client registration, VPN activation, and profile changes.
- Correlate mobile configuration changes with network telemetry rather than relying on either source alone; traffic redirection may be invisible if only endpoint or only perimeter data is reviewed.
- Tune detections to distinguish approved enterprise VPN, security tooling, and carrier/network behavior from unexpected or user-installed traffic-routing applications.
- Use the T1638 relationship to look for follow-on indicators consistent with data manipulation or endpoint denial of service, while avoiding assumptions that either outcome occurred without evidence.
- Document blind spots for unmanaged mobile devices, bring-your-own-device populations, privacy-limited telemetry, and mobile traffic that bypasses enterprise inspection.
Mitigation priorities
- Establish an authoritative inventory of managed Android and iOS devices and the mobile security controls applied to each population.
- Restrict or review mobile VPN/profile installation and configuration changes where enterprise policy and device ownership allow.
- Maintain approved application and configuration baselines for mobile devices that handle sensitive business communications.
- Ensure incident response playbooks include mobile network interception scenarios, including device isolation, configuration review, and evidence preservation.
- Use compliance and audit processes to show that mobile device configuration governance, logging, and response ownership are defined and periodically tested.
Analyst notes and limits
This take is based on ATT&CK detection strategy DET0623 and its relationship to mobile technique T1638, Adversary-in-the-Middle. The most decision-relevant context comes from the related technique: Android and iOS are in scope, and a malicious application may redirect device traffic by registering as a VPN client. Detection engineering should therefore start with mobile configuration and network-redirection evidence rather than generic network monitoring alone.
The supplied DET0623 object has no official description, no official detection text, no tactics, and no platforms directly specified. Recommendations are constrained to the external reference and the relationship to T1638. Local device ownership model, mobile management coverage, privacy constraints, and available telemetry are required to determine real detection coverage.
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 |
|---|---|---|---|
| Mobile | T1638 | 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 | 85f1dbc85eb8… |
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 DET0623Open 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.