DC0116: Permissions Request
System prompts triggered when an application requests new or additional permissions
Analyst context for executives and security teams
Permissions Request is a mobile ATT&CK data component covering the system prompts users see when an application asks for new or additional permissions. For leaders, its value is not that a prompt is malicious by itself, but that permission changes can be important evidence during mobile app risk reviews, incident response, privacy investigations, and compliance discussions about what access an app requested and when.
Executive priority
Treat permission-request visibility as part of mobile governance and incident readiness. Security and risk owners should ask whether the organization can reconstruct permission prompts for managed or business-critical mobile apps, especially when investigating suspicious app behavior, excessive data access, or user-consent concerns. Because ATT&CK provides no detection guidance or platform detail for this object, priority should be based on local mobile device management, privacy, regulatory, and business-use requirements.
Technical view
SOC, IR, and mobile security teams should validate whether permission-request events are observable in their mobile management, endpoint, application, or audit data sources. The key defensive question is whether teams can distinguish expected application permission prompts from unusual new or additional permission requests during an investigation. Since no ATT&CK tactics, platforms, detections, or relationships are supplied, this component should be used as an evidence category rather than a standalone detection analytic.
Likely telemetry
- Mobile operating system permission prompt or consent records where available
- Mobile device management or enterprise mobility management inventory and application state data
- Application audit logs or privacy/access records if exposed by the app or management tooling
- User-reported screenshots or helpdesk records of unexpected permission prompts
- Change records for app installs, updates, or configuration changes that may explain new permission requests
Detection direction
- Confirm whether permission-request events are collected at all; many environments may only see final permission state, not the original prompt.
- Correlate new or additional permission requests with app installation, app update, policy change, or user report context before treating them as suspicious.
- Tune reviews around sensitive or business-relevant permissions rather than alerting on every prompt, because legitimate apps often request permissions during normal feature use.
- Use this data component to support investigation timelines and app risk review workflows, not as proof of malicious activity by itself.
- Document visibility gaps where managed mobile tooling cannot capture prompts or historical permission-request timing.
Mitigation priorities
- Establish a mobile app governance process that reviews requested permissions before approving apps for enterprise use.
- Use mobile management controls, where available, to standardize approved apps and reduce unsanctioned permission exposure.
- Educate users to report unexpected or excessive permission prompts, especially for business apps or apps handling sensitive data.
- Maintain audit evidence for app approval, permission review, and policy decisions to support compliance and incident response.
- During incidents, compare requested permissions against the app’s expected business purpose and recent changes.
Analyst notes and limits
This object is a data component, not an adversary technique. The supplied ATT&CK content defines it narrowly as system prompts triggered when an application requests new or additional permissions. There are no supplied relationships, tactics, platforms, or official detection text, so analysis should remain focused on evidence collection and defensive validation.
ATT&CK provides no official detection logic, no platform list, and no relationship context for this object in the supplied fields. Local mobile operating system behavior, device-management tooling, application logging, and privacy requirements will determine whether this evidence is available and useful.
Permissions Request
System prompts triggered when an application requests new or additional permissions
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 | 61ac3ec54aaf… |
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 DC0116Open 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.