AN1709: Analytic 1709
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.
Analyst context for executives and security teams
This analytic points defenders toward mobile application behavior involving account and credential-related services, specifically iOS Keychain services in the platform field and Android AccountManager-related references in the official description. For security leaders, the value is not that this alone proves malicious activity, but that mobile apps touching account stores deserve extra review because they may affect user identity, credential handling, and trust in managed mobile environments.
Executive priority
Prioritize this as a mobile identity and application-risk validation item. Leaders should ask whether mobile app vetting, MDM/MAM governance, and SOC workflows can identify applications that request or use sensitive account/keychain capabilities, and whether exceptions are documented for legitimate business apps. This can support compliance evidence around mobile application review and identity data protection, but local telemetry and policy enforcement determine actual coverage.
Technical view
For iOS, validate whether telemetry or app assessment processes can observe use of Keychain services by applications under review or deployed to managed devices. The official description also references Android AccountManager API calls and MANAGE_ACCOUNTS manifest review; however, the supplied platform field is iOS, so Android use should be treated as description context rather than platform scope for this object. No ATT&CK tactic, relationship context, or formal detection logic is supplied, so SOC teams should treat this as a detection-strategy prompt rather than a ready-to-deploy analytic.
Likely telemetry
- Mobile application vetting results for sensitive account or credential-related API usage
- iOS application behavior or static analysis indicators involving Keychain services
- Mobile device management or mobile application management inventory showing installed or approved apps
- Application permission and entitlement review data where available
- Security review records documenting business justification for account or credential-store access
Detection direction
- Validate that mobile app review processes flag apps that use account or credential-related services and route them for additional scrutiny.
- Tune review outcomes around business context: password managers, enterprise SSO clients, banking apps, and device management agents may legitimately interact with credential stores.
- Confirm whether the organization has visibility into API usage or only static metadata; lack of runtime visibility may create blind spots.
- Because no official detection logic is provided, avoid treating a single API reference as malicious without corroborating app reputation, provenance, permissions, behavior, and business need.
- Document the platform-scope limitation: the object lists iOS, while the description includes Android-specific AccountManager and MANAGE_ACCOUNTS references.
Mitigation priorities
- Establish or strengthen mobile application vetting for apps that access sensitive account or keychain-related capabilities.
- Require documented business justification and approval for apps that need credential or account-store access.
- Use MDM/MAM policy to control which reviewed applications may be installed or used in managed environments.
- Feed vetted findings into SOC and incident response workflows so suspicious mobile identity behavior can be investigated with device and app context.
- Maintain compliance evidence showing how mobile apps with sensitive identity-related access are reviewed, approved, and periodically reassessed.
Analyst notes and limits
This is a detection analytic object, not a technique or intrusion report. Its strongest decision value is in validating mobile application governance and identity-related telemetry rather than deploying a specific signature. The absence of tactics and relationships limits ATT&CK-driven prioritization, so local mobile estate criticality, app inventory, and identity architecture should drive ranking.
The object provides no official detection logic, no tactics, no relationships, and no evidence of active exploitation or attribution. The platform field lists iOS, while the official description also contains Android-specific references; this take preserves that distinction and does not expand the supported platform scope beyond the supplied fields.
Analytic 1709
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.
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 | 1.0 | Current bundle | 00882b965cc5… |
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 AN1709Open 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.