AN1775: Analytic 1775
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.
Analyst context for executives and security teams
This analytic is about reviewing mobile apps for calendar-access requests, especially on iOS via the app’s Info.plist usage description. For leaders, the business issue is not the permission itself; it is whether the organization can spot apps asking for access to sensitive schedule data that they do not need. Calendar contents can reveal meetings, travel, customer names, internal projects, and executive routines, so permission review is a practical privacy, mobile security, and compliance control point.
Executive priority
Prioritize this where managed or BYOD iOS devices handle executive, legal, healthcare, customer, or operational scheduling data. Security leaders should ask whether app vetting, mobile device governance, and user permission review can identify unnecessary calendar access before or shortly after app installation. This supports audit evidence for least privilege and privacy governance, but the supplied ATT&CK object does not establish a specific tactic, adversary, or active exploitation pattern.
Technical view
For SOC, mobile security, and app-vetting teams, validate whether iOS app assessment processes inspect Info.plist for NSCalendarsUsageDescription and whether requested calendar access is justified by app function. The official description also references Android manifest permissions, but this ATT&CK object’s supplied platform is iOS, so iOS validation should be the primary scope for this take. Because no official detection logic is provided, teams should treat this as a control-validation analytic rather than a complete alert rule.
Likely telemetry
- iOS application metadata collected during app vetting or mobile application management review
- Info.plist contents, specifically NSCalendarsUsageDescription
- Mobile device permission state showing which applications have calendar access
- App inventory from managed iOS devices
- User or administrator records of permission revocation through device settings
Detection direction
- Confirm that app-vetting workflows flag apps requesting calendar access for additional review.
- Tune review criteria around business justification: many apps do not need calendar access, but productivity, scheduling, travel, conferencing, or workflow apps may have legitimate reasons.
- Validate whether permission state is visible after installation, not only at pre-approval time, because users can grant or revoke access through device settings.
- Avoid treating every calendar permission request as malicious; use it as a prioritization signal for scrutiny and least-privilege review.
- Document blind spots where unmanaged iOS devices, incomplete app inventory, or lack of Info.plist inspection prevent reliable assessment.
Mitigation priorities
- Apply least-privilege app approval standards for calendar access on managed iOS devices.
- Require extra review for applications that request NSCalendarsUsageDescription without a clear business need.
- Use device settings or mobile management processes to revoke calendar access when unnecessary.
- Educate users and support teams to question calendar permission prompts that do not align with app function.
- Maintain compliance evidence showing app permission review, exceptions, and remediation decisions.
Analyst notes and limits
This is a mobile ATT&CK detection analytic, external ID AN1775, for iOS. It has no supplied tactic, no relationships, and no official detection section. The official description provides the core review logic: inspect calendar-permission declarations and apply extra scrutiny because most applications do not need calendar access.
Coverage depends on local app inventory, access to iOS application metadata, visibility into permission state, and governance over managed versus unmanaged devices. The supplied object does not provide adversary context, detection pseudocode, severity, impact, or relationship mappings, so local risk ranking must be based on the sensitivity of calendar data and device population.
Analytic 1775
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.
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 | c15e63e369e7… |
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 AN1775Open 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.