AN1787: Analytic 1787
The user can view permissions granted to an application in device settings. Application vetting services typically flag permissions requested by an application, which can be reviewed by an administrator. Certain dangerous permissions, such as `RECEIVE_SMS`, could receive additional scrutiny.
Analyst context for executives and security teams
This analytic is about validating visibility into mobile application permissions on iOS. For leaders, the practical value is governance: knowing whether users, administrators, and application vetting processes can see and review what permissions an app has been granted before that access becomes a privacy, compliance, or operational concern.
Executive priority
Treat this as a mobile security and compliance readiness checkpoint rather than a standalone detection. Security leaders should ask whether the organization has an approved process for reviewing mobile app permissions, whether administrators can evidence that review, and whether higher-risk permission requests receive additional scrutiny before apps are allowed in managed environments.
Technical view
Because no official detection logic or ATT&CK tactics are provided, SOC and mobile security teams should focus on control validation. Confirm that iOS device settings, mobile device management records where available, and application vetting outputs can show permissions granted or requested by apps. Detection engineering should avoid assuming this analytic produces alertable behavior without local telemetry or policy logic.
Likely telemetry
- iOS device settings showing application permissions
- Mobile application vetting results that list requested permissions
- Administrative review records for approved or denied mobile applications
- Mobile device management or enterprise mobility inventory data where deployed
Detection direction
- Validate whether permission visibility exists for managed iOS devices and whether it is centrally reviewable or only user-visible on-device.
- Tune review workflows around permissions that create privacy, messaging, location, microphone, camera, contacts, or other sensitive-access concerns, using locally defined policy thresholds.
- Account for blind spots where unmanaged devices, personally owned devices, or apps outside enterprise vetting are not visible to administrators.
- Do not treat the presence of a permission request as inherently malicious; review app business purpose, user role, and approved-use context.
Mitigation priorities
- Establish or confirm a mobile application vetting process that records requested permissions before approval.
- Define policy criteria for permissions requiring additional review or denial.
- Use managed mobile controls where available to inventory approved applications and support administrator review.
- Maintain compliance evidence showing permission review decisions, especially for apps handling sensitive business or personal data.
- Educate users and support teams on where app permissions can be viewed and when suspicious or unnecessary access should be escalated.
Analyst notes and limits
The supplied object is a detection analytic in the mobile ATT&CK domain with platform iOS. Its official description emphasizes user-visible permissions in device settings and administrator review through application vetting services. No relationships, tactics, or official detection logic were supplied, so this take frames the object as a visibility and governance validation item.
Coverage depends on local mobile management, application vetting, and administrative review processes. The object does not provide alert logic, event fields, adversary behavior, relationships, or evidence of exploitation. The description includes an example dangerous permission, but defenders should map permission risk to the actual iOS and enterprise controls in their environment.
Analytic 1787
The user can view permissions granted to an application in device settings. Application vetting services typically flag permissions requested by an application, which can be reviewed by an administrator. Certain dangerous permissions, such as `RECEIVE_SMS`, could receive additional scrutiny.
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 | b241e33005eb… |
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 AN1787Open 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.