T1636: Protected User Data
Adversaries may utilize standard operating system APIs to collect data from permission-backed data stores on a device, such as the calendar or contact list. These permissions need to be declared ahead of time. On Android, they must be included in the application’s manifest. On iOS, they must be included in the application’s `Info.plist` file.
In almost all cases, the user is required to grant access to the data store that the application is trying to access. In recent OS versions, vendors have introduced additional privacy controls for users, such as the ability to grant permission to an application only while the application is being actively used by the user.
If the device has been jailbroken or rooted, an adversary may be able to access Protected User Data without the user’s knowledge or approval.
Analyst context for executives and security teams
Protected User Data matters because mobile apps can request OS-approved access to sensitive personal and business context on Android and iOS devices, including calendars, contacts, call logs, SMS messages, and account data through related sub-techniques. For leaders, the risk is less about an exotic exploit and more about whether mobile app permissions, user consent, and rooted or jailbroken device exposure are governed well enough to protect communications, identity context, and regulated data.
Executive priority
Prioritize this as a mobile privacy, identity, and compliance readiness issue. Executives should ask whether corporate mobile devices and bring-your-own-device programs can prove which apps have access to protected data stores, whether users receive clear permission guidance, whether devices are kept on recent OS versions, and how rooted or jailbroken devices are handled. This technique is material to incident response because access may appear as normal app behavior unless permission state, device integrity, and app inventory are available during investigation.
Technical view
For Android and iOS, validate visibility into application-declared permissions and runtime user grants for protected data stores. Android-specific review should include manifest-declared access and use of platform data providers or APIs referenced by sub-techniques, such as Calendar, Call Log, Contacts, SMS, and AccountManager. iOS review should include Info.plist privacy declarations and framework usage where applicable, such as EventKit, Contacts, and Keychain services; note that the supplied ATT&CK relationships state iOS provides no standard API for call log or SMS access. Because ATT&CK provides no official detection text for T1636, detection engineering should use the related DET0681 strategy as a starting point and validate local mobile telemetry rather than assuming coverage.
Likely telemetry
- Mobile app inventory and package or bundle metadata
- Android application manifest permissions
- iOS Info.plist privacy usage declarations
- Runtime permission grant and denial state where available
- Mobile device OS version and patch level
Detection direction
- Inventory apps requesting access to protected user data and compare requested permissions against expected business purpose.
- Prioritize alerts or reviews for apps requesting multiple sensitive data categories, especially contacts, calendars, SMS, call logs, or accounts.
- Separate Android and iOS logic because supported APIs differ by platform, including the supplied distinction that iOS has no standard API for call log or SMS access.
- Treat rooted or jailbroken device status as a major context signal because ATT&CK notes protected data may be accessed without user knowledge or approval in that state.
- Tune for false positives from legitimate productivity, communication, calendar, identity, or device-management apps that require these permissions.
Mitigation priorities
- Keep mobile devices on recent OS versions, aligning with mitigation M1006, because newer versions may add privacy controls and security architecture improvements.
- Provide user guidance, aligning with M1011, so users understand permission prompts, risky grants, and the significance of allowing access only while an app is in use where supported.
- Review and govern app permissions before deployment or approval, especially for apps requesting access to protected data stores.
- Maintain controls and response procedures for rooted or jailbroken devices because user permission controls may be bypassed in that condition.
- Use mobile security or device management evidence to support compliance and incident-response decisions about app access, OS version, and device integrity.
Analyst notes and limits
This object is a mobile ATT&CK technique for Android and iOS with no tactic specified and no official detection text supplied. The most useful relationship context is the set of sub-techniques naming specific protected data stores and the mitigations for recent OS versions and user guidance. Local policy, app inventory, and mobile telemetry determine whether this can be detected or only assessed through governance review.
The supplied ATT&CK fields do not provide active exploitation evidence, actor attribution, impact outcomes, or detailed detection analytics. Claims about coverage, exposure, or compromise require organization-specific device, app, permission, and MDM/mobile security data.
Protected User Data
Adversaries may utilize standard operating system APIs to collect data from permission-backed data stores on a device, such as the calendar or contact list. These permissions need to be declared ahead of time. On Android, they must be included in the application’s manifest. On iOS, they must be included in the application’s `Info.plist` file.
In almost all cases, the user is required to grant access to the data store that the application is trying to access. In recent OS versions, vendors have introduced additional privacy controls for users, such as the ability to grant permission to an application only while the application is being actively used by the user.
If the device has been jailbroken or rooted, an adversary may be able to access Protected User Data without the user’s knowledge or approval.
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1636.002 | Call Log Sub-technique | Call Log subtechnique of this object. |
| Mobile | T1636.001 | Calendar Entries Sub-technique | Calendar Entries subtechnique of this object. |
| Mobile | T1636.005 | Accounts Sub-technique | Accounts subtechnique of this object. |
| Mobile | T1636.004 | SMS Messages Sub-technique | SMS Messages subtechnique of this object. |
| Mobile | T1636.003 | Contact List Sub-technique | Contact List subtechnique of this object. |
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 | 1.1 | Current bundle | 31a43d513bab… |
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]
NIST Mobile Threat Catalogue APP-13Open source URL
-
[2]
mitre-attack T1636Open 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.