Mobile ATT&CK Impact Tactic (TA0034) Guide: Limiting Damage on Android and iOS Devices

On a phone, Impact rarely looks like a ransom screen: it looks like SMS sent without the user knowing, calls rerouted to a fake bank, taps the user never made and a factory reset that erases the evidence. ATT&CK for Mobile v20 describes the Impact tactic (TA0034) as the adversary "trying to manipulate, interrupt, or destroy your devices and data", and notes that mobile mission objectives include toll fraud, destruction of device data and locking the user out of the device. This hub covers all ten current Impact techniques on Android and iOS, how they chain with earlier tactics, which ones deserve attention first and how to detect and limit them with mobile device management (MDM), mobile threat defence (MTD) and operating system controls. It is written for mobile security engineers, SOC analysts and endpoint owners. Each technique has its own deep guide, linked from the table below; for the wider matrix see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Mobile Impact is mostly fraud, not encryption. In the ATT&CK Mobile v20 dataset SMS Control (T1582) has 33 recorded uses, Call Control (T1616) 17 and Generate Traffic from Victim (T1643) 16, against 3 for Data Encrypted for Impact (T1471).
• Accessibility abuse is the engine. Input Injection (T1516), with 14 uses, lets banking trojans perform transfers on the victim's own device, which defeats device-binding and one-time passcode checks.
• Destruction is used to hide fraud. BRATA performs a factory reset after theft (T1662), so Impact is often also the attacker's clean-up step.
• Android dominates, but not completely. Seven of the ten techniques list Android only; Network Denial of Service, Endpoint Denial of Service and Generate Traffic from Victim list both Android and iOS.
• The controls are upstream. MITRE maps mostly User Guidance (M1011), Enterprise Policy (M1012) and Use Recent OS Version (M1006) here; in practice that means app allow-listing, accessibility allow-lists and patch-level gating, set before the malware arrives.

What the Impact tactic means on a mobile device

Enterprise Impact (TA0040) is dominated by ransomware and wipers against servers. Mobile Impact (TA0034) is different in three ways. First, the device is a payment and authentication instrument, so the most profitable outcome is to act as the user: send SMS, place or intercept calls, approve transfers. Second, the operating system sandbox makes bulk file encryption hard without elevated privileges, so lock-screen ransom and denial of service are more common than true encryption. Third, the user can recover the device quickly by factory reset, so attackers who want to stop an investigation destroy data themselves.

MITRE's tactic description also covers "techniques used by the adversary to execute his or her mission objectives but that do not cleanly fit into another category such as Collection". That is why Call Control appears under Collection, Impact and Command and Control at once, and Input Injection under Defense Evasion and Impact.

All Impact techniques in ATT&CK Mobile v20

The table lists every current technique and sub-technique under TA0034. Use counts are the number of software, group and campaign "uses" relationships in the ATT&CK Mobile v20.0 STIX bundle, excluding revoked and deprecated objects, counted per technique ID (sub-techniques separately). Counts reflect what MITRE has documented, not prevalence in the wild.

How adversaries chain Impact

Impact on mobile is the last link of a short chain. Counting co-occurrence in the same v20 bundle (software that uses both techniques) shows the pattern:

• Overlay, intercept, act: of the 39 software entries that use Input Capture (T1417 or its sub-techniques), 20 also use SMS Control and 11 also use Input Injection. The banking trojan model is: arrive through Phishing or a dropper, gain Accessibility via Abuse Accessibility Features, capture credentials with overlays, intercept SMS one-time passcodes, then use Input Injection to complete the transfer from the trusted device. See the Android Banking Trojans Guide.
• Notifications plus SMS: of the 14 software entries that read notifications (T1517), 8 also control SMS, so one-time codes delivered by push or text are both exposed.
• Telephone-oriented fraud: Fakecalls breaks the connection when the victim dials their bank and shows a fake call screen, routing the call to the fraudster (T1616). Defences that rely on "call us back on the number you trust" fail on an infected handset.
• Destroy after theft: 3 of the 4 Data Destruction entries also collect local data (T1533). BRATA's factory reset follows the fraud so the user and investigators lose the artefacts.
• Billing and ad fraud: 6 of the 16 Generate Traffic from Victim entries also use Download New Code at Runtime, which keeps the store-reviewed app clean while fraud modules arrive later.

Where to start: ranking the techniques for defenders

1. T1516 Input Injection: the highest-loss technique because the fraud originates from the genuine device and session. One control (an accessibility service allow-list on managed devices) removes most of it.
2. T1582 SMS Control: the most documented technique and the one that turns SMS one-time passcodes into attacker property. Prioritise moving off SMS authentication rather than detection alone.
3. T1616 Call Control: critical for banks, contact centres and any process that verifies by callback.
4. T1662 Data Destruction and T1640 Account Access Removal: lower volume, but they destroy evidence and lock the user out mid-incident; plan forensic capture and remote lock procedures for them.
5. T1643 Generate Traffic from Victim: mainly a cost and reputation issue for consumer apps, and an indicator that a device runs fraudware worth removing.
6. T1642, T1471, T1464 and T1641: keep coverage, but on current OS versions these have narrower paths (for example, MITRE notes that after Android 7 only device or profile owners can reset the passcode).

Detection priorities

Each technique has a v20 detection strategy whose analytics name mobile log sources. The useful pattern is that most Impact detection is a permission or state signal, raised before the damage, rather than a behaviour observed during it.

MDM tells you configuration and permissions; MTD tells you app reputation and device risk; neither sees inside the sandbox on iOS. For suspected targeted compromise, capture evidence before any reset using the Mobile Verification Toolkit (MVT), which Amnesty International's Security Lab released in July 2021 for consensual forensic analysis of Android and iOS devices.

Metrics that show coverage is working

• Accessibility exposure: percentage of managed Android devices with an enforced accessibility service allow-list.
• SMS dependence: share of workforce and customer authentications still using SMS one-time passcodes.
• Patch currency: percentage of devices within the supported OS and security patch level set by policy.
• Sideload rate: number of devices with apps from outside approved stores, trending down.
• Evidence capture: percentage of mobile incidents where a forensic capture was taken before reset.

Mitigation priorities and OS controls

MITRE maps only three mitigation IDs across this tactic (M1006, M1011 and M1012), and two techniques, T1464 and T1471, have none mapped at all. The practical controls are below; see ATT&CK Mitigations for the wider mitigation model.

For platform settings see the Android Enterprise Security Guide and the iOS and iPadOS Enterprise Security Guide. Google Play policy limits SMS and Call Log permissions to apps registered as the default SMS, Phone or Assistant handler, with reviewed exceptions, which is why most SMS Control malware arrives by sideloading or droppers.

Decision guidance

• Corporate-owned fully managed devices: enforce accessibility and input method allow-lists, block sideloading and gate on patch level. This removes most Impact paths.
• BYOD with a work profile: profile policy covers the work side only. Protect the business by removing SMS one-time passcodes and requiring compliant-device signals for high-risk actions, rather than trying to police the personal side.
• Consumer apps (banking, wallets): you do not control the device. Detect enabled accessibility services and active calls during sensitive flows, add transaction signing, and treat device binding as a signal, not proof. See the Mobile Banking App Security Guide.
• Small organisations: start with an MDM baseline and a store-only app policy; MTD can follow. Large organisations should feed MDM and MTD events into the SIEM and correlate with identity provider sign-ins.

Where identity fits

Most mobile Impact is identity abuse delivered through a device. SMS Control and Call Control defeat possession factors; Input Injection runs inside an authenticated session; Account Access Removal targets the device credential itself. The device is also a non-human identity in its own right: its MDM enrolment certificate, managed app tokens and device compliance claim are what conditional access trusts. When malware acts through the genuine device, those signals stay green. Pair device signals with phishing-resistant authentication and step-up for high-value actions; see the Mobile Access Credentials guide.

Common failure patterns

• Treating SMS one-time passcodes as a second factor on the same handset: SMS Control malware reads and deletes them before the user sees them.
• Allowing any accessibility service on managed Android: one permission grant gives the attacker remote hands on the device.
• Factory resetting first: wiping a suspected device before capture destroys the only evidence of what was taken, which is exactly what BRATA's reset intends.
• Trusting callback verification: Call Control lets malware intercept the outgoing call to the bank's real number.
• No patch-level gate: old OS versions keep removed attack paths, such as device administrator passcode resets, alive.
• MDM without monitoring: permissions and admin activations are recorded but nobody alerts on them.

Framework mapping

Practitioner checklist

• Enforce an accessibility service and input method allow-list on every managed Android device.
• Block apps from unknown sources and untrusted configuration profiles on managed devices.
• Set a minimum OS version and security patch level in conditional access, and retire devices that no longer receive updates.
• Remove SMS and voice one-time passcodes from workforce sign-in and high-value customer flows.
• Alert on device administrator activation, default SMS or dialler changes and unexpected factory resets.
• Keep business data in managed apps that sync to enterprise storage, so a wiped device loses nothing important.
• Write a mobile incident procedure that captures evidence with MVT before any reset.
• Offer Lockdown Mode or Android Advanced Protection to high-risk staff, and plan MDM enrolment around Lockdown Mode.
• Review each technique guide linked above against your MDM and MTD coverage once a year.

Standards and references

• MITRE ATT&CK: Impact, Mobile (TA0034)
• MITRE ATT&CK: Mobile Matrix
• NIST: SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• Google Play: Use of SMS or Call Log permission groups
• Google: Allow restricted settings on Android
• Apple: About Lockdown Mode
• Amnesty International Security Lab: Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide, Mobile Malware Guide, Mobile Threat Defense Buyer's Guide, Mobile Device Management Security Guide, Mobile ATT&CK Collection Tactic.