DET0635: Detection of Accounts
DET0635 is a mobile ATT&CK detection strategy for identifying activity related to collection of account information on mobile devices. The business issue i...
Analyst context for executives and security teams
DET0635 is a mobile ATT&CK detection strategy for identifying activity related to collection of account information on mobile devices. The business issue is not just that an app or actor can list accounts; it is that account inventory on Android or iOS can expose identity context, user services, and potential paths for follow-on abuse. Security leaders should treat this as a validation point for mobile visibility: can the organization see when account data is accessed in ways that are unexpected for the app, device state, or user role?
Executive priority
Prioritize this where mobile devices carry business identities, regulated data access, or privileged user accounts. The key decision value is whether mobile security, identity governance, and incident response teams can produce evidence about account-data access on Android and iOS, especially for rooted or jailbroken devices where normal platform protections may be weakened. This supports resilience, audit readiness, and faster scoping during mobile-related investigations.
Technical view
The related ATT&CK technique is T1636.005, Accounts, in the mobile domain. The supplied relationship states that adversaries may use standard OS APIs to gather account data: Android AccountManager, including getAccounts(), and iOS Keychain services; rooted or jailbroken devices may increase access. Because the detection strategy object has no official detection text or platforms of its own, SOC and detection teams should validate coverage against the related technique context rather than assume a complete MITRE analytic exists.
Likely telemetry
- Mobile device management or enterprise mobility management device inventory and compliance state
- Mobile threat defense alerts, especially rooted or jailbroken device indicators
- Application inventory, permissions, and behavior metadata for Android and iOS apps
- Android telemetry related to account access APIs or permissions where available
- iOS telemetry related to Keychain access patterns where available through approved enterprise tooling
Detection direction
- Confirm whether mobile tooling can observe or infer access to account data on Android and iOS; do not assume endpoint-style telemetry is available on mobile platforms.
- Tune review around apps whose expected function does not require account enumeration or Keychain/account access, while accounting for legitimate identity, email, productivity, and device-management applications.
- Correlate account-data access indicators with device risk state, especially rooted or jailbroken status, because the related technique notes expanded access may be possible in those conditions.
- Use identity logs as supporting context rather than a standalone detector; account discovery on device may precede or inform later authentication behavior but is not itself proof of compromise.
- Document blind spots where OS privacy controls, mobile telemetry limits, unmanaged devices, or bring-your-own-device policies prevent direct observation.
Mitigation priorities
- Establish or validate mobile device compliance requirements, including detection and response for rooted or jailbroken devices.
- Restrict enterprise access from noncompliant or unmanaged mobile devices where business risk warrants it.
- Review mobile application allowlisting, permission governance, and app risk assessment for applications that can access account-related data.
- Ensure incident response playbooks include mobile account-data exposure questions, evidence preservation, and identity follow-up actions.
- Align mobile telemetry retention and compliance reporting so teams can demonstrate whether account-access monitoring is in scope.
Analyst notes and limits
This take is based on the DET0635 detection-strategy object and its relationship to mobile technique T1636.005 Accounts. The official detection-strategy object provides no description, detection logic, tactics, or platforms; the practical guidance is therefore anchored to the related technique fields, which identify Android, iOS, AccountManager/getAccounts(), Keychain services, and rooted/jailbroken device considerations.
MITRE supplied no official detection text for DET0635, and no platform list on the detection-strategy object itself. Local tooling, mobile management architecture, privacy constraints, and device ownership model will determine what can actually be collected or detected. This summary does not assert active exploitation, attribution, or existing detection coverage.
Detection of Accounts
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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.
All related ATT&CK context
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 | 09bcc76f03bd… |
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]
mitre-attack DET0635Open 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.