AN1707: Analytic 1707
Application vetting services could look for usage of the `READ_PRIVILEGED_PHONE_STATE` Android permission. This could indicate that non-system apps are attempting to access information that they do not have access to.
Analyst context for executives and security teams
This analytic is about mobile application vetting for suspicious permission use, specifically looking for the Android `READ_PRIVILEGED_PHONE_STATE` permission as a sign that a non-system app may be trying to access privileged device information. However, the supplied ATT&CK platform field lists iOS while the description references an Android permission, so teams should treat this object as requiring source validation before using it for platform-specific control decisions.
Executive priority
The business value is in mobile application governance: validating that app review processes can identify requests for privileged device access before software is approved, deployed, or trusted. For leaders, the key question is whether mobile app vetting produces auditable evidence of risky permission use and whether exceptions are reviewed by security, privacy, or compliance owners. Because the object has sparse ATT&CK context and an apparent platform-description mismatch, it should not be used alone to justify coverage claims or platform risk conclusions.
Technical view
SOC, mobile security, and application governance teams should validate whether their app vetting workflow can inspect application manifests or equivalent metadata for privileged permission requests, especially `READ_PRIVILEGED_PHONE_STATE` as named in the official description. The analytic does not provide official detection logic, tactics, or relationship context, so implementation should be treated as a control-validation item rather than a complete detection. The listed platform is iOS, but the described permission is Android-specific, making platform scoping a primary validation step before operational use.
Likely telemetry
- Mobile application package metadata or manifest contents from app vetting services
- Permission request inventory for submitted or approved mobile applications
- Application source, signing, publisher, and distribution-channel records where available
- App approval, exception, and review workflow logs
- Mobile device management or mobile application management inventory showing installed or approved apps
Detection direction
- Confirm the platform scope before implementation because the supplied platform field lists iOS while the described permission is Android-oriented.
- Validate whether app vetting tools can flag privileged permission declarations and distinguish system apps from non-system apps.
- Tune review workflows to reduce false positives from legitimate system or managed applications while escalating unexpected privileged permission use in third-party or enterprise apps.
- Use this analytic as a pre-deployment or app-governance check; the supplied object does not include runtime detection logic or incident telemetry guidance.
- Require local allowlists, business ownership, and exception records so SOC or governance teams can determine whether a flagged permission request is expected.
Mitigation priorities
- Establish or validate a mobile application vetting process that reviews permission requests before apps are approved for use.
- Require documented business justification and security review for privileged or sensitive permission requests.
- Maintain an inventory of approved mobile apps, publishers, signing identities, and granted exceptions.
- Align mobile app approval evidence with compliance and privacy requirements where device or subscriber information may be sensitive.
- Do not assert platform-specific mitigation coverage until the Android-permission versus iOS-platform inconsistency is resolved against local requirements and authoritative ATT&CK context.
Analyst notes and limits
This object is a detection analytic in the mobile ATT&CK domain with external ID AN1707. The official description references `READ_PRIVILEGED_PHONE_STATE`, an Android permission, while the supplied platform field is iOS. No tactics, relationships, aliases, labels, or official detection text were supplied. The safest interpretation is that this is an app-vetting analytic with incomplete or conflicting platform context.
The take is constrained by sparse official fields. There is no supplied detection logic, no related technique or data-source relationships, and no evidence of exploitation, attribution, or impact. Local mobile platform scope, app inventory, and vetting-tool capabilities are required before making coverage or risk statements.
Analytic 1707
Application vetting services could look for usage of the `READ_PRIVILEGED_PHONE_STATE` Android permission. This could indicate that non-system apps are attempting to access information that they do not have access to.
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 | 1e11c268fc7a… |
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 AN1707Open 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.