T1533: Data from Local System
Adversaries may search local system sources, such as file systems or local databases, to find files of interest and sensitive data prior to exfiltration.
Access to local system data, which includes information stored by the operating system, often requires escalated privileges. Examples of local system data include authentication tokens, the device keyboard cache, Wi-Fi passwords, and photos. On Android, adversaries may also attempt to access files from external storage which may require additional storage-related permissions.
Security context for executives and security teams
T1533 matters because mobile devices often contain business-relevant secrets outside traditional endpoint visibility: authentication tokens, local databases, keyboard cache data, Wi-Fi passwords, photos, and files on device or external storage. If an adversary or malicious app can read those local sources, the incident may become an identity, privacy, and data-loss problem before the organization sees network exfiltration.
Executive priority
Treat this as a mobile security and identity-risk control question: which corporate or BYOD devices can store sensitive tokens or business data locally, and can security teams prove they can detect suspicious access to that data? Priority is highest for executives, regulated users, critical infrastructure personnel, and roles where mobile compromise could expose credentials, surveillance data, or operational information. This also affects audit readiness because many organizations lack evidence showing what mobile data access is logged, retained, and reviewable.
Technical view
The ATT&CK object applies to Android and iOS and describes adversaries searching local file systems or databases for sensitive data before exfiltration. ATT&CK provides no official detection text and no tactic mapping, but a related detection strategy, DET0713, is listed. SOC and IR teams should validate mobile coverage around app permissions, escalated privilege/root or jailbreak indicators, access to local databases and files where observable, Android external storage access permissions, and correlation with suspicious outbound activity. Relationship context shows this behavior across multiple Android malware families and several iOS-related campaigns or tools, so detection should not be limited to one platform or one malware name.
Likely telemetry
- Mobile device management or enterprise mobility management inventory and compliance state
- Installed mobile app inventory and app provenance where available
- Android permission requests and grants, especially storage-related permissions
- Root, jailbreak, or other escalated-privilege indicators
- Mobile OS security logs and application behavior telemetry where collected
Detection direction
- Confirm whether DET0713 or equivalent mobile detections are implemented and mapped to T1533.
- Do not rely only on network exfiltration alerts; local data collection may occur before data leaves the device.
- Tune for combinations of risk signals: unusual app permissions, storage/database access, privilege escalation state, and sensitive user role.
- Separate expected enterprise apps that legitimately read local data from unknown, sideloaded, repackaged, or suspicious apps to reduce false positives.
- Validate Android-specific visibility into external storage access; confirm iOS visibility limitations, especially on unmanaged or jailbroken devices.
Mitigation priorities
- Prioritize mobile device management controls for high-risk users and sensitive business functions.
- Restrict or review apps with broad local storage access and require trusted app sources where policy allows.
- Enforce mobile OS hygiene, timely updates, and controls that identify rooted or jailbroken devices before they access enterprise resources.
- Reduce local persistence of sensitive enterprise data and tokens where feasible through app configuration and identity policy.
- Correlate mobile posture with conditional access decisions so risky devices do not retain privileged access.
Additional notes and limits
The most important defensive question is not whether T1533 exists, but whether the organization has enough mobile telemetry to distinguish legitimate local data access from spyware, banking trojans, or surveillanceware behavior. The supplied relationships show use by multiple Android software entries and iOS-related campaigns/software, including Operation Dust Storm, Operation Triangulation, Windshift, Gooligan, RCSAndroid, Dendroid, SpyNote RAT, Stealth Mango, Tangelo, Exodus, Gustuff, Monokle, FlexiSpy, ViceLeaker, GolfSpy, Anubis, Ginp, Corona Updates, Concipit1248, TrickMo, INSOMNIA, WolfRAT, and Desert Scorpion.
ATT&CK provides no official detection text and no tactics for this object. Platform support is limited to Android and iOS as supplied. Local observability varies significantly by mobile OS version, management state, privacy settings, and security tooling, so local validation is required before claiming detection coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Data from Local System
Adversaries may search local system sources, such as file systems or local databases, to find files of interest and sensitive data prior to exfiltration.
Access to local system data, which includes information stored by the operating system, often requires escalated privileges. Examples of local system data include authentication tokens, the device keyboard cache, Wi-Fi passwords, and photos. On Android, adversaries may also attempt to access files from external storage which may require additional storage-related permissions.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.
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.
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.