Mobile spyware wants documents, photos, voice notes and app databases, and to find them it first lists what is on the device. MITRE ATT&CK for Mobile T1420 File and Directory Discovery covers adversaries enumerating files and directories, or searching specific locations, to decide what to collect and whether to fully infect the device. ATT&CK lists it for Android and iOS under Discovery (TA0032), and is clear about the difference: on Android, file permissions and SELinux restrict app access but shared external storage is generally visible, while iOS generally prevents file discovery without escalated privileges. This guide covers that platform split, what the procedure examples look for, how storage permissions changed, and how to detect and reduce exposure. It is for mobile security engineers, app developers and incident responders. The Enterprise equivalent is T1083 File and Directory Discovery.
Key takeaways
- Shared storage is the Android exposure. Most ATT&CK Android examples enumerate external storage or the SD card, looking for documents, images, audio and databases.
- Scoped storage narrowed it. Apps targeting Android 10 or later get scoped access to external storage by default, and from Android 11 broad file access needs
MANAGE_EXTERNAL_STORAGE. - iOS discovery implies exploitation. ATT&CK's iOS examples (Operation Triangulation and TriangleDB) used the
ftsAPI after compromising the device. - Where you store data is a control. Sensitive files in app-specific internal storage are not readable by other apps; the same file in shared storage often is.
- The only listed mitigation is OS currency. ATT&CK M1006 notes stronger sandboxing and harder privilege escalation in each release.
How the platforms differ
| Aspect | Android | iOS and iPadOS |
|---|---|---|
| Default app view of storage | App-specific internal directories are private; shared storage holds media and documents meant for sharing | App container sandbox; ATT&CK says discovery generally needs escalated privileges |
| Key change | Scoped storage for apps targeting Android 10 (API 29); WRITE_EXTERNAL_STORAGE has no effect for apps targeting Android 11 | No equivalent change; the restriction is architectural |
| Broad access route | MANAGE_EXTERNAL_STORAGE (Android 11) for all-files access; READ_EXTERNAL_STORAGE for other apps' media | Privilege escalation exploit |
| Legitimate sharing | Storage Access Framework system file picker, MediaStore | Document picker and share sheet (user-driven) |
| ATT&CK analytic | opendir() or File.listFiles() on external storage paths above a threshold within a window | MDM host status and app inventory with network flows; no on-device file trace for production devices |
Real cases from ATT&CK procedure examples
- Targeted file types: GoldenEagle looked for .doc, .txt, .gif, .apk, .jpg, .png, .mp3 and .db files on external storage; FrozenCell searched for PDF and Office files; VajraSpy searched for text, image and audio extensions before exfiltration.
- App data hunting: DoubleAgent searched for Gmail and Dropbox app directories, pictures and thumbnails; CarbonSteal searched for .amr audio recordings and superuser binaries.
- Crypto theft: CherryBlos accessed images in external storage and used optical character recognition to find mnemonic phrases in screenshots.
- Permission checks: DocSwap checked for
READ_EXTERNAL_STORAGEandMANAGE_EXTERNAL_STORAGE. - Groups and campaigns: Windshift (G0112) included file enumeration in Operation BULL and Operation ROCK; PROMETHIUM (G0056) used StrongPity in C0033 to collect file lists; Operation Dust Storm (C0016) used Android backdoors that enumerated specific files.
- iOS: during Operation Triangulation (C0054), the actors listed files in a directory with the
ftsAPI, and TriangleDB collected files matching a regular expression.
For investigation of a suspected implant, see the Mobile Forensics Guide.
Where identity fits
The CherryBlos case shows a pattern defenders see repeatedly: secrets end up as files. Screenshots of recovery phrases, exported configuration files with API keys, downloaded VPN profiles and certificate bundles saved to Downloads all sit in shared storage where an app with broad file access can find them. In your own apps, never write tokens, keys or session data to shared storage; keep them in app-specific internal storage protected by the Android Keystore or iOS Keychain. Tell engineers not to keep screenshots or exports of credentials on phones. See the Mobile App Security Guide.
Prevention and hardening
- Raise the OS floor. Require at least Android 11 so scoped storage and the all-files permission model apply to current apps, and a current iOS release to reduce privilege escalation risk.
- Vet storage permissions. Flag third-party apps requesting
MANAGE_EXTERNAL_STORAGEorREAD_EXTERNAL_STORAGEwithout a clear need; Android's own guidance is that most apps do not need all-files access. - Separate work data. Keep corporate apps and files in the Android work profile and use iOS managed/unmanaged document restrictions so corporate files do not land in personal storage.
- Fix your apps' storage. Store sensitive files in
getFilesDir()style internal storage, not shared storage, and test against OWASP MASVS-STORAGE. - Restrict app sources. Most ATT&CK examples were distributed outside official stores; block unknown sources on managed devices.
Detection and measurement
ATT&CK's detection strategy correlates management state, file access evidence and network data:
| Source | What to look for | Platform |
|---|---|---|
| App vetting or forensic acquisition | High-volume directory listing of external storage paths by an app soon after install | Android |
| Permission state from the device policy controller | Apps holding all-files or broad storage access outside the approved list | Android |
MDM host status (DeviceInformation, SecurityInfo, ProfileList) | Unexpected profiles, compliance drift or out-of-date OS that may indicate compromise | iOS |
| Network logging, VPN or gateway | Large uploads from a recently installed app to an unfamiliar destination | Both |
| Consensual forensics with MVT | Known spyware indicators in iOS backups or filesystem dumps and Android artefacts | Both (investigation only) |
The Mobile Verification Toolkit, released by Amnesty International's Security Lab, is built for consensual forensic analysis and is a response tool, not monitoring. Measures:
- Number of approved third-party apps with all-files access (track and justify each).
- Percentage of managed devices at Android 11 or later and current iOS.
- In-house apps with sensitive data in shared storage, found in testing (target zero).
- Percentage of corporate files accessed through managed apps or the work profile.
Common failure patterns
- Saving secrets as screenshots. Recovery phrases and keys photographed or screenshotted are exactly what CherryBlos searched for.
- Granting all-files access by habit. File managers and cleaners ask for it; each grant gives a full view of shared storage.
- In-house apps writing to Downloads. Exports and logs written to shared storage are visible to other apps with storage permission.
- Assuming iOS cannot be affected. iOS discovery requires escalation, but Operation Triangulation shows that happens against targeted users; keep iOS current and consider Lockdown Mode for high-risk staff.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK for Mobile | T1420; TA0032; M1006 | Technique, tactic and listed mitigation |
| NIST SP 800-53 Rev 5 | AC-19; CM-7; CM-11; SI-4 | Mobile restrictions, least functionality, app control, monitoring |
| NIST CSF 2.0 | PR.PS-02; DE.CM-09 | Software currency; endpoint monitoring |
| OWASP MASVS | MASVS-STORAGE | Secure storage of sensitive data in your own apps |
Practitioner checklist
- Require Android 11 or later and a current iOS release for corporate access.
- Review every third-party app with all-files or broad storage access.
- Keep corporate files in the work profile or managed apps only.
- Keep tokens, keys and exports out of shared storage in your own apps.
- Tell staff not to store screenshots of credentials or recovery phrases on phones.
- Offer Lockdown Mode guidance to staff at high risk of targeted spyware.
- Use MVT or equivalent consensual forensics when a device is suspected.
Standards and references
- MITRE ATT&CK: File and Directory Discovery, Mobile T1420
- MITRE ATT&CK: Use Recent OS Version, M1006
- Android Developers: Data and file storage overview
- Apple Platform Deployment: Restrictions for iPhone and iPad
- Apple Support: About Lockdown Mode
- Amnesty International Security Lab: Mobile Verification Toolkit documentation
- OWASP: Mobile Application Security Verification Standard
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · T1083 File and Directory Discovery · Mobile Forensics Guide · Mobile App Security Guide · Commercial Spyware Guide · Mobile T1533 Data from Local System · Mobile T1409 Stored Application Data