T1409: Stored Application Data
Adversaries may try to access and collect application data resident on the device. Adversaries often target popular applications, such as Facebook, WeChat, and Gmail.[1]
Due to mobile OS sandboxing, this technique is only possible in three scenarios:
* An application stores files in unprotected external storage * An application stores files in its internal storage directory with insecure permissions (e.g. 777) * The adversary gains root permissions on the device
Analyst context for executives and security teams
Stored Application Data matters because mobile devices often hold business communications, identity material, email, messaging content, and application-local records that may not be visible in traditional endpoint monitoring. ATT&CK describes this as adversaries attempting to access application data resident on Android or iOS devices, especially popular apps, when storage is exposed, permissions are insecure, or the device is rooted or jailbroken. For leaders, the decision point is not only malware detection; it is whether mobile app storage, OS currency, and managed-device visibility are strong enough to protect sensitive data on phones and tablets.
Executive priority
Prioritize this technique where mobile devices are used for executive communications, regulated data access, privileged administration, or workforce identity workflows. The supplied ATT&CK relationships show broad use across mobile spyware, banking malware, and surveillanceware families, plus an iOS campaign relationship, making it a useful control-validation scenario for mobile security programs. Executives should ask whether managed devices run recent OS versions, whether high-risk apps store data safely, whether rooted or jailbroken devices are blocked from business access, and whether incident responders can collect enough mobile evidence to confirm or rule out application-data access.
Technical view
For SOC, detection engineering, and IR teams, validate coverage on Android and iOS for evidence that application-resident data could be accessed outside normal app boundaries. ATT&CK states this is constrained by mobile OS sandboxing and is primarily possible when apps store files in unprotected external storage, use insecure permissions in internal storage, or when adversaries gain root permissions. Because ATT&CK provides no official detection text for T1409, teams should treat related detection strategy DET0621 as a pointer to build local analytics around storage exposure, app permission weakness, device integrity state, and suspicious access to app data paths. Relationship context includes many Android software entries, several iOS or cross-platform entries, and Operation Triangulation on iOS, so testing should not be limited to one mobile OS if both are in scope.
Likely telemetry
- Mobile device management or enterprise mobility inventory showing Android/iOS version, patch level, device compliance, and managed/unmanaged status
- Root or jailbreak indicators from MDM, mobile threat defense, or device compliance checks
- Application inventory and app risk assessment results, especially for business-critical messaging, email, banking, wallet, shopping, and collaboration apps
- Mobile application security test results showing use of external storage, insecure file permissions, or sensitive local data storage
- On-device forensic artifacts during incident response, including application data locations and file permission evidence where legally and technically available
Detection direction
- Start by confirming whether DET0621 or an equivalent local detection strategy is implemented; ATT&CK does not provide a native detection description for T1409.
- Tune detection around prerequisites and enabling conditions: rooted or jailbroken devices, apps storing sensitive files in external storage, and insecure internal storage permissions.
- Correlate mobile malware or spyware detections with device posture and app data exposure rather than treating the malware alert alone as proof of data access.
- Account for blind spots on personally owned or unmanaged devices, where storage inspection, app inventory, and forensic collection may be limited.
- Use relationship context for threat-informed testing: ATT&CK links this technique to Pegasus for iOS, Pegasus for Android, RCSAndroid, SpyDealer, Skygofree, Exodus, FlexiSpy, Mandrake, FluBot, S.O.V.A., and other mobile malware or surveillanceware entries; validate whether telemetry would show the relevant platform and device-integrity conditions.
Mitigation priorities
- Use M1006 as a baseline priority: keep mobile operating systems on recent supported versions to benefit from patches and security architecture improvements.
- Enforce mobile compliance policies that restrict rooted or jailbroken devices from business resources.
- Review internally developed and high-risk third-party mobile apps for unsafe storage patterns, including unprotected external storage and insecure file permissions.
- Apply mobile application management or device management controls to separate business data from unmanaged personal app data where feasible.
- Prioritize executive, administrator, regulated-data, and incident-response user populations for stronger mobile posture enforcement and monitoring.
Analyst notes and limits
The materiality of T1409 depends heavily on local mobile architecture: managed versus unmanaged devices, use of corporate apps, app storage practices, OS versions, and whether security tooling can observe root or jailbreak state. The large set of ATT&CK software relationships suggests this is a common objective or capability across mobile malware reporting, but those relationships should be used for defensive prioritization rather than assumptions about active exposure in a specific environment.
The ATT&CK object does not specify tactics and provides no official detection text. The supplied data supports Android and iOS scope, the three described enabling scenarios, one mitigation relationship, one detection-strategy relationship, and listed campaign/group/software relationships. It does not by itself prove active exploitation, customer exposure, successful data theft, or detection coverage in any environment.
Stored Application Data
Adversaries may try to access and collect application data resident on the device. Adversaries often target popular applications, such as Facebook, WeChat, and Gmail.[1]
Due to mobile OS sandboxing, this technique is only possible in three scenarios:
* An application stores files in unprotected external storage * An application stores files in its internal storage directory with insecure permissions (e.g. 777) * The adversary gains root permissions on the device
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Groups, software, and campaigns
G0034: Sandworm Team
Sandworm Team is a destructive threat group that has been attributed to Russia's General Staff Main Intelligence Directorate (GRU) Main Center for Special Technologies (GTsST) military unit 74455.[1][2] This group has been active since at least 2009.[3][4][5][6]
In October 2020, the US indicted six GRU Unit 74455 officers associated with Sandworm Team for the following cyber operations: the 2015 and 2016 attacks against Ukrainian electrical companies and government organizations, the 2017 worldwide NotPetya attack, targeting of the 2017 French presidential campaign, the 2018 Olympic Destroyer attack against the Winter Olympic Games, the 2018 operation against the Organisation for the Prohibition of Chemical Weapons, and attacks against the country of Georgia in 2018 and 2019.[1][2] Some of these were conducted with the assistance of GRU Unit 26165, which is also referred to as APT28.[7]
S0399: Pallas
Pallas is mobile surveillanceware that was custom-developed by Dark Caracal.[1]
S1079: BOULDSPY
S0509: FakeSpy
S0405: Exodus
S0485: Mandrake
Mandrake is a sophisticated Android espionage platform that has been active in the wild since at least 2016. Mandrake is very actively maintained, with sophisticated features and attacks that are executed with surgical precision.
Mandrake has gone undetected for several years by providing legitimate, ad-free applications with social media and real reviews to back the apps. The malware is only activated when the operators issue a specific command.[1]
S0408: FlexiSpy
S1062: S.O.V.A.
S.O.V.A. is an Android banking trojan that was first identified in August 2021 and has subsequently been found in a variety of applications, including banking, cryptocurrency wallet/exchange, and shopping apps. S.O.V.A., which is Russian for "owl", contains features not commonly found in Android malware, such as session cookie theft.[1][2]
S0316: Pegasus for Android
Pegasus for Android is the Android version of malware that has reportedly been linked to the NSO Group. [1] [2] The iOS version is tracked separately under Pegasus for iOS.
S0295: RCSAndroid
RCSAndroid is Android malware. [1]
S1067: FluBot
FluBot is a multi-purpose mobile banking malware that was first observed in Spain in late 2020. It primarily spread through European countries using a variety of SMS phishing messages in multiple languages.[1][2] An international law enforcement operation of 11 countries eventually disrupted the spread of FluBot.[3]
S1185: LightSpy
First observed in 2018, LightSpy is a modular malware family that initially targeted iOS devices in Southern Asia before expanding to Android and macOS platforms. It consists of a downloader, a main executable that manages network communications, and functionality-specific modules, typically implemented as `.dylib` files (iOS, macOS) or `.apk` files (Android). LightSpy can collect VoIP call recordings, SMS messages, and credential stores, which are then exfiltrated to a command and control (C2) server.[1]
S1128: HilalRAT
C0054: Operation Triangulation
Operation Triangulation is a mobile campaign targeting iOS devices.[1] The unidentified actors used zero-click exploits in iMessage attachments to gain Initial Access, then executed exploits and validators, such as Binary Validator before finally executing the TriangleDB implant.
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 3.1 | Current bundle | 9008e947ce53… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
SWB Exodus March 2019
Security Without Borders. (2019, March 29). Exodus: New Android Spyware Made in Italy. Retrieved November 17, 2024.
Open source URL -
[2]
NIST Mobile Threat Catalogue AUT-0Open source URL
-
[3]
mitre-attack T1409Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.