DET0631: Detection of Proxy Through Victim
DET0631 is a mobile ATT&CK detection strategy for identifying when a compromised victim device is being used as an Internet proxy. The business significanc...
Analyst context for executives and security teams
DET0631 is a mobile ATT&CK detection strategy for identifying when a compromised victim device is being used as an Internet proxy. The business significance is that traffic may appear to come from a legitimate user device, weakening simple IP-based trust decisions and complicating fraud, account abuse, and incident scoping.
Executive priority
Treat this as a control-validation topic for mobile and identity-facing services rather than a standalone alert. Leaders should ask whether teams can distinguish normal Android user traffic from proxy-like behavior, whether account-risk decisions rely too heavily on source IP reputation, and whether incident responders can prove when a device became part of adversary infrastructure.
Technical view
The supplied ATT&CK object has no official detection text, platforms, or tactics, but it detects T1604 Proxy Through Victim, whose related platform is Android. SOC and detection teams should validate visibility into mobile network behavior, device posture, account access patterns, and unusual traffic routing that could indicate a compromised device forwarding adversary traffic. Detection logic should be tested against legitimate mobile VPN, enterprise proxy, carrier NAT, hotspot, and privacy-service behavior to reduce false positives.
Likely telemetry
- Mobile device network connection metadata where available
- Android device management or mobile security posture events where deployed
- Authentication and account access logs for services reached from mobile devices
- Network proxy, DNS, firewall, or secure web gateway logs
- Cloud or application session telemetry showing source IP, device identity, geography, and user agent context
Detection direction
- Confirm whether telemetry can associate network activity with a specific mobile device and user, not only an IP address.
- Look for mismatches between expected device behavior and account activity, such as unusual destinations, session patterns, or services accessed through the device context.
- Tune carefully for common benign causes: mobile carrier NAT, roaming, VPN clients, enterprise proxying, hotspot use, and privacy features.
- Correlate mobile device posture with identity events; a proxy-through-victim pattern may be missed if network, mobile, and identity logs are reviewed separately.
- Because ATT&CK provides no official detection logic for this object, validate detections with local baselines and incident data before using them as compliance or coverage evidence.
Mitigation priorities
- Reduce reliance on IP address alone for access decisions; favor device identity, session risk, and strong authentication context where applicable.
- Ensure managed mobile devices have sufficient security posture monitoring and response procedures for suspected compromise.
- Document how SOC and IR teams will triage a mobile device suspected of proxying traffic, including containment, evidence preservation, and user/account actions.
- Review identity and application controls that may be bypassed or weakened when adversary traffic appears to originate from a legitimate victim device.
- Use tabletop or detection validation exercises to confirm that mobile, network, and identity teams can jointly investigate this scenario.
Analyst notes and limits
This take is intentionally relationship-driven: the detection strategy object itself is sparse, while its ATT&CK relationship says it detects T1604 Proxy Through Victim in the mobile domain with Android as the related platform. The key defensive value is validating whether security teams can identify abuse hidden behind legitimate victim-device traffic.
Official description, official detection guidance, tactics, and object-level platforms were not provided. Any detection engineering must be grounded in local Android fleet visibility, mobile management coverage, network architecture, and identity/application logging. No active exploitation, attribution, or guaranteed detection coverage is implied.
Detection of Proxy Through Victim
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 | T1604 | Proxy Through Victim | This object detects Proxy Through Victim. |
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 | 69f14ef4a57b… |
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 DET0631Open 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.