Mobile T1533 Data from Local System: Detecting Data Collection on Android and iOS

Once malicious code runs on a phone, the files, databases and tokens stored on the device are the first thing it takes. MITRE ATT&CK for Mobile records this as T1533 Data from Local System, a Collection technique listed for Android and iOS, with more than fifty procedure examples covering commodity Android malware, commercial surveillance tools and the iOS campaign Operation Triangulation. This guide explains what local system data means on each platform, what the OS already restricts, which signals reveal bulk collection, and how to reduce the value of what is stored. It is for mobile security engineers, MDM and MTD administrators, mobile app developers and incident responders.

Key takeaways

• Local data includes credentials. ATT&CK lists authentication tokens, the keyboard cache, Wi-Fi passwords and photos as examples; Gooligan stole tokens usable across Google applications, as ATT&CK records.
• Reach depends on privilege. ATT&CK notes that access to local system data often requires escalated privileges, and on Android external storage access may need storage permissions; permission review is a primary control.
• Both platforms are affected. Android families dominate the procedure list, but ATT&CK records Operation Triangulation stealing data from SQLite databases on iOS, and LightSpy collecting messaging app files and browser history.
• No mitigations are mapped in ATT&CK. Prevention comes from OS sandboxing, scoped storage, current OS versions, app source control and how your own apps store data.
• Detection is mostly vetting and forensics. ATT&CK's DET0713 relies on app vetting and forensic acquisition for file access; iOS detection is described primarily as a vetting and controlled analysis task.

What T1533 covers on mobile

ATT&CK describes the technique as searching local system sources, such as file systems or local databases, for files of interest and sensitive data before exfiltration. As of ATT&CK v20.1 it is listed for Android and iOS with no sub-techniques. It is distinct from T1636 Protected User Data, which covers data behind OS permission prompts such as contacts, calendar and SMS, and from T1634 Credentials from Password Store. It mirrors Enterprise T1005; for the wider collection picture see the ATT&CK Collection Tactic Guide and the MITRE ATT&CK for Mobile Guide.

What the platforms already restrict

These controls explain why so many procedure examples in ATT&CK target external storage, photos and browser data: they are the parts of the filesystem a permission grant opens up. Collection from other apps' private databases generally needs root, a jailbreak-level exploit or a privileged system component, which is what the iOS campaign cases show.

Procedure examples from ATT&CK

A selection of the procedure examples ATT&CK records, grouped by the data taken, as ATT&CK states them.

Several families, including Drinik, VajraSpy and DocSwap, are recorded requesting or checking storage permissions such as READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE. Permission requests that do not fit the app's purpose are an early warning.

How to reduce exposure

1. Control app sources. Restrict installs to managed Google Play or the App Store and MDM-managed apps. Keep Play Protect on for Android fleets.
2. Review storage permissions. Report apps holding all-files access or legacy storage permissions; remove or replace them. Prefer the system photo and document pickers.
3. Keep OS versions current. Scoped storage and newer permission models only help on current versions. ATT&CK mitigations M1001 Security Updates and M1006 Use Recent OS Version apply; the privileged-access cases (Triangulation, INSOMNIA) relied on exploits that updates address.
4. Separate corporate data. Use Android Enterprise work profiles and iOS managed apps so personal apps cannot read work files. See the Mobile Device Management Security Guide.
5. Harden high-risk users. Offer Lockdown Mode on iOS (iOS 16 and later) to people likely to be targeted by commercial spyware. See the Mobile Communications Protection for High-Risk Individuals Guide.
6. Store less, and store it well, in your own apps. Follow OWASP MASVS-STORAGE: keep sensitive data in internal storage or the Keystore and Keychain, never in shared storage, logs or backups.

Detection and measurement

ATT&CK's detection strategy DET0713 Detection of Data from Local System treats management state queries as periodic observations, not real-time events. For Android it correlates permission grant state (DevicePolicyManager.getPermissionGrantState() and manifest review) with app vetting or forensic evidence of an app reading files across many directories in a background or low-interaction state, and with runtime traces of ContentResolver or Storage Access Framework queries across user data paths outside the app's sandbox. For iOS it describes detection primarily during app vetting or controlled analysis: entitlements and Info.plist privacy usage keys, bulk reads from Photos, Files providers or iCloud Drive in the background, and broad data access without a user-initiated document picker.

• Permission drift: alert when a managed app update adds storage or media permissions without a matching feature.
• App vetting: run new and updated apps in instrumented analysis and flag background bulk reads.
• Network correlation: Android Enterprise network logging records DNS and TCP connection events per package; correlate with collection windows found in vetting.
• Forensics: MVT supports iOS backups, filesystem dumps and sysdiagnose files, and Android backups and intrusion logs, and checks them against published indicators. See the Mobile Verification Toolkit (MVT) guide.

Metrics:

• Number of managed apps with all-files or legacy storage access.
• Percentage of devices on a supported OS version within 30 days of release.
• Percentage of app updates passing vetting with a background data access check.
• Time from MTD high-risk alert to containment.
• Number of mobile tokens revoked after device incidents, and time to revoke.

Where identity fits

The first example ATT&CK gives for local system data is authentication tokens. A refresh token or API key read from app storage lets an attacker reach the account or backend from anywhere, long after the device is cleaned. Keep tokens in the Android Keystore or iOS Keychain, use short-lived access tokens and sender-constrained tokens where your identity provider supports them, and include token and session revocation in every mobile incident. See the OAuth for Native and Mobile Apps Guide and the Mobile Access Credentials guide.

Common failure patterns

• Corporate files in shared storage. Documents saved to shared download or media folders are readable by any app with the right media or storage grant.
• Tokens in plain preferences or files. Readable token stores turn a device compromise into an account compromise.
• Old permission grants carried forward. Apps that targeted older SDKs keep broad access until reviewed.
• Treating iOS as out of scope. Triangulation and LightSpy show local data theft on iOS; high-risk users need the same forensic readiness on both platforms.
• No revocation step in response. Wiping the device without revoking tokens it held leaves the stolen data usable.

Framework mapping

Practitioner checklist

• Restrict app sources and keep Play Protect on for Android fleets.
• Report and review apps with all-files or legacy storage access each quarter.
• Keep corporate data in work profiles or managed apps only.
• Enforce a minimum supported OS version through MDM compliance.
• Vet app updates for new storage permissions and background bulk reads.
• Store tokens in Keystore or Keychain and document revocation for each mobile app.
• Offer Lockdown Mode to high-risk iOS users.
• Acquire and analyse suspected devices with MVT before wiping.

Standards and references

• MITRE ATT&CK: T1533 Data from Local System (Mobile)
• Android Developers: Data and file storage overview
• Apple Platform Security: Security of runtime process in iOS, iPadOS and visionOS
• Apple: App Review Guidelines
• Google Play: Device and Network Abuse policy
• Android Developers: Network activity logging
• Apple Support: About Lockdown Mode
• Amnesty International Security Lab: Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Forensics Guide · Mobile App Permissions · Mobile Malware Guide · Mobile Spyware Infection Response Playbook