Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0602: Detection of Call Log

DET0602 is a mobile ATT&CK detection strategy for behavior related to access or collection of call log data. For leaders, the practical issue is not just p...

MobileDET0602Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0602 is a mobile ATT&CK detection strategy for behavior related to access or collection of call log data. For leaders, the practical issue is not just privacy: call history can expose customer relationships, executive communications, regulated personal data, investigations, and operational contacts. The related ATT&CK technique, T1636.002 Call Log, applies to Android and iOS context, with Android offering standard APIs for call log access and iOS requiring jailbreak/root-level conditions for comparable access according to the supplied relationship context.

Executive priority

Prioritize this as a mobile data-protection and incident-readiness question: can the organization prove which managed or high-risk mobile devices have applications, permissions, or device states that could allow call log access? Security leaders should ask whether mobile device management, application governance, privacy controls, and incident response procedures can identify suspicious call log access, especially for executives, regulated users, field operations, and bring-your-own-device populations where visibility may be limited.

Technical view

The official detection strategy object does not provide detection logic, platforms, or tactics, so defenders should anchor validation to the related technique T1636.002. For Android, confirm visibility into applications requesting or using call log-related permissions and relevant OS/API access where enterprise tooling permits. For iOS, focus validation on jailbreak/root indicators and unauthorized device state because the supplied relationship states there is no standard iOS API for call log access. SOC and IR teams should test whether mobile telemetry can distinguish expected business applications from unusual or unauthorized access patterns without assuming full endpoint-like coverage on mobile devices.

Likely telemetry

  • Mobile device management or enterprise mobility management inventory and compliance state
  • Mobile application inventory and application reputation/governance records
  • Android application permission state, especially call log-related permissions where collected
  • Mobile OS security posture signals, including jailbreak or root indicators
  • Mobile threat defense alerts where deployed

Detection direction

  • Validate whether the organization collects any telemetry capable of observing call log permission grants, risky applications, or suspicious mobile device state; do not assume coverage from traditional endpoint tooling.
  • For Android-related coverage, review detections around applications requesting or using call log access and tune for approved dialer, communications, support, or productivity applications to reduce false positives.
  • For iOS-related coverage, prioritize detection of jailbreak/root conditions or unmanaged device states, since the supplied relationship states iOS has no standard API for call log access.
  • Correlate mobile alerts with device ownership, user risk, application install source, and compliance posture to support triage decisions.
  • Document known blind spots for unmanaged/BYOD devices, limited mobile telemetry retention, privacy constraints, and devices outside enterprise management.

Mitigation priorities

  • Establish or confirm mobile device management coverage for users and roles where call log exposure would create business, privacy, or operational risk.
  • Restrict or govern applications that request call log access, especially on Android, using enterprise application control processes where available.
  • Enforce mobile compliance policies that identify rooted or jailbroken devices and define response actions for noncompliant devices.
  • Maintain an approved mobile application baseline and review exceptions for users with sensitive communications.
  • Ensure incident response playbooks include mobile evidence handling, user notification considerations, and privacy/legal review for call log-related investigations.
Analyst notes and limits

This take is based on the DET0602 detection strategy metadata and its relationship to T1636.002 Call Log. The source object itself provides no official description or detection text, so recommendations are framed as validation questions and telemetry/control priorities rather than confirmed detection analytics.

ATT&CK does not specify DET0602 platforms, tactics, detection logic, or data sources in the supplied fields. Local mobile management architecture, BYOD policy, privacy requirements, and available telemetry will determine actual detection and response feasibility.

Official MITRE ATT&CK definition

Detection of Call Log

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
Mobile T1636.002 Call Log Sub-technique This object detects Call Log.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
0d317b7032de435e...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 0d317b7032de…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0602
    Open source URL
Source and licensing

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.