Mobile T1471 Data Encrypted for Impact: Limiting Android Ransomware Damage

Mobile ransomware does not need to break the operating system: an app with broad storage access can encrypt the photos, downloads and documents in shared storage and then demand payment for the key. MITRE ATT&CK for Mobile T1471 Data Encrypted for Impact (tactic TA0034 Impact) covers encrypting files on a mobile device either for ransom or to make them permanently inaccessible. ATT&CK v20 maps the technique to Android only. This guide explains why, what the recorded malware did, how Android's storage model limits the damage, and the MDM, detection and backup measures that matter. It is for mobile and endpoint engineers and incident responders. The Enterprise equivalent is covered in MITRE ATT&CK T1486 Data Encrypted for Impact, and the matrix overview in the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Android only in ATT&CK. All three recorded procedure examples (Xbot, Anubis, S.O.V.A.) are Android malware; ATT&CK lists no iOS procedure or platform mapping for T1471.
• Shared storage is the target. Xbot encrypted files on external storage such as the SD card; app-private internal storage is not readable by other apps.
• Storage permissions are the gate. Since Android 10 scoped storage limits what an app can reach, and All files access (MANAGE_EXTERNAL_STORAGE) is a special permission the user must grant in Settings.
• The infection comes first. These families arrive as malicious apps, so blocking unknown-source installs prevents most cases.
• Backups decide the outcome. Business data that lives in managed cloud services, not only on the device, makes a wipe and re-enrol the fastest recovery.

How T1471 works

ATT&CK describes an adversary encrypting files stored on a mobile device to prevent the user from accessing them, either to extract payment for decryption or to render data permanently inaccessible where the key is not saved or transmitted. The recorded examples:

Anubis and S.O.V.A. are banking trojans, so encryption sits alongside credential theft and overlay attacks rather than being the whole business model. See the Android Banking Trojans Guide.

Android and iOS: why the mapping differs

The iOS column describes Apple's sandbox design; it is not a claim that iOS cannot be affected, only that ATT&CK records no case. Treat iOS data loss risk through the same backup and app vetting controls.

What Android's storage model limits

• Internal app-specific storage: files under getFilesDir() and getCacheDir() need no permission and other apps cannot access them. Managed work apps should keep business data here.
• External app-specific storage: getExternalFilesDir() is also not accessible to other apps on API 19 and higher, but it lives on a volume the user can remove.
• Shared media: apps targeting Android 10 and higher see their own media by default; reading other apps' media needs a runtime storage permission, which the user is asked to grant.
• All files access: MANAGE_EXTERNAL_STORAGE, introduced in Android 11, grants read and write access to all files in shared storage and the root of USB OTG drives and SD cards, but not other apps' Android/data/ directories. The user grants it on the "Allow access to manage all files" settings screen. Google Play has evaluated apps requesting it since May 2021 and limits it to uses such as file managers, backup and anti-virus.

The defender's reading: a ransomware app needs either broad storage permission or All files access to do meaningful damage to shared storage, and both are visible in the app's requested permissions. See the Mobile App Permissions guide.

Prevention

ATT&CK lists no mitigation object directly against T1471 in v20, so prevention comes from blocking the malicious app and limiting what it can touch:

1. Block sideloading. Set the Android Management API advancedSecurityOverrides.untrustedAppsPolicy to DISALLOW_INSTALL (the default) on fully managed devices; on personally owned devices with a work profile, ALLOW_INSTALL_IN_PERSONAL_PROFILE_ONLY keeps the work profile closed.
2. Keep Play Protect enforced. googlePlayProtectVerifyApps at VERIFY_APPS_ENFORCED stops users switching verification off.
3. Use a work profile. Work apps and data sit apart from personal apps, so a personal-side ransomware app does not reach managed data.
4. Restrict removable media where not needed. mountPhysicalMediaDisabled stops users mounting external media, and deviceConnectivityManagement.usbDataAccess can block USB file transfer on company-owned devices.
5. Vet permissions in the managed store. Flag any app requesting MANAGE_EXTERNAL_STORAGE and approve it only where the use is clear, such as a file manager the business has chosen.
6. Keep business data off the device as the master copy. Use managed cloud storage and email so the device holds a synchronised copy, not the only one.

Testing and rollback: apply the work profile and install restrictions to a pilot ring first; check that line-of-business apps distributed outside Play are moved into the managed store before closing unknown sources.

Detection

ATT&CK v20's DET0678 Detection of Data Encrypted for Impact is Android only. It correlates app permission grant state and managed package inventory with dynamic analysis of storage API use, such as bulk ContentResolver, DocumentProvider or Storage Access Framework input and output above a file modification threshold. In practice:

• App vetting: static and dynamic analysis of new apps for storage-wide permissions combined with cryptographic API use.
• MDM inventory: apps not deployed through the managed store, and apps holding All files access.
• MTD verdicts: known ransomware or banking trojan detections, sideloaded app alerts.
• User reports: files that will not open, changed extensions, or a ransom message; route these to the security team, not just the help desk.

Metrics

• Percentage of Android devices with unknown-source installs blocked in the work context.
• Count of managed apps holding All files access, each with an approved justification.
• Percentage of business data stored in managed cloud services rather than device-only storage.
• Time from user report to device isolation and re-enrolment.

Response and recovery

1. Isolate: remove network access to corporate resources through conditional access, and disconnect the device from sync to stop encrypted files replacing good copies in cloud storage.
2. Preserve: capture the app package name, permissions and ransom note; acquire evidence if the case may be reported. See the Mobile Forensics Guide.
3. Do not pay: payment does not remove the malware, and families such as Anubis also steal credentials.
4. Reset: wipe the work profile or the device and re-enrol, then restore data from managed cloud versions.
5. Rotate credentials: Anubis and S.O.V.A. also steal credentials, so reset passwords and revoke tokens used on the device.

Where identity fits

Because the recorded T1471 families are also credential stealers, treat every case as a possible account compromise: revoke refresh tokens, re-register authenticators that lived on the device and check for sign-ins from new locations. Apps that cache API keys in shared storage expose them to the same broad-permission malware; keep tokens in the Android Keystore and app-private storage. See the Secrets in Mobile Apps Guide.

Common failure patterns

• Sideloading left open for one internal app: the exception opens the device to every lookalike APK as well.
• Device as the only copy: field photos and documents saved only to shared storage are lost when encrypted.
• Sync spreading the damage: encrypted files synchronised to cloud storage overwrite good versions unless versioning is on.
• Treating it as a nuisance: wiping the phone without rotating credentials misses the banking trojan side of the same malware.

Framework mapping

Practitioner checklist

• Block unknown-source installs in the work context and enforce Play Protect verification.
• Use work profiles on personally owned Android devices.
• Review and justify every managed app holding All files access.
• Keep business data in managed cloud storage with versioning turned on.
• Disable external media mounting where users do not need it.
• Write a mobile ransomware runbook that includes credential rotation.
• Apply the same backup and app vetting controls to iOS even though ATT&CK records no iOS case.

Standards and references

• MITRE ATT&CK: T1471 Data Encrypted for Impact (Mobile)
• Android Developers: Data and file storage overview
• Android Developers: Manage all files on a storage device
• Apple Platform Security: Security of runtime process in iOS and iPadOS
• Google: Android Management API policies reference
• Google: Google Play Protect
• MITRE ATT&CK: S0422 Anubis

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · MITRE ATT&CK T1486 Data Encrypted for Impact · Mobile Malware Guide · Android Enterprise Security Guide · Mobile T1662 Data Destruction · Mobile T1641 Data Manipulation