Mobile T1644 Out of Band Data: Detecting SMS, NFC and Bluetooth Command Channels

Mobile malware does not need the internet to take orders: an SMS, a notification or an NFC exchange can carry commands that never cross the corporate proxy, VPN or secure web gateway. ATT&CK for Mobile v20 tracks this as Out of Band Data (T1644), a Command and Control (TA0037) technique on both Android and iOS. Adversaries use it to avoid network monitoring, as a backup channel when the main server is blocked, and to move data when a device has no Wi-Fi or cellular data connection. This page is for mobile security engineers, MDM administrators and incident responders: how the technique works on each platform, the procedure examples ATT&CK records, where the evidence sits, and the platform controls that narrow the channel. For the wider matrix and how mobile tactics fit together, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• The channel bypasses your network sensors. SMS, NFC and Bluetooth traffic does not pass through an enterprise proxy or DNS filter, so network-only detection misses it by design.
• SMS dominates the procedure examples. Most ATT&CK v20 entries for T1644, from Pegasus for iOS to Rotexy and Gustuff, describe malware taking commands by text message, often from a fixed "control phone" or with hard-coded magic strings.
• On Android the gate is a permission. Reading SMS content needs restricted SMS permissions or notification access, and ATT&CK notes that notification access must be granted by the user in Settings, although an app can send the user straight to that screen.
• iOS is narrower but not immune. ATT&CK states there is no way for an iOS app to read push notifications programmatically, yet Pegasus for iOS used SMS for command and control, so assume high-end spyware can reach the channel.
• Detection is mostly on the device and in app vetting. Permission grant state from MDM, application vetting of requested permissions and forensic review with tools such as MVT give more signal than the network.

What T1644 is and why adversaries use it

ATT&CK defines Out of Band Data as communicating with compromised devices using data streams outside the normal internet path. It lists three reasons: evading network traffic monitoring, providing a backup command and control (C2) method, and exfiltrating data when the device has no internet-providing network. The streams named are SMS messages, NFC and Bluetooth. The technique has no sub-techniques in v20 and applies to Android and iOS.

For a defender the important point is architectural. Enterprise mobile security often relies on per-app VPN, a secure web gateway or DNS filtering to see where apps talk. Out of band channels sit below or beside that layer: an SMS arrives over the cellular signalling path, NFC works at a few centimetres and Bluetooth pairs directly with a nearby device. The same device may be well covered for HTTP C2 (see Beaconing and C2 Detection Guide) and blind to a text message that says "upload contacts".

Real cases from ATT&CK v20

The procedure examples below are taken from the ATT&CK v20 Mobile data set as ATT&CK states them. Attribution of spyware to vendors or customers is only as the cited ATT&CK software page states it.

• Pegasus for iOS (S0289) and Pegasus for Android (S0316): both use SMS for command and control. This is the clearest evidence that iOS limits on reading messages do not stop spyware that has already exploited the device.
• Monokle (S0407): can be controlled via email and SMS from a set of "control phones".
• Gustuff (S0406) and TrickMo (S0427): Gustuff accepts SMS commands from a defined admin phone number; TrickMo can be controlled through encrypted SMS. Both are banking malware, covered more broadly in the Android Banking Trojans Guide.
• SharkBot (S1055): uses Android's Direct Reply feature to answer notifications automatically with a message supplied by C2, turning notification access into a two-way channel.
• Skygofree (S0327) and BusyGasper (S0655): Skygofree accepts binary SMS; BusyGasper acts when one of two hard-coded magic SMS strings arrives.
• NGate (S9040): used NFC to send the victim's card information through a server to an adversary-controlled device, an example where the out of band stream carries data rather than commands.
• Others listed by ATT&CK: Desert Scorpion, Rotexy, Stealth Mango, RCSAndroid, SpyDealer, SpyC23, BOULDSPY, CarbonSteal and Android/Chuli.A, all controlled by SMS. TriangleDB (S1216) is also mapped to T1644 in v20, with a description of Protobuf-based C2 messaging.

Android and iOS: how the channel is reached

Android

• SMS permissions: READ_SMS, RECEIVE_SMS, RECEIVE_MMS, RECEIVE_WAP_PUSH, SEND_SMS and WRITE_SMS form a restricted group under Google Play policy. Only the default SMS, Phone or Assistant handler, or an app granted a declared exception, may request them. Malware that wants this group is usually distributed outside Play; see APK sideloading.
• Notification access: ATT&CK notes that apps can read push notifications, including the content of SMS, once the user grants notification access in the settings menu, and that an app can launch an Intent that takes the user directly to that screen. Listener apps declare a service protected by the BIND_NOTIFICATION_LISTENER_SERVICE permission.
• Restricted settings: on Android 13 and later Android can block sensitive settings such as accessibility for apps the user was told to download, until the user explicitly chooses "Allow restricted settings" for that app. Social engineering now targets that extra step.

iOS

• No programmatic notification reading: ATT&CK states there is no way to read push notifications programmatically on iOS, and the platform offers no public API for third-party apps to read SMS.
• Exploit-dependent access: the iOS procedure examples are spyware that gained deep access through exploitation, which is why high-risk users should consider Apple Lockdown Mode. Lockdown Mode blocks most Messages attachment types and turns off link previews, reducing the message-borne attack surface. See the Apple Lockdown Mode Guide.

What to detect and where

ATT&CK v20's detection strategy for T1644 correlates application vetting and dynamic analysis (a notification listener receiving notifications from high-value apps when it is not on an allow list), Android Enterprise managed app telemetry, Apple MDM device and profile state, and network flow metadata where a per-app VPN or gateway is deployed. In practice that becomes four data sources.

The Mobile Verification Toolkit (MVT), developed by Amnesty International's Security Lab and released in July 2021, supports consensual forensic analysis of iOS backups, filesystem dumps and sysdiagnose files, and Android backups including SMS. Use it with the device owner's consent and through a defined process; see the Mobile Forensics Guide and the Mobile Spyware Infection Response Playbook.

Mitigations

ATT&CK v20 maps one mitigation to T1644: M1011 User Guidance, telling users not to grant applications unexpected or unnecessary permissions. That is necessary but not enough for a managed fleet. The rows marked as additions are NHI Mgmt Group recommendations drawn from the platform documentation, not ATT&CK mappings.

For Android settings detail, see the Android Enterprise Security Guide; for Apple, the iOS and iPadOS Enterprise Security Guide. Short-range channels are covered in the Bluetooth, RFID and NFC Security Guide.

Where identity fits

SMS is still a second factor and a recovery channel for many workforce and service accounts. Malware that reads SMS or notifications to take commands can read one-time passcodes in the same way, so T1644 capability on a device is also a credential exposure. Treat a confirmed SMS-controlled implant as a compromise of every account whose OTPs reached that number: rotate, re-enrol on phishing-resistant authenticators and review recent sign-ins. See Mobile Access Credentials and the SIM swap guide for related number-based risks.

How to implement

1. Inventory permission grants. Pull SMS permission and notification access state for every managed Android device; for iOS, pull OS version, supervision and profile lists.
2. Build an allow list. Approve default SMS apps, wearable companions and enterprise messaging; everything else with these rights is a finding.
3. Run in report-only mode for two weeks. Raise tickets rather than block, to find legitimate business apps that need an exception.
4. Enforce. Block unknown sources, mark devices non-compliant when an unapproved listener appears, and gate access to corporate apps on compliance.
5. Prepare forensics. Agree a consent-based MVT process and evidence handling with legal and HR before you need it.
6. Roll back safely. If enforcement breaks a business workflow, move the specific app to the allow list rather than relaxing the whole policy.

Measuring it

• Percentage of managed Android devices with no unapproved notification listener or SMS permission holder.
• Median time from an unapproved grant appearing to device quarantine.
• Percentage of fleet within the supported OS and patch window.
• Number of high-risk users with Lockdown Mode or Advanced Protection enabled against the number identified.
• Share of accounts still using SMS one-time passcodes on corporate numbers.

Common failure patterns

• Network-only monitoring. A mobile programme that measures C2 coverage by proxy logs alone has no view of SMS or NFC.
• Ignoring notification access. Teams audit runtime permissions but not the separate notification access list, which is where SharkBot-style abuse sits.
• Granting "restricted settings" on request. Helpdesk scripts that tell users to allow restricted settings to fix an app remove a key Android 13 protection.
• Assuming iOS is out of scope. Pegasus for iOS shows SMS C2 on iOS after exploitation; patch cadence and Lockdown Mode matter for exposed staff.
• Leaving SMS OTP in place for privileged users. An SMS-reading implant then becomes an account takeover tool.

Framework mapping

Practitioner checklist

• Pull SMS permission and notification access grants for every managed Android device.
• Maintain an allow list of apps approved to hold those rights.
• Block installs from unknown sources and keep Play Protect on.
• Enforce minimum OS and patch levels on Android and iOS through MDM compliance.
• Offer Lockdown Mode or Advanced Protection to high-risk users, enrolling devices in MDM first.
• Remove SMS one-time passcodes for privileged and service-owner accounts.
• Agree a consent-based MVT forensic process before an incident.
• Restrict Bluetooth and NFC on single-purpose and kiosk devices.

Standards and references

• MITRE ATT&CK: Out of Band Data, Mobile T1644
• MITRE ATT&CK: User Guidance, Mobile M1011
• Google Play Console Help: Use of SMS or Call Log permission groups
• Android Help: Allow restricted settings
• Android Developers: Play Integrity API integrity verdicts
• Apple Support: About Lockdown Mode
• Mobile Verification Toolkit documentation
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Command and Control (C2) Guide · Mobile Malware Guide · Mobile App Permissions