AN1708: Analytic 1708
OLD: Monitor for API calls that are related to the AccountManager API on Android and Keychain services on iOS. Application vetting services may look for `MANAGE_ACCOUNTS` in an Android application’s manifest. Most applications do not need access to accounts, so extra scrutiny may be applied to those that request it.
NEW: A defender observes an Android application invoking the AccountManager API.
Analyst context for executives and security teams
This analytic matters because Android applications that invoke the AccountManager API may be interacting with device account data or account-related services. For security leaders, the decision value is not that every such app is malicious, but that account access is sensitive enough to require visibility during mobile app vetting, managed mobile detection, and incident review. Organizations that rely on Android devices should be able to answer which apps request or use account-related capabilities and whether that use is expected for the app’s business purpose.
Executive priority
Prioritize this as a mobile identity and application-risk validation point. It can support decisions about mobile application approval, bring-your-own-device risk, compliance evidence for mobile controls, and incident response scoping when suspicious Android app behavior is under review. Leaders should ask whether the organization has a repeatable process to identify Android apps using account-management capabilities, review whether that access is justified, and preserve evidence when a mobile investigation is required.
Technical view
The supplied ATT&CK analytic is for Android and centers on observing an application invoking the AccountManager API. The older description also notes that app-vetting services may look for MANAGE_ACCOUNTS in an Android application manifest, with extra scrutiny because most applications do not need account access. SOC, mobile security, and IR teams should validate whether they can collect app manifest data, mobile application inventory, and runtime or EDR/MDM telemetry showing AccountManager API usage. Because no tactic, technique relationship, or official detection logic is supplied, this should be treated as a detection-validation and triage analytic rather than a standalone maliciousness signal.
Likely telemetry
- Android application manifest permissions, including whether MANAGE_ACCOUNTS is requested
- Mobile application inventory and package metadata from managed devices
- Runtime mobile telemetry showing Android AccountManager API invocation, where available
- Mobile app vetting or application reputation findings
- Device ownership, user, and deployment context from MDM/UEM records
Detection direction
- Validate whether mobile telemetry can distinguish apps that merely declare account-related permissions from apps that actually invoke the AccountManager API.
- Tune triage around business justification: productivity, identity, messaging, and enterprise management apps may have legitimate account-related behavior, while unrelated apps may warrant closer review.
- Correlate AccountManager API use with application source, package identity, install path, user population, and whether the app is approved for enterprise use.
- Do not treat this analytic alone as proof of compromise; use it as a prompt for vetting, escalation, or investigation when the app’s purpose does not justify account access.
- Document blind spots where unmanaged Android devices, limited MDM coverage, or lack of runtime mobile telemetry prevent observation of API invocation.
Mitigation priorities
- Maintain an approved mobile application inventory and require review for Android apps that request or use account-management capabilities.
- Use mobile app vetting to inspect manifests for account-related permissions, including MANAGE_ACCOUNTS where present.
- Restrict installation of unapproved applications on managed Android devices where business policy allows.
- For incident response readiness, ensure teams can preserve app metadata, permission data, device context, and relevant mobile telemetry.
- Periodically review high-risk mobile apps against their business purpose and remove or restrict apps with unjustified account-related access.
Analyst notes and limits
This Glexia take is based only on the supplied MITRE analytic AN1708 fields. The object is a detection analytic in the mobile ATT&CK domain, with Android as the only supplied platform. The description changed from broader monitoring of Android AccountManager and iOS Keychain-related APIs to a narrower statement: observing an Android application invoking the AccountManager API. The older text’s Android manifest and MANAGE_ACCOUNTS guidance remains useful as vetting context, but the current analytic should be interpreted around Android AccountManager observation.
No official detection logic, tactics, technique relationships, adversary relationships, or impact claims were supplied. This means the analytic cannot by itself establish malicious intent, attribution, active exploitation, or coverage quality. Local mobile management architecture, device ownership model, telemetry depth, and approved-app policy are required to determine operational priority and detection feasibility.
Analytic 1708
OLD: Monitor for API calls that are related to the AccountManager API on Android and Keychain services on iOS. Application vetting services may look for `MANAGE_ACCOUNTS` in an Android application’s manifest. Most applications do not need access to accounts, so extra scrutiny may be applied to those that request it.
NEW: A defender observes an Android application invoking the AccountManager API.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 2375c8cbb349… |
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 AN1708Open 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.