Mobile T1582 SMS Control: Limiting SMS Abuse on Android Devices

Mobile malware that can send, delete or alter text messages turns a single infected phone into a spreader of phishing links, a hidden command channel and a way to quietly remove the SMS warnings and codes that would expose fraud. MITRE ATT&CK for Mobile records this as T1582 SMS Control, an Impact technique listed for Android only. This guide explains the Android permissions and default SMS app model the technique depends on, what ATT&CK's procedure examples show, why iOS apps cannot do the same, and how to prevent, detect and respond on managed devices. It is written for mobile and endpoint security teams, SOC analysts and identity teams who still rely on SMS for one-time codes, and builds on the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Two levels of control. Any Android app holding SEND_SMS can send texts; only the default SMS app receives SMS_DELIVER_ACTION and can write to the SMS provider, which is what allows editing, hiding and deleting messages.
• Default SMS app changes are a high-value signal. ATT&CK records SharkBot changing the device's default SMS handler; a work device whose default SMS app is not the expected one should be investigated.
• Google Play restricts SMS permissions. Play policy limits the SMS permission group to default handlers and a short list of exceptions, so most apps requesting them arrive from outside Play.
• iOS apps cannot send texts silently. Apple's MessageUI framework only presents a compose sheet for the person's approval, and ATT&CK lists no iOS platform for T1582.
• SMS is a weak authenticator. Malware that can read and delete SMS defeats SMS one-time codes, so move high-value accounts to phishing-resistant MFA.

What T1582 covers

ATT&CK describes T1582 as adversaries deleting, altering or sending SMS messages without user authorisation, to hide command and control (C2) messages, spread malware or cause other external effects. It is achieved by requesting the RECEIVE_SMS or SEND_SMS permissions, and, if the app is the device's default SMS handler, by registering for the SMS_DELIVER broadcast, which allows writing to the SMS content provider and so inserting, modifying or deleting arbitrary messages.

The Android SMS permission model

Android introduced the default SMS app in Android 4.4. Android's developer blog post for that release states that only the app receiving the SMS_DELIVER_ACTION broadcast, the user-selected default SMS app, can write to the SMS provider. Other apps can observe new messages through SMS_RECEIVED_ACTION but cannot write to the provider. Any app with SEND_SMS can still send messages through SmsManager, and the system writes those sent messages into the provider for it.

Google Play's SMS and Call Log permissions policy restricts READ_SMS, RECEIVE_MMS, RECEIVE_SMS, RECEIVE_WAP_PUSH, SEND_SMS and WRITE_SMS to apps actively registered as the default SMS, Phone or Assistant handler, plus listed exceptions such as enterprise device management and SMS-based financial transactions, each declared in the Play Console and subject to review. The policy points developers to the SMS Retriever API, which handles verification codes without any extra app permissions. An app outside those cases asking for SMS permissions is, by Play's own rules, unusual.

What the procedure examples show

ATT&CK lists more than 30 software entries under T1582, almost all Android banking trojans and spyware. The table groups representative examples as ATT&CK states them.

For how these families are delivered and monetised, see the Android Banking Trojans Guide and the Vishing and Smishing Guide.

iOS: why the technique does not apply the same way

ATT&CK lists Android only for T1582. Apple's MessageUI documentation states that MFMessageComposeViewController displays the standard message composition interface, that the app can only construct the initial message and present it for a person's approval, that the person may cancel it, and that if they choose to send, the Messages app takes responsibility for sending. A third-party iOS app therefore cannot send a text without the user tapping Send. The iOS risks around SMS sit elsewhere: smishing that reaches the user, and SIM swap at the carrier, covered in the SIM Swap Fraud Guide.

Prevention on managed Android devices

• Block untrusted installs: on Android Enterprise, keep advancedSecurityOverrides.untrustedAppsPolicy at DISALLOW_INSTALL (the documented default) and googlePlayProtectVerifyApps at VERIFY_APPS_ENFORCED. Most SMS-abusing malware arrives as a side-loaded APK; see APK sideloading.
• Deny SMS permissions by policy: the Android Management API's permissionGrants can set android.permission.SEND_SMS and RECEIVE_SMS to DENY for managed apps that have no business need, overriding defaultPermissionPolicy.
• Disable SMS where it is not needed: the policy field smsDisabled disables sending and receiving SMS on the device, which suits data-only kiosks, scanners and shared devices. See the Kiosk and Shared Device Security Guide.
• User guidance (M1011): ATT&CK's mitigation is to tell users to be careful which apps they grant SMS access, and not to change the default SMS handler to an app they do not recognise. Put that in onboarding material for BYOD users, whose personal profile your MDM may not control.
• Review permissions in app vetting: treat SMS permissions on any non-messaging app as a finding; see Mobile App Permissions.

Detection

ATT&CK's DET0599 analytic correlates SMS permission state or the default SMS role with SMS sending, interception, message database changes or concealment by an app outside expected messaging workflows, especially from background or locked-device state without recent user interaction.

Two signals outside the device also help. Carriers and business SMS providers can flag unusual outbound SMS volume from a corporate line, and users reporting that "everyone in my contacts got a strange text from me" is a classic sign of FluBot-style spreading. Treat such reports as an incident, not a help desk ticket.

Where identity fits

SMS one-time codes and SMS-delivered recovery links are only as safe as the phone's message store. Malware with RECEIVE_SMS can read codes as they arrive, and malware holding the default SMS role can delete the message so the user never sees it. That makes SMS unsuitable for privileged users, administrators and any account whose compromise would expose service credentials or API keys. Use phishing-resistant methods instead; see the Phishing-Resistant MFA Guide and the Authenticator Apps and OTP Guide. If your own apps verify phone numbers, use the SMS Retriever API rather than requesting SMS permissions.

Response

1. Contain: mark the device non-compliant and block corporate access; on the carrier side, consider suspending outbound SMS for the line if spreading is under way.
2. Identify the app: from MDM inventory, find apps holding SMS permissions or the default SMS role that are not on your baseline.
3. Remove and reset: uninstall the app, restore the expected default SMS app, and factory reset if the app resists removal or used accessibility abuse to protect itself.
4. Revoke and re-enrol credentials: treat any SMS codes received during the infection window as exposed: reset passwords, revoke sessions and replace SMS MFA registrations.
5. Warn recipients: where the device sent phishing texts, tell affected contacts and, for staff, issue an internal warning with the message text.

Measuring it

• SMS permission exposure: number of managed apps holding SEND_SMS or RECEIVE_SMS outside an approved list (target zero).
• Default SMS baseline: percentage of managed devices whose default SMS app is on the approved list.
• SMS MFA reliance: percentage of privileged accounts still using SMS as a second factor (target zero).
• Response time: median time from detection or user report to device containment.

Common failure patterns

• Personal profile blind spot: BYOD work profiles protect corporate apps, but malware in the personal profile can still read SMS codes for corporate accounts.
• SMS codes for admins: privileged and break-glass accounts still using SMS one-time codes.
• No default SMS baseline: MDM collects app inventory but nobody checks which app holds the SMS role.
• Reports treated as spam: contacts reporting odd texts from a colleague are not escalated to security.
• Over-broad permission grants: defaultPermissionPolicy set to GRANT for convenience, granting SMS permissions to any managed app that asks.

Framework mapping

Practitioner checklist

• Keep untrusted installs blocked and Play Protect verification enforced on every Android Enterprise policy.
• Deny SEND_SMS and RECEIVE_SMS by policy to managed apps without a documented need.
• Set smsDisabled on kiosks, scanners and shared devices that never need SMS.
• Baseline the default SMS app and alert on changes.
• Remove SMS one-time codes from privileged accounts and move them to phishing-resistant MFA.
• Escalate user reports of unexpected texts sent from a colleague's number as incidents.
• Include SMS permission and default handler guidance in BYOD onboarding.

Standards and references

• MITRE ATT&CK: SMS Control, Mobile technique T1582
• Android Developers Blog: Getting Your SMS Apps Ready for KitKat
• Google Play: Use of SMS or Call Log permission groups
• Apple Developer: MFMessageComposeViewController
• Google: Android Management API policy reference
• Google: SMS Retriever API overview
• Google: Use Google Play Protect to help keep your apps safe

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Malware Guide · Android Enterprise Security Guide · Phone Number Fraud · Mobile T1616 Call Control · Mobile T1517 Access Notifications · Mobile Impact Tactic