Mobile ATT&CK Command and Control Tactic: Spotting Mobile Malware Channels on Android and iOS

Almost every piece of mobile malware needs to receive instructions and new code, and the Command and Control tactic (TA0037) in MITRE ATT&CK for Mobile describes how it does that while blending into normal phone traffic. ATT&CK v20 defines the tactic as the adversary "trying to communicate with compromised devices to control them" and adds a mobile-specific point: phones often sit on cellular and public Wi-Fi networks outside enterprise control, and can use non-IP channels such as SMS. This hub covers all nine current techniques and their eight sub-techniques, the patterns seen in real malware families, the network and device signals defenders can use on Android and iOS, and the controls that narrow the channel. It is written for mobile security engineers, network and SOC teams, and MDM administrators. Each technique has its own deep page linked from the table.

Key takeaways

• Web protocols carry most mobile C2. In the v20 dataset T1437.001 Web Protocols is linked to 49 software entries, the Dark Caracal group and campaign C0033, far more than any other C2 technique.
• Phones have channels laptops do not. T1644 Out of Band Data (SMS, NFC, Bluetooth) has 19 software entries including Pegasus for Android and iOS, and T1616 Call Control has 17, mostly Android banking and spyware families.
• Legitimate services provide cover. T1481 Web Service covers dead drop resolvers, two-way and one-way channels on public platforms, and T1663 Remote Access Software covers legitimate tools turned into C2.
• Few formal mitigations exist. Only T1616, T1644, T1663 and T1521.003 have mitigations mapped in v20 (M1011 User Guidance and M1012 Enterprise Policy), so defence leans on network controls, app vetting and managed configuration.
• Your network vantage point is optional on mobile. Unless traffic is forced through an always-on VPN or a managed DNS resolver, a phone on cellular data is invisible to the corporate network stack.

Why mobile C2 is different

Enterprise network detection assumes that endpoints sit behind a proxy, firewall and DNS resolver you control. Mobile devices break that assumption. They move between home Wi-Fi, cellular data and public hotspots; their apps legitimately talk to hundreds of cloud services; and most of that traffic is TLS-encrypted. ATT&CK's tactic description notes that cellular data caps and charges can make heavy C2 traffic noticeable, but a modest implant that polls a web API every few minutes looks like any other app. The mobile platforms also give malware non-IP options: SMS commands, push notification services and phone calls.

That shapes what works. Network detection only helps once you route device traffic through infrastructure you see. On-device and app-vetting signals, such as which permissions an app holds and which domains it contacts during dynamic analysis, are often the better source. For the wider matrix, see the MITRE ATT&CK for Mobile Guide.

Every technique in the tactic

All current (not revoked or deprecated) techniques and sub-techniques with the command-and-control phase in the ATT&CK for Mobile v20 dataset. Counts are distinct software (malware or tool) and group or campaign objects with a "uses" relationship; DET is the v20 detection strategy.

That is nine parent techniques shown in nine rows; T1437, T1481, T1521 and T1637 carry eight sub-techniques between them, which the deep pages cover. All are listed for Android and iOS except T1616 Call Control, which is Android only.

Where to start: ranked for defenders

1. T1437.001 Web Protocols. HTTP and HTTPS to attacker infrastructure, and push channels: ATT&CK notes that notification services such as Firebase Cloud Messaging can carry two-way traffic. Families in v20 include Cerberus, FluBot, GodFather, Exodus, FakeSpy and BRATA. Domain and destination reputation, plus app vetting that records contacted domains, catches most of it.
2. T1544 Ingress Tool Transfer. Downloading additional payloads after install is how small droppers in app stores become full banking trojans. v20 links it to Mandrake, SharkBot, Chameleon, Phenakite, LightSpy and TriangleDB. Pair it with Mobile T1407 Download New Code at Runtime, which sits under Defense Evasion.
3. T1644 Out of Band Data and T1616 Call Control. SMS commands and call forwarding survive network blocking and are central to banking fraud (Rotexy, TrickMo, Fakecalls, Gustuff). Permission policy is the main lever.
4. T1481 Web Service and T1637.001 DGAs. Dead drop resolvers on public platforms (Anubis, Red Alert 2.0, XLoader) and generated domains (FluBot, SharkBot, Rotexy) defeat static block lists; detection needs behaviour and DNS analytics.
5. T1521 Encrypted Channel, T1509 Non-Standard Port, T1663 Remote Access Software. Lower counts but useful signals: unusual ports from a phone, an app-level layer of encryption inside TLS, or a remote access tool nobody approved.

How it chains with other tactics

Method: among the 129 software entries in ATT&CK for Mobile v20 that use any technique, 78 use at least one technique carrying the command-and-control phase. Of those 78, 72 also use Collection techniques, 71 Discovery, 63 Defense Evasion, 44 Impact, 41 Credential Access, 34 Initial Access and 26 each Exfiltration and Persistence. C2 is the backbone that the rest of the intrusion hangs on, so breaking the channel limits collection and fraud even after a device is infected.

Detection priorities

The v20 detection strategies for this tactic (for example DET0620 for Web Protocols, with analytics AN1681 for Android and AN1682 for iOS) correlate application vetting and instrumented dynamic analysis with management state and network evidence. In practice, defenders have three vantage points.

For high-risk users, a consensual forensic check with the Mobile Verification Toolkit (MVT) can match device records against published spyware indicators, including known C2 domains.

Metrics that show coverage

• Visibility coverage: share of managed devices whose traffic passes through managed DNS or always-on VPN.
• Vetting coverage: share of installed apps that passed vetting before approval.
• Risky permission holders: count of non-default apps holding SMS, call or notification listener rights, trending down.
• Unapproved remote access tools: number of devices with a remote access app not on the approved list, target zero.
• Time to block: minutes from a C2 domain being identified to it being blocked at the resolver.

Prevention and hardening

• Route traffic you can see: on Android, an always-on VPN can block connections that do not use the VPN; on Apple platforms the DNS Settings payload sets an encrypted resolver over HTTPS or TLS. Either gives you a DNS and destination log for managed devices.
• Use the platform permission gates: Google Play policy restricts READ_SMS, RECEIVE_SMS, SEND_SMS and the call log permissions to apps registered as the default SMS, Phone or Assistant handler, with reviewed exceptions. On managed devices, block sideloading so apps that bypass that review cannot arrive. See Mobile App Permissions.
• Approve remote access tools explicitly (M1012): keep an allowlist of support tools and treat any other remote control or screen-sharing app on a managed device as an incident.
• Constrain your own apps' networking: Android Network Security Configuration disables cleartext by default for apps targeting API 28 and above and, from API 24, trusts only system CAs unless the app opts in to user CAs. Keep those defaults in apps you build, and pin with a backup pin and a planned rotation.
• Reduce reliance on SMS for authentication: T1644 and T1616 exist largely because SMS and calls carry one-time codes. Moving to app-based or phishing-resistant authentication removes the prize.

Rollout order

1. Pilot managed DNS or always-on VPN on corporate-owned devices in monitor mode; record what breaks (captive portals, apps that bind to a specific network).
2. Add threat intelligence and newly registered domain blocking in log-only mode, then enforce for a pilot ring.
3. Turn on app vetting for every catalogue request and re-vet on major updates, since droppers fetch code after approval.
4. Enforce fleet-wide; roll back by switching the resolver policy to log-only rather than removing the profile.

Decision guidance

• BYOD with work profile or app protection only: you will not see personal traffic and should not try. Focus on permission policy, app vetting for work apps, and per-app VPN for managed apps.
• Corporate-owned fleets: always-on VPN or managed encrypted DNS gives real C2 visibility; the cost is support effort for networks that block VPNs.
• High-risk users: network controls will not see an implant using TLS to a cloud host with its own encryption layer (T1521.002). Combine Lockdown Mode, fast patching and periodic forensic checks.

Where identity fits

Mobile C2 is often aimed at identities rather than devices: SMS and call interception (T1644, T1616) target one-time passcodes, and payloads fetched over C2 frequently steal session tokens and app credentials. Treat confirmed C2 on a device as credential exposure: revoke refresh tokens and device certificates, and re-register authenticators. See the Mobile Banking App Security Guide for the fraud angle.

Common failure patterns

• Assuming the corporate proxy sees phones: it only sees traffic you route to it.
• Vetting apps once: droppers pass review and download their payload later through T1544.
• Static block lists against DGAs and dead drops: FluBot-style generated domains and resolvers hosted on public services outpace manual lists.
• Allowing any remote support app: fraud operations ask victims to install legitimate remote access tools, which then serve as the C2 channel.
• Leaving SMS as the only second factor: it keeps SMS interception profitable.

Framework mapping

Practitioner checklist

• Decide which device groups will route traffic through managed DNS or always-on VPN, and measure coverage.
• Log DNS for managed devices and alert on newly registered and generated domains.
• Vet every catalogue app with dynamic analysis, and re-vet on updates.
• Block sideloading on managed Android devices.
• Inventory apps holding SMS, call, notification listener and accessibility rights.
• Keep an approved list of remote access tools and alert on anything else.
• Move users off SMS one-time codes for corporate sign-in.
• Revoke tokens and certificates on any device with confirmed C2.

Standards and references

• MITRE ATT&CK: Command and Control, Mobile (TA0037)
• NIST: SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise
• Android Developers: VPN (always-on VPN and blocked connections)
• Android Developers: Network security configuration
• Google Play Console Help: Use of SMS or Call Log permission groups
• Apple Platform Deployment: DNS Settings payload settings
• Amnesty International Security Lab: Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide, Mobile ATT&CK Privilege Escalation Tactic, Mobile ATT&CK Execution Tactic, Mobile Malware Guide, Mobile T1646 Exfiltration Over C2 Channel.