DET0679: Detection of Contact List
DET0679 is a mobile detection strategy for identifying attempts to collect a user’s contact list, mapped to ATT&CK technique T1636.003 Contact List. The bu...
Analyst context for executives and security teams
DET0679 is a mobile detection strategy for identifying attempts to collect a user’s contact list, mapped to ATT&CK technique T1636.003 Contact List. The business issue is not just privacy: contact data can expose customers, employees, executives, partners, and social graphs that may support follow-on fraud, phishing, or targeting. Because MITRE provides no official detection text for this strategy, organizations should treat it as a coverage-validation item rather than an out-of-the-box analytic.
Executive priority
Security leaders should ask whether mobile security, privacy, and incident response programs can prove when apps access contact data on Android and iOS devices. This matters for executive and regulated-user devices, bring-your-own-device governance, investigation readiness, and compliance evidence around sensitive personal data handling. Priority should be higher where mobile devices contain business contacts, customer relationships, or privileged staff communications.
Technical view
The related technique describes adversaries using standard OS APIs to gather contact list data: Android Contacts Content Provider and iOS Contacts framework, with additional concern if a device is rooted or jailbroken. SOC and mobile security teams should validate whether they can observe contact-permission grants, app behavior involving contact access, suspicious or unexpected applications requesting contacts, and rooted or jailbroken device state. Because the ATT&CK object has no official detection guidance and no platform field of its own, implementation must be based on local Android/iOS fleet architecture, MDM/MAM capabilities, mobile threat defense telemetry, and endpoint privacy controls.
Likely telemetry
- Mobile device management or mobile application management records for installed apps, permissions, and policy state
- Mobile threat defense alerts or behavioral events related to contact access or risky apps
- Android permission and application inventory data related to Contacts Content Provider access
- iOS application permission state and access to Contacts framework where observable through enterprise tooling
- Root or jailbreak detection signals
Detection direction
- Inventory which enterprise tools can actually report contact-list permission state and contact-access behavior on Android and iOS; do not assume visibility exists by default.
- Flag unexpected, newly installed, sideloaded, unmanaged, or low-reputation apps requesting access to contacts, with tuning for legitimate communications, collaboration, CRM, and productivity apps.
- Correlate contact-access concern with rooted or jailbroken device indicators, because the related technique notes contact data may be accessed without user knowledge or approval in those conditions.
- Use allowlists or business-justified app baselines to reduce false positives from approved apps that legitimately need contact access.
- Preserve mobile app, permission, and device-state evidence for incident response, since the official ATT&CK object does not provide a ready analytic or detection procedure.
Mitigation priorities
- Establish policy baselines for which managed mobile apps may access contacts and require business justification for exceptions.
- Use MDM/MAM or equivalent controls to restrict unmanaged, sideloaded, or noncompliant apps from accessing enterprise data where supported.
- Prioritize detection and containment workflows for rooted or jailbroken devices, especially for executive, privileged, or regulated-user populations.
- Review mobile app permission requests during app approval and procurement processes, particularly for apps that request contacts without clear business need.
- Document mobile permission monitoring and response procedures as compliance and incident-readiness evidence.
Analyst notes and limits
This is a detection strategy object, not a technique description with full detection content. The only behavioral detail comes from its relationship to T1636.003 Contact List, which identifies Android and iOS mechanisms for contact-list access. A useful assessment should therefore test local telemetry and control coverage rather than relying on ATT&CK to define a complete analytic.
MITRE supplied no official description, no official detection text, no tactics, and no platforms on the detection-strategy object itself. Android and iOS are supported only through the related Contact List technique. Local device ownership model, MDM/MAM deployment, privacy settings, and mobile telemetry determine practical detectability.
Detection of Contact List
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1636.003 | Contact List Sub-technique | This object detects Contact List. |
All related ATT&CK context
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 | d51b1f8ed4a7… |
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 DET0679Open 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.