AN1702: Analytic 1702
The defender correlates proxy-capable network setup or socket-handling behavior with subsequent bidirectional traffic relaying through the same device and app context, especially when inbound client sessions are followed by outbound connections to unrelated remote destinations or when the device sustains multiplexed traffic patterns inconsistent with normal mobile app workflows. The analytic prioritizes Android-observable effects: proxy or raw-socket setup, app background execution, inbound-to-outbound traffic bridging, and sustained relayed flows to multiple destinations without recent user interaction.
Analyst context for executives and security teams
This analytic is about spotting an Android device or app behaving like a relay point: accepting or handling traffic and then forwarding it to unrelated remote destinations, often in the background and without recent user interaction. For leaders, the practical issue is that a mobile device can become part of a traffic path that obscures where activity is really coming from, creates investigation complexity, and may introduce business, compliance, or operational risk if unmanaged mobile endpoints are trusted inside enterprise workflows.
Executive priority
Prioritize this where Android devices have access to corporate networks, identity-protected applications, sensitive data, or operational environments. The decision value is to verify whether mobile security monitoring can distinguish normal app networking from proxy-like relaying behavior, and whether incident responders can quickly identify the app, device, user context, and destinations involved. This is especially relevant for managed detection readiness, mobile device governance, compliance evidence around endpoint monitoring, and incident containment planning.
Technical view
SOC and detection teams should validate Android-observable evidence around proxy-capable network setup, raw socket or socket-handling behavior, app background execution, inbound-to-outbound traffic bridging, sustained bidirectional relayed flows, multiplexed traffic patterns, multiple unrelated remote destinations, and lack of recent user interaction. Because ATT&CK does not provide a separate official detection procedure for this analytic, teams should treat the description as detection intent and map it to available mobile telemetry, network telemetry, and MDM or EDR-style device context. Tactics are not specified in the supplied object, and no relationship context is provided, so local use-case scoping is required.
Likely telemetry
- Android app network connection metadata, including source app context and destination endpoints
- Evidence of proxy-capable configuration, proxy-like listener behavior, or raw socket usage where available
- Inbound session records followed by outbound connections from the same device and app context
- Flow duration, byte counts, directionality, and multiplexed connection patterns
- Background app execution state and recent user interaction signals
Detection direction
- Validate whether telemetry can correlate inbound client sessions with outbound connections from the same Android device and app context.
- Tune for sustained bidirectional relaying and multiplexed traffic patterns that are inconsistent with expected mobile app workflows, rather than alerting only on single network connections.
- Use app foreground/background state and recent user interaction as important context to reduce noise.
- Baseline sanctioned apps that legitimately use proxying, VPN, debugging, or network relay functions to manage false positives.
- Identify blind spots where Android app identity, socket behavior, inbound mobile sessions, or background execution state is not collected.
Mitigation priorities
- Inventory Android devices and apps that are allowed to access enterprise resources and confirm ownership, management status, and logging coverage.
- Restrict or review apps with proxy, VPN, raw socket, or relay-like capabilities where they are not business-required.
- Ensure MDM, mobile threat defense, network controls, and incident response processes can connect device, user, app, and network destination context.
- Define containment steps for suspected relay behavior, such as isolating the device from enterprise access, preserving relevant telemetry, and reviewing installed apps and recent activity.
- Maintain allowlists or documented exceptions for legitimate mobile apps that create sustained background network tunnels or relay-like flows.
Analyst notes and limits
This object is a mobile ATT&CK detection analytic for Android. Its value is strongest as a validation checklist for whether mobile and network monitoring can prove or disprove relay-like behavior on a device. The absence of supplied relationships means it should not be over-mapped to a specific tactic, technique, or adversary without additional ATT&CK or local evidence.
The supplied object has no official detection field, no tactics, no aliases, and no relationship context. Conclusions about prevalence, attacker use, impact, or existing detection coverage are not supported by the provided STIX fields. Local telemetry quality and Android management coverage will determine whether this analytic can be operationalized.
Analytic 1702
The defender correlates proxy-capable network setup or socket-handling behavior with subsequent bidirectional traffic relaying through the same device and app context, especially when inbound client sessions are followed by outbound connections to unrelated remote destinations or when the device sustains multiplexed traffic patterns inconsistent with normal mobile app workflows. The analytic prioritizes Android-observable effects: proxy or raw-socket setup, app background execution, inbound-to-outbound traffic bridging, and sustained relayed flows to multiple destinations without recent user interaction.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.1 | Current bundle | e81bbaac733f… |
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 AN1702Open 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.