T1636.005: Accounts
Adversaries may utilize standard operating system APIs to gather account data. On Android, this can be accomplished by using the AccountManager API. For example, adversaries may use the `getAccounts()` method to list all accounts.[1] On iOS, this can be accomplished by using the Keychain services.
If the device has been jailbroken or rooted, adversaries may be able to access Accounts without the users’ knowledge or approval.
Analyst context for executives and security teams
This mobile technique matters because account data on Android and iOS can reveal what services, identities, and credentials are present on a device. Even when access is mediated by normal OS APIs and user permissions, a malicious or trojanized app may turn approved mobile access into useful reconnaissance or collection. Rooted or jailbroken devices increase the risk because account data may be accessed without normal user awareness or approval.
Executive priority
Security leaders should treat this as a mobile identity and data-governance issue, not just a malware behavior. Priority questions are: which enterprise mobile devices can install untrusted apps, how consistently are devices kept on recent OS versions, can the organization identify rooted or jailbroken devices, and is there evidence of which apps request or receive access to protected user data. This is most relevant to mobile workforce risk, identity exposure, BYOD governance, and audit evidence for mobile access controls.
Technical view
For SOC, detection engineering, and IR teams, validate visibility around Android AccountManager usage and iOS Keychain-related access patterns where telemetry is available. On Android, review app manifests, requested permissions, installed app inventory, and mobile security telemetry for suspicious apps accessing account information through standard APIs. On iOS, focus on app entitlement/configuration review, device posture, and Keychain-related access evidence where your tooling exposes it. Because MITRE provides no official detection text for this object, coverage should be tested locally rather than assumed. Relationship context shows Android malware families/software entries using this technique, so Android telemetry and app-source controls deserve particular validation.
Likely telemetry
- Mobile device inventory, platform, OS version, and patch level
- Root or jailbreak detection and device compliance state
- Installed mobile application inventory and application source, including unmanaged or uncontrolled distribution channels
- Android application manifest permissions and use of account-related APIs such as AccountManager/getAccounts where observable
- iOS application configuration, entitlements, and Keychain-related access evidence where observable
Detection direction
- Confirm whether existing mobile security tooling can observe access to account data APIs, or only infer risk from app permissions and device posture.
- Tune reviews around apps that request protected user data access inconsistent with their stated business purpose, while accounting for legitimate identity, email, VPN, and enterprise management applications.
- Prioritize rooted or jailbroken devices because MITRE notes account data may be accessed without normal user knowledge or approval in those states.
- Use relationship context to seed validation with Android-focused scenarios, since the supplied software examples using this technique are Android.
- Do not rely on permission prompts alone as detection; combine app inventory, permission state, install source, and device posture.
Mitigation priorities
- Keep mobile devices on recent Android and iOS versions, aligning with M1006 Use Recent OS Version.
- Provide user guidance for risky app installation, permission approval, and rooted/jailbroken device use, aligning with M1011 User Guidance.
- Enforce mobile device compliance checks that identify outdated, rooted, or jailbroken devices before allowing access to enterprise resources.
- Review and restrict unmanaged or unnecessary applications on enterprise-managed devices where policy allows.
- Maintain evidence of OS currency, device posture, app inventory, and permission governance for audit and incident response readiness.
Analyst notes and limits
This object is a sub-technique of Protected User Data and describes collection of account data through standard mobile OS mechanisms. The official object lists Android and iOS, with Android AccountManager and iOS Keychain services specifically named. Related software examples supplied for this object are Android-focused, which supports Android-specific prioritization but not exclusion of iOS risk.
MITRE does not provide official detection text or tactics for this object in the supplied fields. Specific permissions, event names, API telemetry, and feasible detections depend heavily on mobile platform version, device management model, and deployed MDM/MTD/EDR capabilities. This take does not establish active exploitation or customer exposure.
Accounts
Adversaries may utilize standard operating system APIs to gather account data. On Android, this can be accomplished by using the AccountManager API. For example, adversaries may use the `getAccounts()` method to list all accounts.[1] On iOS, this can be accomplished by using the Keychain services.
If the device has been jailbroken or rooted, adversaries may be able to access Accounts without the users’ 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 | Protected User Data | This object subtechnique of Protected User Data. |
Groups, software, and campaigns
S1241: RatMilad
RatMilad is an Android remote access tool (RAT) with spyware functionality that has been used to target enterprise mobile devices in the Middle East since at least 2021. Variants of RatMilad have been disguised as VPN applications and a fake app named NumRent. Upon installation, RatMilad employs multiple Collection techniques to collect sensitive information before uploading the collected data to its command and control (C2) server. [1]
S9006: VajraSpy
VajraSpy is Android malware distributed via trojanized messaging and news applications. It has been used to target individuals in Pakistan and India since at least 2021 and has been delivered through the Google Play Store, malicious domains, and other uncontrolled distribution channels. VajraSpy is attributed with high confidence to Patchwork which has used the malware to conduct targeted espionage, primarily against devices in Pakistan.[1][2][3]
S1243: DCHSpy
DCHSpy is an Android spyware likely used by MuddyWater. DCHSpy uses political decoys and masquerades as legitimate applications, such as VPNs and banking applications, to trick victims into downloading the malware. Once downloaded, DCHSpy collects information from the device and exfiltrates the data to the command and control (C2) server.[1]
S9005: DocSwap
DocSwap is an Android malware first identified in 2025, and attributed to Kimsuky. DocSwap’s name is a combination of its Korean name “문서열람 인증 앱” (Document Viewing Authentication App) and a phishing page masquerading as CoinSwap at the C2 address. Based on DocSwap’s name and Korean-language strings, DocSwap potentially targets mobile device users in South Korea. Several variants of DocSwap exist; one of the latest samples indicates that the adversary added a native decryption function that decrypts an internal APK.[1][2]
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.0 | Current bundle | a7f48acf11dc… |
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]
Android_AccountManager_Feb2025
Android. (2025, February 13). AccountManager. Retrieved September 2, 2025.
Open source URL -
[2]
mitre-attack T1636.005Open 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.