Mobile T1604 Proxy Through Victim Guide

Mobile malware can turn an infected Android phone into a proxy, so fraud and command traffic arrives from the victim's own IP address and slips past IP-based risk checks. MITRE ATT&CK for Mobile tracks this as T1604 Proxy Through Victim, under the Defense Evasion tactic. This guide explains how the technique works, what it defeats, how to spot it with mobile device management (MDM), mobile threat defence (MTD) and network telemetry, and how service owners such as banks should stop trusting device IP as a strong signal. It is written for mobile security engineers, SOC analysts and fraud teams. For the wider matrix, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

Android only in ATT&CK. ATT&CK v20 lists T1604 for Android; no iOS procedure is recorded, so this page does not invent one.
The target is IP reputation, not the phone. Attackers relay traffic through the device so that bank or social media logins look like they come from the real customer's network.
SOCKS is the common form. ATT&CK notes a SOCKS proxy can be built with standard Android APIs or raw sockets and gives the user no visible sign.
Network logs are the best device signal. Android Enterprise network logging records DNS lookups and TCP connections per app package, which exposes long-lived relay connections from apps with no business need for them.
Fraud controls must assume the IP is shared. Device attestation, session binding and behavioural signals carry more weight than geolocation of the source address.

What T1604 is and why it matters

ATT&CK describes Proxy Through Victim as an adversary using a compromised device as a proxy server to the internet. The relay hides the true address of the attacker's command and control (C2) infrastructure and makes attacker traffic appear to originate from the device, which can evade IP-based restrictions and alerts on services such as bank accounts and social media. The technique page notes that on Android, malware can use the Proxy API to set up a SOCKS proxy connection, or lower-level APIs to work directly with raw sockets.

The technique is closely related to the enterprise technique T1090 Proxy, but the direction of trust is different. On a server, a proxy usually hides attacker origin from the victim network. On a phone, the infected device itself becomes part of the attacker's infrastructure, and the party being deceived is often a third-party service that trusts the customer's IP address. See the T1090 Proxy Defensive Guide for the enterprise side, and the Residential Proxy Networks and Abuse Guide for the wider market in hijacked consumer IP addresses.

Platform scope

ATT&CK v20 lists Android as the only platform for T1604. Apple's platform security guide states that all third-party iOS apps are sandboxed and that apps can perform background processing only through system-provided APIs, which constrains a long-running hidden relay. No iOS procedure example is recorded in ATT&CK, so treat iOS as out of scope for this technique unless new reporting appears.

Real cases from ATT&CK procedure examples

Software	What ATT&CK records for T1604	Source context
Exobot (S0522)	Can open a SOCKS proxy connection through the compromised device.	ThreatFabric's July 2017 Exobot v2 write-up reported hints of SOCKS proxy code in the C2, noting it could help attackers stay hidden and bypass IP-based fraud detection.
FluBot (S1067)	Can use a SOCKS proxy to evade C2 IP detection.	Proofpoint (April 2021) reported FluBot spreading by SMS lures posing as delivery notices, gaining full device access through the Accessibility Service, and opening a SOCKS proxy on C2 request.

Both are Android banking malware families. The pattern is consistent: the proxy is one module among credential theft, overlay and SMS interception features, and it exists to make fraudulent sessions look like the genuine customer. For the malware families themselves, see the Android Banking Trojans Guide.

Detection: signals and where they come from

ATT&CK's detection strategy for T1604 (DET0631) correlates four kinds of evidence. The table maps each to a practical collector.

Evidence	Collector	What to look for
Network traffic flow	Android Enterprise network logging (`DevicePolicyManager.retrieveNetworkLogs()`, `DnsEvent` and `ConnectEvent`) or enterprise VPN flow metadata	An app package holding persistent TCP connections to a small set of IP addresses, especially fixed IPs with no DNS lookup, on unusual ports, and at all hours
Network traffic content	Secure web gateway or proxy, where inspection is deployed	Traffic patterns that match relay behaviour, such as many distinct destination sites tunnelled through one app session
Application permission	`DevicePolicyManager.getPermissionGrantState()`, manifest review in app vetting	Apps with network access combined with accessibility, SMS or notification access that their stated purpose does not need
OS API execution	App vetting and instrumented dynamic analysis	Apps that create `ServerSocket` listeners, SOCKS client code or bidirectional relays without being on an approved list

Limits of on-device network logging

Android's documentation sets the boundaries clearly, and an analyst needs them in mind:

Who can collect: a device owner on Android 8.0 and later sees all device traffic; a profile owner of a work profile on Android 12 and later sees only work profile traffic, not the personal profile where most consumer malware lands.
What is missed: UDP traffic, direct DNS server communication, connections to fixed IPs that skip DNS, and apps that issue system calls directly are not captured. A relay that connects to a hard-coded IP produces a ConnectEvent with no matching DnsEvent, which is itself a useful anomaly.
Retention: logs arrive in batches of up to 1,200 events and are discarded if not retrieved, so the DPC or MDM must forward them promptly to the SIEM.

Android advises combining device logs with network-layer monitoring such as a VPN gateway or firewall for complete coverage. For BYOD devices where the organisation cannot see the personal profile, detection shifts to the service side.

Service-side detection for banks and platforms

Session inconsistency: a login from the customer's usual IP whose app integrity or device signals do not match the enrolled device.
Concurrent use: the genuine app session and a second, browser-style session sharing one source address at the same time.
Integrity verdicts: the Play Integrity API can return appRecognitionVerdict, deviceIntegrity labels and, where opted in, an appAccessRiskVerdict for apps that can capture the screen, draw overlays or control the device, plus a playProtectVerdict. A request that lacks a valid verdict from the real app is not the real app, whatever its IP.

Prevention and hardening

Control	Owner	Effect on T1604
Keep Google Play Protect on and block sideloading on managed devices	Endpoint / MDM team	Reduces installation of the banking malware that carries proxy modules
Restrict accessibility and notification access to approved apps through MDM policy	Endpoint / MDM team	FluBot needed Accessibility Service access to take control; removing it breaks the infection chain before the proxy runs
Route managed traffic through an always-on VPN to an inspected gateway	Network team	Makes relay flows visible and allows egress policy on unusual ports
Bind sessions to device attestation, not IP	Application and fraud teams	Removes the benefit the proxy is meant to provide
Apply OS security updates and require a recent patch level	Endpoint / MDM team	Closes flaws that malware can use to gain the access it needs (ATT&CK M1006 Use Recent OS Version)

ATT&CK v20 lists no specific mitigation object for T1604. The controls above reduce the likelihood of infection and the value of the proxy rather than blocking a single API.

How to implement

Confirm coverage. List which managed devices are fully managed (device owner) and which are work profile only, because that decides what network logging can see.
Turn on network logging in audit mode. Enable it on a pilot ring through the MDM or DPC, forward DnsEvent and ConnectEvent batches to the SIEM, and baseline normal per-package traffic for two to four weeks.
Write the first detections. Alert on non-approved packages with long-lived connections to fixed IPs, connections with no prior DNS lookup, and new listeners found in app vetting.
Tighten app policy. Block unknown sources, restrict accessibility services to an allowlist, and require Play Protect on managed devices.
Add service-side checks. For customer apps, require integrity verdicts on sensitive calls and lower the trust weight of source IP in fraud scoring.
Roll out and keep a rollback path. Expand ring by ring; if network logging affects battery or MDM stability, disable it through the same policy (Android deletes unreported logs when logging is turned off, so export first).

Decision guidance

Fully managed corporate phones: device-owner network logging plus always-on VPN gives good visibility. Use it.
BYOD with work profiles: you see only work profile traffic. Rely on MTD app scanning, compliance checks and service-side attestation rather than trying to monitor personal traffic.
Consumer-facing apps: you never control the device. Invest in integrity verdicts and session binding; treat matching IP and geolocation as weak evidence.
Small organisations: start with MDM policy (no sideloading, accessibility allowlist) and an MTD product; network logging analysis can wait until there is SOC capacity.

Where identity fits

The proxy exists to make a stolen credential or session look legitimate. Banking and social media accounts reached through the victim's IP are human identities, but the same trick works against API keys or OAuth tokens lifted from the device, which are non-human credentials whose use is often scored on source address alone. Bind tokens to the device where the platform allows it and watch for token use that does not match app integrity signals. See the Mobile Access Credentials guide.

Metrics that show it is working

Share of managed Android devices forwarding network logs to the SIEM.
Number of apps on managed devices with accessibility access outside the allowlist (target: zero).
Share of sensitive customer API calls carrying a valid integrity verdict.
Mean time from a relay-pattern alert to device quarantine.
Fraud cases where the attacker session shared the customer's IP, tracked quarter on quarter.

Framework mapping

Framework	Reference	Relevance
MITRE ATT&CK for Mobile	T1604 Proxy Through Victim; DET0631	Technique and detection strategy
NIST CSF 2.0	DE.CM-01, DE.CM-09	Monitoring networks and runtime environments
NIST SP 800-53 Rev 5	AC-19, SC-7, SI-4	Mobile device access control, boundary protection, system monitoring
ISO/IEC 27001:2022 Annex A	A.8.1, A.8.16	User endpoint devices, monitoring activities
OWASP MASVS	MASVS-RESILIENCE	Apps confirming they run on a trusted platform before sensitive actions

Common failure patterns

IP match treated as proof: fraud rules that pass a session because it comes from the customer's home network are exactly what T1604 defeats.
Logs enabled but never collected: network logging batches are discarded when the buffer fills, so logging without a forwarder gives no evidence.
Work profile blind spot unacknowledged: teams assume they can see personal profile traffic on BYOD devices and miss malware installed there.
Accessibility left open: without an allowlist, a user tapping through prompts grants the access that lets banking malware take over before any proxy activity starts.
DNS-only monitoring: relays that connect to fixed IPs never appear in DNS logs.

Practitioner checklist

Record which Android devices are device owner versus work profile managed.
Enable Android Enterprise network logging and forward batches to the SIEM promptly.
Alert on connections with no preceding DNS lookup from non-approved packages.
Block unknown sources and keep Play Protect on for managed devices.
Allowlist apps permitted accessibility and notification access.
Require Play Integrity or key attestation verdicts on sensitive customer API calls.
Reduce the weight of source IP and geolocation in fraud scoring.
Rehearse quarantine of a device flagged for relay behaviour, using the Mobile Spyware Infection Response Playbook.

Mobile T1604 Proxy Through Victim: Detecting Phones Used as Attacker Proxies