Mobile T1636 Protected User Data: Android and iOS

Protected User Data (T1636) is malware on a phone reading the data stores that the operating system guards behind permissions: calendar, call log, contacts, SMS and accounts. It is one of the most widely recorded techniques in ATT&CK for Mobile, because nearly every spyware family and banking trojan wants the victim's contacts and messages. MITRE ATT&CK v20 lists it under Collection for both Android and iOS, with five sub-techniques. This guide is for mobile security engineers, MDM administrators and SOC analysts who need to know how each data store is reached on each platform, which OS controls stand in the way, and how ATT&CK's v20 analytics detect the collection. For the matrix overview see the MITRE ATT&CK for Mobile Guide.

Key takeaways

The permission prompt is the main gate. ATT&CK notes that in almost all cases the user must grant access to the data store; on a rooted or jailbroken device that gate can disappear.
The platforms are not symmetric. Android exposes call log and SMS through content providers; ATT&CK states iOS provides no standard API for either, so iOS cases in ATT&CK involve full-device spyware.
Store policy narrows Android's attack surface. Google Play restricts the SMS and Call Log permission groups to default handlers and declared exceptions, so a sideloaded app requesting them deserves attention.
Detection pairs a permission with a data flow. ATT&CK's analytics correlate a grant or bulk query by an unapproved app with outbound traffic shortly after, using thresholds tuned per data type.
Mitigation is thin by design. ATT&CK maps only M1006 Use Recent OS Version and M1011 User Guidance, so managed app catalogues and permission policy carry most of the weight.

What T1636 covers

ATT&CK describes T1636 as adversaries using standard operating system APIs to collect data from permission-backed data stores. The permission has to be declared ahead of time: in the manifest on Android and in the Info.plist file on iOS. ATT&CK also notes that recent OS versions add finer controls, such as granting access only while the app is in use. The five sub-techniques split the technique by data store:

Sub-technique	Android access path (per ATT&CK)	iOS access path (per ATT&CK)	Software recorded in ATT&CK v20
T1636.001 Calendar Entries	Calendar Content Provider	`EventKit` framework	6
T1636.002 Call Log	Call Log Content Provider	No standard API	41
T1636.003 Contact List	Contacts Content Provider	`Contacts` framework	58
T1636.004 SMS Messages	SMS Content Provider	No standard API	75
T1636.005 Accounts	`AccountManager`, for example `getAccounts()`	Keychain services	4

The counts are the distinct software and campaign entries ATT&CK v20 records for each sub-technique. SMS stands out because SMS carries one-time passcodes: reading it is how banking trojans defeat SMS-based verification. Related techniques sit next door and have their own pages: Location Tracking (T1430), Data from Local System (T1533), Credentials from Password Store (T1634) and Clipboard Data (T1414).

The sub-techniques in practice

T1636.001 Calendar Entries

Calendars reveal meetings, locations and attendees, which is why ATT&CK's examples are surveillance tools rather than fraud malware. ATT&CK records Pegasus for Android accessing calendar entries, Exodus Two exfiltrating calendar events, and Monokle retrieving event name, time, place and description. ATT&CK's mitigation note calls calendar access an uncommonly needed permission that users should scrutinise.

T1636.002 Call Log

On Android the Call Log permission group (READ_CALL_LOG, WRITE_CALL_LOG, PROCESS_OUTGOING_CALLS) is restricted on Google Play to apps registered as the default Phone, SMS or Assistant handler, plus exceptions Google approves through the Permissions Declaration Form. Google Play's policy page also states that account verification by phone call will no longer be a permitted use of READ_CALL_LOG from 27 January 2027. On iOS, ATT&CK records Pegasus for iOS capturing call logs; with no standard API, that requires the device itself to be compromised.

T1636.003 Contact List

Contacts are the most broadly requested of the five, which makes them the hardest to judge from a permission alone. Messaging, CRM and dialler apps have real reasons to ask. ATT&CK records Cerberus, Fakecalls, LightSpy, Monokle, Pegasus for Android and iOS, and RatMilad among the families that take the contact list. Because so many apps hold this permission, the useful signal is not the grant but what the app does next: a bulk read followed by an upload.

T1636.004 SMS Messages

The SMS permission group (READ_SMS, RECEIVE_SMS, RECEIVE_MMS, RECEIVE_WAP_PUSH, SEND_SMS, WRITE_SMS) carries the same Google Play default-handler restriction as Call Log. ATT&CK records RatMilad reading inbox, sent, draft, outbox, failed and queued messages, and FinFisher capturing and exfiltrating SMS. Any app that reads SMS can read one-time passcodes, which turns this sub-technique into an account takeover path. See the Android Banking Trojans Guide.

T1636.005 Accounts

Account data tells an adversary which services the user is signed in to. Android 8.0 (API level 26) changed this: the developer documentation states that apps can no longer get access to user accounts unless the authenticator owns the accounts or the user grants access, and that GET_ACCOUNTS alone is no longer sufficient. Apps use AccountManager.newChooseAccountIntent() instead. On iOS, ATT&CK names Keychain services as the access path. ATT&CK records DCHSpy, DocSwap, RatMilad and VajraSpy for this sub-technique.

Platform controls on Android and iOS

Control	Android	iOS
Declaration	Permission declared in the app manifest	Purpose declared in `Info.plist`
User consent	Runtime permission grant; user can revoke in Settings	Apple Platform Security lists Calendars and Contacts among the categories where access is enforced; users can grant or revoke per app in Settings
Store policy	Google Play restricts SMS and Call Log groups to default handlers and approved exceptions; non-qualifying apps may be removed	App Review; call log and SMS have no standard API
App data isolation	Application sandbox; work profile separates managed apps from personal data	Data Vault protects third-party app data on iOS and iPadOS 13.4 or later, per Apple Platform Security
Malware scanning	Google Play Protect scans installed apps, including those from outside Google Play, per Google	App Store distribution and review
Management	Android Enterprise DPC can query and set permission grant state for managed apps	MDM restrictions prevent data moving between managed and unmanaged apps and accounts, per Apple Platform Security

The jailbreak and root caveat appears in every sub-technique: ATT&CK states that on such a device an adversary may reach these stores without the user's knowledge or approval. A device integrity check in MDM or mobile threat defence (MTD) is therefore a prerequisite for trusting any of the permission controls above. See the Mobile App Permissions guide for the permission model in depth.

Detection: ATT&CK v20 analytics

ATT&CK v20 detection strategy DET0681 covers the parent technique with one analytic per platform, and each sub-technique has its own strategy (DET0674 Calendar Entries, DET0602 Call Log, DET0679 Contact List, DET0686 SMS Messages, DET0635 Accounts). All of them share one rule: alert on a sequence or state change inconsistent with the device and app baseline, approved management policy or expected user workflow, and do not infer unobserved API calls from management state alone.

Analytic	Platform	What it correlates	Tunable fields (ATT&CK defaults)
AN1786	Android	Bulk `ContentResolver.query()` on contacts, calendar, call log or SMS providers by an app not on the approved list; enterprise network logs (`DnsEvent`, `ConnectEvent`); permission grant state from the DPC	Query thresholds per data type: Contacts 50, Calendar 30, Call Log 10, SMS 20 queries in 2 minutes; uplink 100 KB within 120 seconds
AN1787	iOS	`CNContactStore.enumerateContacts` or `EKEventStore.fetchEvents` with broad scope by an unapproved app; Network Extension or per-app VPN flow metadata; entitlements and `Info.plist` usage keys from app vetting	Approved apps per data type from the MDM catalogue; uplink 100 KB within 120 seconds
AN1708 / AN1709	Android / iOS	Repeated `AccountManager.getAccounts()` or `getAccountsByType()`; on iOS `SecItemCopyMatching()` with `kSecMatchLimitAll`	Approved authenticator apps; enumeration threshold and window

The API-level signals come from application vetting or instrumented dynamic analysis, not from production phones. In a fleet, the realistic signals are the permission grant state reported by MDM, the app inventory, and network flow data. On Android, network activity logging (DevicePolicyManager.setNetworkLoggingEnabled()) records DNS lookups and TCP connection attempts with the package name; it needs a device owner on Android 8.0 or later, or a work profile owner on Android 12 or later, and logs only work profile activity in that case. Google's documentation notes it does not capture UDP or apps that connect without a lookup.

Metrics that show it is working

Sensitive grant coverage: percentage of managed devices reporting permission grant state for SMS, Call Log, Contacts and Calendar.
Unapproved grants: count of apps outside the approved catalogue holding SMS or Call Log permissions, trended weekly; the target is zero.
Integrity failures: devices flagged as rooted or jailbroken, and median time to quarantine them.
Vetting coverage: share of approved apps that passed a review of requested permissions before deployment.
Alert precision: share of query-then-upload alerts confirmed as malicious or policy violations after triage.

Prevention and response

Keep the OS current (M1006). Set minimum OS versions in MDM compliance policy; ATT&CK notes that OS updates often improve permission privacy. Block or quarantine devices below the floor.
Build an approved app list per data type. Record which apps legitimately need SMS, Call Log, Contacts, Calendar or account access. This list is the ApprovedDataApps field the analytics depend on.
Use managed configuration to deny what is not needed. On Android Enterprise, set permission policy for managed apps; on iOS, use managed open-in and data movement restrictions so work data stays in managed apps.
Restrict sideloading. On Android, disallow installs from unknown sources for managed devices and keep Google Play Protect on. Sideloaded apps escape the Google Play SMS and Call Log policy.
Train for the prompt (M1011). ATT&CK's guidance is specific: these are uncommonly needed permissions and deserve extra scrutiny. Teach staff to deny SMS and call log requests from anything that is not their messaging or phone app.
Respond with forensics. For a suspected spyware case, collect evidence with consent using the Mobile Verification Toolkit (MVT), which Amnesty International Security Lab built for consensual forensic analysis of Android and iOS devices. See the Mobile Spyware Infection Response Playbook.

Rollback is simple for permission policy: changes to grant state apply per app and can be reverted from the MDM console. Pilot new deny policies on a small ring first, because an over-broad rule can break a CRM or dialler app the business relies on.

Where identity fits

T1636.004 is an identity technique as much as a privacy one. When SMS carries one-time passcodes, any app that reads SMS holds a second factor for every account using it. T1636.005 lists the accounts on the device, which tells the adversary which services to target next. Move staff off SMS codes to phishing-resistant authenticators where you can. See the Mobile Access Credentials guide.

Common failure patterns

Trusting the permission on a compromised device. Every T1636 sub-technique carries ATT&CK's rooted or jailbroken caveat; without integrity checks the permission model tells you nothing.
No approved list, so no baseline. Without per-data-type approved apps, every contacts request looks equally normal and the analytics cannot fire.
Allowing sideloading on managed devices. Apps from outside Google Play are not bound by its SMS and Call Log policy.
Relying on SMS one-time passcodes for high value accounts. SMS collection is the most recorded sub-technique in ATT&CK v20.
Assuming network logs are complete. Android network logging skips UDP and direct connections, so pair it with VPN or gateway flow data.

Framework mapping

Framework	Reference	Why it applies
ATT&CK for Mobile	M1006 Use Recent OS Version; M1011 User Guidance	The only mitigations mapped to T1636
NIST SP 800-53 Rev. 5	CM-11 User-installed Software; AC-6 Least Privilege; SI-4 System Monitoring	Control which apps are installed, what they may access, and monitor for misuse
NIST CSF 2.0	PR.PS-05; PR.AA-05; DE.CM-09	Prevent unauthorised software, enforce least privilege, monitor endpoints
OWASP MASVS	MASVS-PRIVACY	Apps you build should request and use only the data they need

Practitioner checklist

Publish an approved app list for SMS, Call Log, Contacts, Calendar and account access.
Set and enforce a minimum OS version for Android and iOS in MDM compliance policy.
Block managed devices that fail root or jailbreak integrity checks.
Disallow unknown sources on managed Android devices and keep Google Play Protect on.
Collect permission grant state from the DPC and alert on SMS or Call Log grants to unapproved apps.
Turn on Android network activity logging where you own the device or work profile, and add VPN or gateway flow data.
Review requested permissions as part of app vetting before any app enters the catalogue.
Replace SMS one-time passcodes for staff accounts with phishing-resistant methods.
Keep a consent-based MVT collection procedure ready for suspected spyware.

Mobile T1636 Protected User Data: Detecting Data Collection on Android and iOS