T1604: Proxy Through Victim
Adversaries may use a compromised device as a proxy server to the Internet. By utilizing a proxy, adversaries hide the true IP address of their C2 server and associated infrastructure from the destination of the network traffic. This masquerades an adversary’s traffic as legitimate traffic originating from the compromised device, which can evade IP-based restrictions and alerts on certain services, such as bank accounts and social media websites.[1]
The most common type of proxy is a SOCKS proxy. It can typically be implemented using standard OS-level APIs and 3rd party libraries with no indication to the user. On Android, adversaries can use the `Proxy` API to programmatically establish a SOCKS proxy connection, or lower-level APIs to interact directly with raw sockets.
Analyst context for executives and security teams
Proxy Through Victim is a mobile ATT&CK technique where a compromised Android device is used as an Internet proxy, making adversary traffic appear to originate from the victim’s device. For business leaders, the material risk is not just malware on a phone; it is the possibility that trusted customer, employee, or user devices can be abused to bypass IP-based controls and make fraudulent or suspicious activity look legitimate.
Executive priority
Prioritize this behavior where Android devices are used for banking, customer access, workforce identity, privileged administration, or other services that rely on device reputation, source IP, or geo-location as risk signals. Leaders should ask whether mobile security, fraud monitoring, identity controls, and SOC workflows can distinguish normal user traffic from traffic relayed through a compromised device. This is especially relevant for resilience and audit discussions around mobile access controls, fraud prevention, and incident response evidence quality.
Technical view
ATT&CK lists this as a mobile technique for Android, with no official detection text or tactic specified. The description highlights SOCKS proxy behavior implemented through Android Proxy APIs or lower-level raw socket activity. SOC, mobile security, and IR teams should validate whether they can see unusual outbound proxy-like connections, abnormal socket use, unexpected long-lived network sessions, and application behavior inconsistent with normal mobile app function. Relationship context shows Exobot and FluBot use this technique, so detection engineering should include mobile banking malware tradecraft context without assuming those families are present in the environment.
Likely telemetry
- Android device network connection metadata, including destination, duration, volume, and frequency
- Mobile threat defense or EDR telemetry for application network behavior
- Application inventory and package reputation data for Android devices
- Proxy, VPN, firewall, secure web gateway, or DNS logs where mobile traffic traverses managed infrastructure
- Identity, fraud, or application access logs containing source IP, device, geolocation, and session-risk signals
Detection direction
- Validate visibility into Android outbound connections that resemble proxying, such as unusual SOCKS-like behavior, raw socket activity, or sustained relay-style sessions.
- Correlate mobile device identity, app identity, source IP changes, session behavior, and destination services rather than relying only on IP-based alerts.
- Tune for false positives from legitimate VPNs, enterprise proxies, privacy tools, mobile carrier NAT behavior, and authorized remote-access applications.
- Use the related detection strategy DET0631 as a cue to build or map coverage, but do not assume coverage because ATT&CK provides no official detection details in the supplied object.
- Review detections in the context of related Android malware Exobot and FluBot, while avoiding family-specific assumptions unless local telemetry supports them.
Mitigation priorities
- Reduce dependence on source IP alone for access, fraud, and risk decisions; combine device posture, identity, session behavior, and transaction context.
- Ensure Android device management or mobile threat controls can identify suspicious applications and abnormal network behavior where managed devices are in scope.
- Harden mobile access paths for sensitive services with strong authentication, conditional access, and device trust checks where appropriate.
- Prepare IR procedures for collecting Android device, application, and network evidence when proxy-through-victim behavior is suspected.
- For compliance and assurance, document what mobile telemetry is collected, how long it is retained, and how it supports investigations involving device-originated traffic.
Analyst notes and limits
The supplied ATT&CK object is specific to Android and describes proxying through a compromised device to hide adversary infrastructure and evade IP-based restrictions or alerts. The only cited example in the object is Threat Fabric reporting on Exobot, and the relationship set also includes FluBot. ATT&CK provides no official detection text and no tactic for this object, so practical coverage must be validated against local mobile, network, identity, and fraud telemetry.
This take is limited to the supplied ATT&CK fields, references, and relationships. It does not assert active exploitation, customer exposure, specific adversary attribution, or guaranteed detectability. Local device management scope, mobile telemetry availability, application mix, and identity/fraud control design determine actual risk and coverage.
Proxy Through Victim
Adversaries may use a compromised device as a proxy server to the Internet. By utilizing a proxy, adversaries hide the true IP address of their C2 server and associated infrastructure from the destination of the network traffic. This masquerades an adversary’s traffic as legitimate traffic originating from the compromised device, which can evade IP-based restrictions and alerts on certain services, such as bank accounts and social media websites.[1]
The most common type of proxy is a SOCKS proxy. It can typically be implemented using standard OS-level APIs and 3rd party libraries with no indication to the user. On Android, adversaries can use the `Proxy` API to programmatically establish a SOCKS proxy connection, or lower-level APIs to interact directly with raw sockets.
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.
Groups, software, and campaigns
S1067: FluBot
FluBot is a multi-purpose mobile banking malware that was first observed in Spain in late 2020. It primarily spread through European countries using a variety of SMS phishing messages in multiple languages.[1][2] An international law enforcement operation of 11 countries eventually disrupted the spread of FluBot.[3]
S0522: Exobot
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.1 | Current bundle | 8fc5bb94235b… |
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]
Threat Fabric Exobot
Threat Fabric. (2017, February). Exobot - Android banking Trojan on the rise. Retrieved October 29, 2020.
Open source URL -
[2]
mitre-attack T1604Open 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.