AN1783: Analytic 1783
Application vetting services could look for `android.permission.READ_CONTACTS` in an Android application’s manifest, or `NSContactsUsageDescription` in an iOS application’s `Info.plist` file. Most applications do not need contact list 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 the contact list through the device settings screen, revoking the permission if necessary.
Analyst context for executives and security teams
This analytic is about flagging mobile apps that ask for access to the user’s contact list. For an executive or security leader, the value is privacy and governance: contact data can expose employees, customers, partners, and relationship maps, and many apps do not need it to perform their business function.
Executive priority
Prioritize this as a mobile application vetting and privacy-control question rather than a traditional SOC alert. Leaders should ask whether approved iOS applications are reviewed for contact-list access requests, whether there is a business justification for that access, and whether users or administrators can revoke unnecessary permissions when identified. This supports compliance evidence, mobile risk management, and reducing unnecessary exposure of sensitive relationship data.
Technical view
For the supplied iOS platform, validate whether app vetting reviews inspect an application’s Info.plist for NSContactsUsageDescription. Treat the presence of contact access requests as a review trigger, not automatic maliciousness. SOC, IR, and mobile security teams should distinguish legitimate use cases, such as communications or contact-management functions, from apps where contact access is unrelated to expected behavior. No ATT&CK tactic, relationship context, or formal detection logic was supplied, so this should be implemented as a governance/vetting analytic rather than a guaranteed detection rule.
Likely telemetry
- iOS application Info.plist contents, specifically NSContactsUsageDescription
- Mobile application vetting results showing requested privacy permissions
- Inventory of approved or deployed mobile applications
- Device-level contact permission state where available through settings review or approved management processes
- Exception records documenting business justification for applications that require contact-list access
Detection direction
- Confirm that app review workflows actually parse and retain iOS permission-purpose strings from Info.plist files.
- Tune review criteria so contact-list access creates extra scrutiny rather than a blanket block; legitimate applications may require the permission.
- Compare requested contact access against the app’s stated business purpose and approved use case.
- Look for blind spots in apps installed outside normal vetting or approval processes.
- Because no official detection logic is provided, require local validation before using this as compliance or SOC coverage evidence.
Mitigation priorities
- Establish a baseline of approved iOS applications and their expected contact-list permission requirements.
- Require additional review or business justification for applications requesting contact access.
- Use device settings processes to revoke contact permissions when access is unnecessary, as described in the official object.
- Document exceptions so privacy, audit, and incident response teams can explain why contact access was allowed.
- Periodically re-review approved apps because permission requests and business use can change over time.
Analyst notes and limits
The supplied ATT&CK object is a mobile detection analytic, AN1783, for iOS. The official description also mentions Android manifest permission review, but the supplied platform metadata for this object is iOS, so this take focuses on iOS and Info.plist review. There are no supplied relationships or tactics to connect this analytic to a specific ATT&CK technique chain.
Official detection content was not provided, and no relationships were supplied. This limits confidence in specific alerting logic, false-positive rates, and operational coverage. Local evidence is required to determine which apps are deployed, whether contact access is justified, and whether permissions can be reviewed or revoked in the organization’s mobile environment.
Analytic 1783
Application vetting services could look for `android.permission.READ_CONTACTS` in an Android application’s manifest, or `NSContactsUsageDescription` in an iOS application’s `Info.plist` file. Most applications do not need contact list 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 the contact list through the device settings screen, revoking 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 | 9b24de59acf0… |
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 AN1783Open 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.