AN1651: Analytic 1651
Application vetting services could look for `android.permission.READ_CALL_LOG` in an Android application’s manifest. Most applications do not need call log access, so extra scrutiny could be applied to those that request it. On Android, the user can manage which applications have permission to access the call log through the device settings screen, revoking the permission if necessary.
Analyst context for executives and security teams
This analytic is meant to support mobile application vetting by flagging apps that request access to call logs, specifically the Android manifest permission `android.permission.READ_CALL_LOG` described in the official text. For leaders, the practical value is governance: call-log access can expose sensitive relationship, customer, employee, or operational metadata, so app approval processes should not treat this as a routine permission. Note that the supplied platform field lists iOS while the description is Android-specific, so teams should resolve that inconsistency before using it as control evidence.
Executive priority
Prioritize this as a mobile risk-management and compliance-readiness check rather than a standalone SOC detection. Security leaders should ask whether corporate app vetting, MDM/UEM policy review, and mobile privacy controls can identify applications requesting high-risk permissions and document why access is justified. This matters for BYOD and managed-device programs because excessive mobile permissions can create privacy, legal, and operational exposure even without confirmed malware activity.
Technical view
The supplied ATT&CK object provides an analytic concept but no official detection logic and no relationship context. Detection and mobile security teams should validate whether their app-vetting pipeline can inspect mobile application manifests for `android.permission.READ_CALL_LOG`, identify the requesting application, and support analyst review of whether call-log access is expected. Because the object’s platform metadata says iOS but the description references Android, do not map this blindly to iOS telemetry; treat the Android permission reference as the concrete technical indicator supplied by the description and confirm the intended platform in local content management.
Likely telemetry
- Mobile application manifest metadata collected during app vetting or app-store review
- MDM/UEM application inventory and permission reporting, if available
- Device settings or permission-state records showing whether call-log access is granted or revoked
- Application approval records documenting business justification for sensitive permissions
Detection direction
- Validate that app-vetting services can parse manifests and surface `android.permission.READ_CALL_LOG` requests for review.
- Tune review workflows to avoid treating every permission request as malicious; some apps may have a legitimate business reason, but the justification should be explicit.
- Confirm whether telemetry covers managed devices, BYOD devices, sideloaded apps, and apps installed outside approved channels, as these are common mobile governance blind spots.
- Do not claim analytic coverage from ATT&CK alone: the object has no official detection logic, tactics, or relationships supplied.
Mitigation priorities
- Require additional scrutiny or approval for applications requesting call-log access.
- Use mobile device settings or management controls, where available, to revoke unnecessary call-log permission.
- Maintain an app inventory with permission metadata and documented business justification for sensitive mobile permissions.
- Align mobile app-vetting evidence with privacy, compliance, and incident-response requirements so investigators can quickly determine which apps had access to call-log data.
Analyst notes and limits
The object is an ATT&CK mobile detection analytic, external ID AN1651, linked to DET0602. Its official description is narrowly focused on identifying Android call-log permission requests during application vetting. There are no supplied relationships, aliases, labels, tactics, or detection implementation details.
The supplied metadata contains a material inconsistency: platform is listed as iOS, while the official description refers to Android manifest permission `android.permission.READ_CALL_LOG` and Android device settings. Local validation is required before using this as platform-specific detection content or audit evidence. No active exploitation, attribution, impact, or guaranteed detection coverage is supported by the supplied fields.
Analytic 1651
Application vetting services could look for `android.permission.READ_CALL_LOG` in an Android application’s manifest. Most applications do not need call log access, so extra scrutiny could be applied to those that request it. On Android, the user can manage which applications have permission to access the call log through the device settings screen, revoking the permission if necessary.
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 | 4c48e9f7016a… |
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 AN1651Open 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.