AN1795: Analytic 1795
OLD: Application vetting services could look for `android.permission.READ_SMS` in an Android application’s manifest. Most applications do not need access to SMS messages, so extra scrutiny could be applied to those that request it. On Android, the user can manage which applications have permission to access SMS messages through the device settings screen, revoking the permission if necessary.
NEW: A defender observes an Android application requesting for `android.permission. READ_SMS` and/or ` android.permission. RECEIVE_SMS `, which may also be listed in the application's manifest file.
Analyst context for executives and security teams
This analytic matters because SMS access on Android can expose sensitive business communications and one-time passcodes if granted to an unnecessary or untrusted app. The ATT&CK object is narrow: it focuses on observing Android applications that request `android.permission.READ_SMS` and/or `android.permission.RECEIVE_SMS`, including where those permissions appear in the application manifest.
Executive priority
Security leaders should treat SMS permissions as a mobile application risk review item, especially for managed Android devices and enterprise-approved apps. The decision value is in confirming whether mobile app vetting, device management, or user-permission review processes can identify apps requesting SMS access and trigger extra scrutiny before sensitive users or business workflows are exposed.
Technical view
For SOC, mobile security, and IR teams, validate whether Android app inventory and application vetting processes capture requested permissions from app manifests and runtime permission requests. Because no ATT&CK detection logic, tactic, or relationship context is supplied, this should be handled as a permission-risk signal rather than a standalone malicious-behavior alert. Review apps requesting `READ_SMS` or `RECEIVE_SMS` for business justification, source, user population, and whether users or administrators can revoke the permission through Android device settings where appropriate.
Likely telemetry
- Android application manifest permission data
- Mobile device/application inventory
- Mobile app vetting or application review results
- Android permission grant or request records where available
- User or administrator device-settings permission state for SMS access
Detection direction
- Flag Android applications requesting `android.permission.READ_SMS` and/or `android.permission.RECEIVE_SMS` for review.
- Tune triage around whether the app has a legitimate business need for SMS access; many benign apps may request permissions for functional reasons, so permission presence alone should not be treated as proof of compromise.
- Prioritize review for apps installed on sensitive users' devices, broadly deployed apps, or apps outside approved distribution and vetting workflows, if that local context is available.
- Check for blind spots where app inventories do not parse manifests, do not retain permission history, or cannot distinguish requested permissions from granted permissions.
Mitigation priorities
- Establish or enforce mobile application vetting for Android apps that request SMS permissions.
- Require documented business justification for enterprise-approved apps needing `READ_SMS` or `RECEIVE_SMS`.
- Use Android device settings or managed-device controls, where available, to revoke unnecessary SMS permissions.
- Educate users and support teams to question SMS permission prompts from apps without a clear business purpose.
- Maintain audit evidence showing how SMS-access permissions are reviewed and remediated for managed Android devices.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, AN1795, for the Android platform in the mobile domain. It provides a specific permission-focused observation but no official detection implementation and no relationship context. Treat this as a mobile permission governance and app-vetting use case rather than a complete detection strategy.
The object does not specify tactics, related techniques, adversary use, active exploitation, or detection logic. Local mobile management, app inventory, permission-state telemetry, and business context are required to determine severity and response.
Analytic 1795
OLD: Application vetting services could look for `android.permission.READ_SMS` in an Android application’s manifest. Most applications do not need access to SMS messages, so extra scrutiny could be applied to those that request it. On Android, the user can manage which applications have permission to access SMS messages through the device settings screen, revoking the permission if necessary.
NEW: A defender observes an Android application requesting for `android.permission. READ_SMS` and/or ` android.permission. RECEIVE_SMS `, 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 | 25c6a8cd770d… |
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 AN1795Open 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.