AN1774: Analytic 1774
OLD: Application vetting services could look for `android.permission.READ_CALENDAR` or `android.permission.WRITE_CALENDAR` in an Android application’s manifest, or `NSCalendarsUsageDescription` in an iOS application’s `Info.plist` file. Most applications do not need calendar access, so extra scrutiny could be applied to those that request it. On both Android and iOS, the user can manage which applications have permission to access calendar information through the device settings screen, revoke the permission if necessary.
NEW: A defender observes an Android application requesting for `android.permission.READ_CALENDAR` or `android.permission.WRITE_CALENDAR`, which may also be listed in the application’s Manifest.
Analyst context for executives and security teams
This analytic is about identifying Android apps that request calendar read or write permissions. For security leaders, the practical value is governance: calendar data can expose meetings, contacts, business relationships, travel, and operational schedules, so unnecessary access should trigger review before apps are approved or widely deployed.
Executive priority
Treat calendar permission review as part of mobile application risk management and compliance evidence. The key business question is whether approved Android apps have a legitimate need to access calendar data, and whether the organization can prove that risky or unnecessary permissions are reviewed, denied, or removed during app vetting and device management processes.
Technical view
SOC, mobile security, and app-vetting teams should validate whether they can inspect Android application manifests for `android.permission.READ_CALENDAR` and `android.permission.WRITE_CALENDAR`. Because no ATT&CK detection logic is supplied beyond the permission observation, this should be treated as a permission-risk analytic rather than a standalone malicious-behavior detection. Triage should compare the requested permission against the app’s business purpose, publisher trust, deployment scope, and whether users or administrators can revoke access through device settings or mobile management controls.
Likely telemetry
- Android application manifest metadata
- Mobile application vetting results
- Mobile device management or enterprise mobility management app inventory
- Android device permission state/configuration
- Approved application catalog and business justification records
Detection direction
- Flag Android apps requesting `android.permission.READ_CALENDAR` or `android.permission.WRITE_CALENDAR`.
- Tune review thresholds based on app category and business purpose; calendar apps may be expected to request this access, while unrelated apps should receive extra scrutiny.
- Validate whether the organization collects both pre-deployment app manifest data and post-deployment permission state from managed devices.
- Avoid treating the permission request alone as proof of compromise; it is a risk signal requiring context.
- Look for blind spots in unmanaged Android devices, sideloaded applications, and apps approved before current permission-review standards were in place.
Mitigation priorities
- Require mobile app vetting for applications before enterprise approval or broad deployment.
- Document business justification for Android apps that request calendar read or write permissions.
- Use device settings or mobile management controls to revoke or restrict unnecessary calendar access where feasible.
- Maintain an approved app catalog and periodically re-review apps after updates, since permissions can change across versions.
- Align evidence from app vetting and permission review with privacy, compliance, and mobile security governance requirements.
Analyst notes and limits
The supplied ATT&CK object is a mobile detection analytic for Android and provides a narrow observation: an application requests calendar read or write permission, potentially visible in the Manifest. There are no supplied tactics, relationships, procedure examples, or formal detection logic, so the defensible use is permission-risk review and mobile app governance rather than behavioral threat detection.
This take is limited to the official STIX fields and external reference supplied. The object does not provide relationship context, active threat use, detection pseudocode, data source mappings, or impact details. Local app inventory, MDM coverage, business justification, and device management evidence are required to determine material risk.
Analytic 1774
OLD: Application vetting services could look for `android.permission.READ_CALENDAR` or `android.permission.WRITE_CALENDAR` in an Android application’s manifest, or `NSCalendarsUsageDescription` in an iOS application’s `Info.plist` file. Most applications do not need calendar access, so extra scrutiny could be applied to those that request it. On both Android and iOS, the user can manage which applications have permission to access calendar information through the device settings screen, revoke the permission if necessary.
NEW: A defender observes an Android application requesting for `android.permission.READ_CALENDAR` or `android.permission.WRITE_CALENDAR`, which may also be listed in the application’s Manifest.
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 | de6aae6082a8… |
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 AN1774Open 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.