NotCompatible is Android malware that turns an infected device into a proxy or relay for attacker traffic. This lets the operator hide their origin and use the device as part of broader criminal infrastructure. Defenders should inspect unexplained outbound connections, proxy-like behaviour, and mobile devices participating in traffic they should not generate.
What this malware does in practice
NotCompatible is a mobile proxy malware family, so the immediate danger is not only device compromise, but also that the infected phone becomes part of attacker infrastructure. That changes the device from a simple endpoint into an unwanted relay for malicious traffic.
This matters because proxying hides the operator’s source network, blends abusive traffic into ordinary mobile use, and can make the device an intermediary in abuse, fraud, or follow-on exploitation. For defenders, the key question is no longer just whether the phone is infected, but whether it is being used to move traffic it should never generate.
How this kind of malware is usually spotted
Detection starts with behaviour, not just signature matching. A device that makes unexplained outbound connections, maintains long-lived sessions to unfamiliar hosts, or behaves like a proxy by relaying traffic for other systems deserves closer inspection.
Mobile telemetry can also help distinguish normal app traffic from device-as-relay behaviour. Unusual data patterns, connections that do not align with installed applications, and network activity that persists when the user is inactive are common clues that the handset is being used as infrastructure rather than as a normal client.
Because Android malware often hides behind legitimate-looking app activity, defenders should correlate mobile network logs with endpoint alerts and user context. That helps separate ordinary background sync from traffic pivoting, tunnelling, or relay behaviour.
Why proxy malware is dangerous for organisations
A compromised phone used as a proxy creates visibility gaps. The organisation may see outbound traffic, but not immediately recognise that the traffic is being relayed on behalf of someone else, which complicates attribution, containment, and incident triage.
It can also widen the impact of a single infection. Once a device is acting as part of attacker infrastructure, it may support credential theft, command-and-control relay, abuse of corporate connectivity, or access to services that trust mobile-origin traffic. For broader context on mobile threats and family patterns, see NHIMG’s Mobile Malware Guide.
In practice, this means the harm is not limited to the handset owner. The device can become a stepping stone in criminal operations and a source of reputational, forensic, and containment overhead for the organisation that owns or manages it.
What defenders should do after identifying it
Once proxy behaviour is suspected, isolate the device from sensitive networks, preserve logs, and inspect for other signs of compromise such as persistence mechanisms, suspicious app installs, and traffic that continues after user activity should have stopped. If the device handled corporate email, VPN, or SSO sessions, assume those sessions may also need review.
For control design and hardening around mobile threats, pair behavioural monitoring with baseline device policy and application trust controls. The NIST SP 800-53 Rev 5 Security and Privacy Controls provide a useful control catalogue for access control, auditability, configuration management, and system integrity.
Risk and Threat Considerations
Proxy malware is dangerous because it turns a compromised endpoint into a trusted-looking relay. That gives attackers a way to mask origin, spread traffic across residential or mobile networks, and complicate detection by making malicious activity resemble ordinary device communication.
Failure mechanism: The malware establishes relay capability on the device, then routes attacker traffic through it so the real source is obscured and the device’s network behaviour no longer matches legitimate user activity.
Impact: Defenders can misattribute the traffic, miss the true operator, and lose visibility into the full attack path, while the infected device may be used in wider abuse campaigns or as a foothold for additional compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-13 — Data Protection | Proxy malware creates outbound traffic abuse and visibility gaps that data protection controls help constrain |
| Recommendation — Monitor mobile traffic baselines and block unauthorized outbound relay paths. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Relay behaviour is detected by reviewing logs and correlating anomalous outbound sessions |
| Recommendation — Correlate mobile and network logs to spot relay-style traffic. | ||
| MITRE ATT&CK | T1090 — Proxy | The malware turns the device into a proxy or relay for attacker traffic |
| Recommendation — Map observed relay behaviour to T1090 and hunt for compromised devices. | ||
Practitioner Guidance
What to watch for: Treat unexplained outbound connections, proxy-like session patterns, and traffic that cannot be tied to an installed app or user action as investigation triggers. On mobile fleets, the absence of obvious user impact does not mean the device is clean.
Governance implication: Mobile security policy should define who can investigate, isolate, and wipe a suspected device, because relay malware is both an endpoint issue and a network abuse issue. The response should cover device containment, session review, and validation that no corporate trust was abused through the infected handset.