Mobile T1409 Stored Application Data is an adversary reading the files, databases, preferences and tokens that other apps keep on a phone, such as chat histories, account details and session cookies. MITRE ATT&CK for Mobile v20 lists it under Collection for Android and iOS, and is precise about when it is possible: mobile sandboxing means an attacker can only reach another app's data if that app writes to unprotected external storage, if it stores internal files with insecure permissions, or if the attacker has root. That makes T1409 unusual: defenders can reason about exactly which conditions to close. This guide is for mobile security engineers, app developers, MDM administrators and incident responders. For the matrix overview see the MITRE ATT&CK for Mobile Guide.
Key takeaways
- Three preconditions, three controls. External storage, world-readable internal files and root access are the only routes ATT&CK lists; each has a matching control.
- Modern Android closes two of them. Android 9 blocks world-accessible sharing for apps targeting it, and scoped storage from Android 10 limits external storage access to an app's own directory and media.
- Root turns T1409 into full collection. Pegasus, Operation Triangulation, Exodus and others read messaging databases after escalating, so patching and attestation protect app data too.
- iOS encrypts app data by default. Third-party app files default to Data Protection Class C; sensitive files can be raised to Class A.
- Tokens are stored application data. S.O.V.A. gathered session cookies and FlyTrap collected Facebook login tokens; a stolen token skips MFA.
What T1409 covers and when it is possible
ATT&CK describes T1409 as accessing and collecting application data resident on the device, often from popular apps such as Facebook, WeChat and Gmail. It has no sub-techniques. The closest Enterprise behaviour is Data from Local System; on a phone the sandbox is what makes the difference.
| Precondition (ATT&CK) | Android position | iOS position | Control |
|---|---|---|---|
| App stores files in unprotected external storage | Apps targeting Android 10 and higher get scoped storage by default: access to their own external directory and media they created. From Android 11, MANAGE_EXTERNAL_STORAGE grants broad file access | Apps are confined to their own container (App Review Guideline 2.5.2 also bars reading or writing outside it) | Keep sensitive data in internal, app-specific storage; review apps holding broad storage permissions |
| App stores internal files with insecure permissions | Apps targeting Android 9 and higher cannot share data with other apps using world-accessible Unix permissions (per-app SELinux domains) | Sandboxed containers; files encrypted under Data Protection classes | Raise target SDK; share through content providers, not file modes |
| Adversary gains root | Any app data is readable | Any app data the device has unlocked is readable | Patching, attestation, compromised device detection; see the T1068 Exploitation for Privilege Escalation guide for the Enterprise equivalent |
Procedure examples and what they teach
ATT&CK v20 records more than thirty entries for T1409. A representative set, as ATT&CK states them:
| Software or campaign | Platform | Data collected | Lesson |
|---|---|---|---|
| Operation Triangulation (C0054) | iOS | Data from WhatsApp and Telegram | After kernel compromise, end-to-end encryption does not protect data at rest on the device |
| Pegasus for iOS (S0289) and for Android (S0316) | iOS, Android | Skype call data from database files; WhatsApp, Facebook and Twitter messages | Commercial spyware targets messaging stores; see the Commercial Spyware Guide |
| Pallas (S0399) | Android | Messages and decryption keys for messaging apps | Keys stored next to data are collected with it |
| FlexiSpy (S0408) | Android | Used a FileObserver on Skype and WeChat databases and shared preferences | Stalkerware watches app files for changes |
| S.O.V.A. (S1062), FlyTrap (S1093) | Android | Session cookies; Facebook ID, email, cookies and login tokens | Session material is the target, not only content |
| YiSpecter (S0311) | iOS | Contacts and authorisation tokens of the QQ messenger | iOS malware also targets stored tokens |
| SpyDealer (S0324) | Android | Data from over 40 apps | Root plus a target list scales collection |
Prevention
- Patch and attest (M1006 and root prevention): ATT&CK lists Use Recent OS Version as the mitigation, because Android 9 stopped apps reading or writing other apps' internal storage regardless of permissions. Enforce minimum OS and patch levels in MDM, and gate access on Play Integrity or managed device attestation so rooted or jailbroken devices lose access.
- Separate work data: Android work profiles and iOS managed apps keep corporate app data apart from personal apps and allow selective wipe. See the Android Enterprise Security Guide and the iOS and iPadOS Enterprise Security Guide.
- Restrict broad storage permissions: review apps holding MANAGE_EXTERNAL_STORAGE or legacy storage permissions on managed devices, and keep app sources restricted.
- Protect high-risk users: Apple Lockdown Mode (iOS 16 and later) and Android Advanced Protection narrow the delivery paths spyware uses to reach root in the first place.
For app developers: storing data so T1409 fails
| Data | Android | iOS |
|---|---|---|
| Files and databases | App-specific internal storage (getFilesDir, Room); not accessible to other apps and removed on uninstall | App container with Data Protection Class A (NSFileProtectionComplete) for sensitive files; Class C is the default for third-party app data |
| Tokens and keys | Android Keystore with hardware-backed, non-exportable keys; encrypt tokens at rest | Keychain with an accessibility class matching how the app uses the token |
| Shared files | Content providers with explicit grants, never world-readable modes | App groups and share extensions only where required |
| Secrets in the package | Never ship long-lived API keys or cloud credentials in the app; Cybernews found hard-coded secrets in 71 percent of 156,080 iOS apps it analysed, as described in the iOS Apps Leaking Hard-Coded Secrets breach analysis | |
OWASP MASVS-STORAGE covers secure storage and leakage of sensitive data, and is the test standard to apply. See the Mobile App Security Testing Guide.
Detection
ATT&CK v20 detection guidance for Android correlates permission grants from the device policy controller, file reads on external storage or files with 777 permissions seen through vetting or forensic acquisition, and network flow data. For iOS it uses MDM installed and managed application lists, host status and per-app VPN or network extension flows. File-level reads are a lab or forensic signal; fleet detection rests on the surrounding behaviour.
- Root or jailbreak state: a blank Play Integrity device verdict, failed managed device attestation or an MTD compromise alert means every app's data is exposed.
- Permission drift: new grants of broad storage, accessibility or notification access to non-catalogue apps.
- Exfiltration volume: uploads from a non-messaging app shortly after it gains storage access, visible in Android network logs or per-app VPN data.
- Token anomalies: server-side, the same session or refresh token used from a new device or network, which is often the first visible effect.
- Forensics: MVT checks iOS backups, filesystem dumps and sysdiagnose archives, and Android backups, against indicators for known spyware. See the Mobile Spyware Infection Response Playbook.
How to implement
- Raise the floor: enforce minimum OS versions so the Android 9 and 10 storage protections apply, and retire unsupported devices.
- Gate on attestation: pilot conditional access on compliance and attestation in report-only mode, then enforce in rings. Rollback is returning the rule to report-only.
- Separate data: deploy work profiles or managed apps for corporate data, with selective wipe tested.
- Review permissions: list apps with broad storage or accessibility rights; remove or vet those outside the catalogue.
- Fix your own apps: test against MASVS-STORAGE, move tokens into Keystore or Keychain, remove secrets from packages.
- Respond: on a confirmed collection case, preserve evidence, revoke every session and refresh token for apps on the device, and notify app owners whose data was exposed.
Decision guidance
- Company-owned or BYOD: on company-owned devices you can enforce attestation and collect logs; on BYOD, work profile or user enrolment protects corporate data without seeing personal apps.
- Small organisations: minimum OS, attestation-based access and managed apps cover most risk. Large or targeted organisations add MTD and a forensic route.
- Data Protection class choice: Class A protects best when locked but blocks background access; use it for data the app does not need while locked.
Where identity fits
Most valuable stored application data is identity material: OAuth refresh tokens, session cookies, API keys and messaging decryption keys. Because a token stolen from storage bypasses MFA, bind tokens to the device with hardware-backed keys or proof of possession where the identity provider supports it, keep them short-lived, and revoke on any compromise signal. See the Mobile Access Credentials guide.
Detection and measurement
- Share of devices on OS versions where scoped storage and per-app SELinux protections apply.
- Attestation pass rate, and time from failure to blocked access.
- Non-catalogue apps with broad storage permissions (target zero on company-owned devices).
- Your own apps passing MASVS-STORAGE tests, and secrets found in app packages (target zero).
- Median time to revoke tokens after a device compromise.
Framework mapping
| Framework | Reference | Relevance to T1409 |
|---|---|---|
| MITRE ATT&CK Mobile | M1006 Use Recent OS Version | Listed mitigation |
| NIST SP 800-53 Rev 5 | SC-28 Protection of Information at Rest; SC-39 Process Isolation | Encryption and sandboxing |
| NIST SP 800-53 Rev 5 | AC-6 Least Privilege; SI-2 Flaw Remediation | Permission review and patching |
| NIST CSF 2.0 | PR.DS-01, PR.PS-02 | Data at rest protected, software maintained |
| ISO/IEC 27001:2022 Annex A | A.8.1 User endpoint devices; A.8.24 Use of cryptography | Device policy and encryption |
| OWASP MASVS | MASVS-STORAGE | Secure storage in your own apps |
Common failure patterns
- Writing sensitive files to shared storage: exactly the first precondition ATT&CK lists.
- Old target SDKs: apps targeting old API levels miss the Android 9 and 10 protections even on new devices.
- Treating end-to-end encryption as data-at-rest protection: messaging data is readable on a rooted device.
- Wiping without revoking: tokens copied off the device keep working after a wipe.
- Secrets in the app package: anything shipped in the binary is readable without root.
Practitioner checklist
- Enforce minimum OS and patch levels and retire unsupported devices.
- Gate corporate access on attestation.
- Use work profiles or managed apps for corporate data.
- Review apps with broad storage and accessibility permissions.
- Store tokens in Keystore or Keychain; use Class A for sensitive iOS files.
- Remove long-lived secrets from app packages.
- Test your apps against MASVS-STORAGE.
- Revoke all tokens on a compromised device before or alongside the wipe.
Standards and references
- MITRE ATT&CK: Stored Application Data (Mobile T1409)
- Android Developers: Data and file storage overview
- Android Developers: Behavior changes, apps targeting API level 28
- Apple: Data Protection classes
- OWASP: Mobile Application Security Verification Standard
- Android Developers: Play Integrity API integrity verdicts
- Apple: About Lockdown Mode
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile App Security Guide · Mobile App Permissions · Mobile Forensics Guide