DC0114: Application Permission
Represents the permissions, entitlements, or capability grants associated with a mobile application, including both permissions declared by the application and those granted or requested during runtime.
Monitoring permission state helps defenders identify applications attempting to access protected device resources such as sensors, storage, communications interfaces, or system services.
Examples include:
Android
- Permissions declared in AndroidManifest.xml - Runtime permission prompts - Special access privileges (AccessibilityService, overlay, device admin)
iOS
- App entitlements in provisioning profiles - Privacy permission prompts - Capability grants for device services
Analyst context for executives and security teams
Application Permission is a mobile ATT&CK data component focused on what permissions, entitlements, or capability grants a mobile app declares, requests, or receives at runtime. For leaders, its value is governance: if the organization cannot see which apps can access protected device resources such as sensors, storage, communications interfaces, or system services, it has limited ability to assess mobile privacy, compliance, and incident risk.
Executive priority
Treat this as a mobile security evidence requirement rather than a single detection rule. Security leaders should ask whether managed mobile apps, high-risk BYOD scenarios, and incident response processes can prove which app permissions were declared, prompted, granted, or elevated. This supports control prioritization, audit evidence, and faster decisions when a mobile app is suspected of excessive or inappropriate access.
Technical view
SOC, mobile security, and IR teams should validate whether they can collect and review application permission state across the mobile estate. The official object includes declared permissions, runtime permission prompts, special access privileges such as AccessibilityService, overlay, and device admin, plus iOS-style app entitlements, privacy prompts, and capability grants. Because ATT&CK provides no detection logic or relationships for this object, teams should define local baselines for expected permissions by app, role, and device context, then investigate unusual permission requests or grants against approved business need.
Likely telemetry
- Mobile application inventory and metadata
- Declared application permissions, such as AndroidManifest.xml entries where available
- Runtime permission prompt and grant state
- Special access privilege state, including accessibility, overlay, and device administration privileges where available
- Application entitlements and provisioning-profile capability data where available
Detection direction
- Validate that permission state is actually collected, retained, and searchable for mobile applications in scope.
- Baseline expected permissions for approved business applications and compare against newly requested, newly granted, or unusually sensitive permissions.
- Prioritize review of permissions that expose protected device resources, including sensors, storage, communications interfaces, and system services, as described by the official object.
- Tune reviews to reduce false positives from legitimate enterprise apps that require broad permissions for business functions, while requiring documented justification for sensitive access.
- Account for blind spots where personal devices, unmanaged apps, or limited mobile telemetry prevent visibility into runtime prompts, entitlements, or special access privileges.
Mitigation priorities
- Define mobile application permission governance: what permissions are acceptable, who approves exceptions, and what evidence must be retained.
- Ensure mobile security, device management, or app vetting processes can inventory declared permissions and granted runtime capabilities for applications in scope.
- Review sensitive or special access grants before deployment and during periodic reassessment, especially for apps with access to protected resources or system services.
- Integrate permission evidence into incident response playbooks so responders can quickly determine what resources a suspicious app could access.
- Use local risk context, compliance obligations, and device ownership models to prioritize remediation where visibility or enforcement is weakest.
Analyst notes and limits
This object is a data component, not a technique. Its main defensive value is helping teams verify whether they have evidence about mobile app permissions, entitlements, prompts, and grants. No ATT&CK relationships were supplied, so this take avoids mapping it to specific tactics, techniques, adversaries, or campaigns.
ATT&CK does not provide an official detection section, platforms are not specified in the object fields, and no relationship context was supplied. Local mobile management architecture, device ownership model, operating system version, and available telemetry will determine what can actually be collected and enforced.
Application Permission
Represents the permissions, entitlements, or capability grants associated with a mobile application, including both permissions declared by the application and those granted or requested during runtime.
Monitoring permission state helps defenders identify applications attempting to access protected device resources such as sensors, storage, communications interfaces, or system services.
Examples include:
Android
- Permissions declared in AndroidManifest.xml - Runtime permission prompts - Special access privileges (AccessibilityService, overlay, device admin)
iOS
- App entitlements in provisioning profiles - Privacy permission prompts - Capability grants for device services
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.1 | Current bundle | 3c6a18f340be… |
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 DC0114Open 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.