AN1650: Analytic 1650
OLD: 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.
NEW: A defender observes an Android application requesting for `android.permission.READ_CALL_LOG`, which may also be listed in the application's manifest file.
Analyst context for executives and security teams
This analytic is a mobile security signal for Android apps that request access to call logs through `android.permission.READ_CALL_LOG`. For leaders, the value is governance and risk triage: most apps do not need call-log access, so this permission should trigger review before an app is approved, deployed, or allowed to remain on managed devices.
Executive priority
Prioritize this as part of mobile application vetting, privacy risk management, and compliance evidence for Android environments. The key business question is whether the organization can identify apps requesting sensitive call-log access and make an approval, exception, or removal decision before that access creates unnecessary exposure.
Technical view
SOC, mobile security, and endpoint teams should validate whether Android application manifests and device permission states are visible in existing tooling. The supplied ATT&CK object does not specify tactics or a detection implementation, so teams should treat this as a permission-based review analytic: flag Android apps requesting `android.permission.READ_CALL_LOG`, then assess whether the app has a legitimate business need and whether users or administrators can revoke the permission through device settings.
Likely telemetry
- Android application manifest data
- Mobile application inventory
- Android app permission requests
- Current device permission state for installed applications
- Mobile device management or enterprise mobility management records, where available
Detection direction
- Confirm that Android apps requesting `android.permission.READ_CALL_LOG` are surfaced during application vetting or mobile inventory review.
- Tune review workflows to distinguish approved business applications from apps with no clear need for call-log access.
- Validate whether permission revocation or app removal decisions are recorded as audit evidence.
- Account for the main blind spot: the ATT&CK object provides no behavioral detection logic beyond observing the permission request, so local app context is required before escalation.
Mitigation priorities
- Establish or update mobile application vetting criteria for sensitive Android permissions, including call-log access.
- Require business justification and approval for Android apps requesting `android.permission.READ_CALL_LOG`.
- Use Android device settings or managed device controls, where available, to revoke unnecessary call-log permissions.
- Maintain an inventory of approved exceptions and periodically revalidate whether the permission is still required.
Analyst notes and limits
This object is a detection analytic in the ATT&CK mobile domain for Android. It focuses on observing an Android application requesting `android.permission.READ_CALL_LOG`, potentially in the application manifest. No tactics, relationships, aliases, or official detection text were supplied, so the strongest use is as a mobile app permission governance and triage signal rather than a standalone incident indicator.
The supplied ATT&CK fields do not provide associated techniques, adversary use, detection pseudocode, data sources, or relationships. This take should not be interpreted as proof of malicious activity; local app purpose, device management visibility, and permission state evidence are required.
Analytic 1650
OLD: 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.
NEW: A defender observes an Android application requesting for `android.permission.READ_CALL_LOG`, which may also be listed in the application's manifest file.
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 | f15d5505eb44… |
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 AN1650Open 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.