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

DET0681: Detection of Protected User Data

DET0681 is a mobile ATT&CK detection strategy for identifying access to protected user data, linked to the mobile technique T1636. The business issue is pr...

MobileDET0681Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0681 is a mobile ATT&CK detection strategy for identifying access to protected user data, linked to the mobile technique T1636. The business issue is privacy and trust: mobile apps that access permission-backed data stores such as contacts or calendars can create regulatory, reputational, and incident-response risk if access is unnecessary, excessive, or suspicious. Because the ATT&CK object provides no official detection text, teams should treat this as a validation prompt rather than a ready-made analytic.

Executive priority

Security leaders should use this object to ask whether the organization can prove which mobile apps request and use sensitive user-data permissions on Android and iOS, whether that access is business-justified, and whether SOC or mobile security teams can investigate questionable access. This matters for privacy evidence, mobile risk management, incident scoping, and control prioritization around application governance and permission review.

Technical view

SOC, detection engineering, and mobile security teams should validate visibility around permission-backed data access associated with Android application manifests and iOS Info.plist declarations, as described in the related technique. Since no official DET0681 detection logic is supplied, coverage should be built from local mobile telemetry, application inventory, permission declarations, user-consent state where available, and behavioral evidence of access to protected stores such as contacts or calendar data. Detection should focus on mismatches between declared business purpose, granted permissions, and observed access patterns.

Likely telemetry

  • Mobile application inventory and package metadata
  • Android manifest permission declarations
  • iOS Info.plist privacy permission declarations
  • Mobile device management or enterprise mobility management app and permission records
  • Mobile threat defense or endpoint telemetry showing protected data access where available

Detection direction

  • Confirm whether Android and iOS mobile fleets are in scope, because the detection strategy object has no platforms listed but the related technique identifies Android and iOS.
  • Baseline approved applications and expected protected-data permissions, then flag apps requesting access to sensitive stores without a clear business purpose.
  • Correlate permission declarations with observed access where telemetry exists; declaration alone may indicate risk but not prove data collection.
  • Tune for legitimate enterprise apps that require contacts, calendar, or similar access to avoid excessive false positives.
  • Look for gaps where unmanaged devices, personal devices, or limited mobile telemetry prevent confirmation of app permissions or protected data access.

Mitigation priorities

  • Maintain an approved mobile application inventory with documented business justification for protected-data permissions.
  • Review Android manifests and iOS Info.plist entries during app approval, procurement, and internal development reviews.
  • Use mobile management controls to restrict or remove unapproved applications where organizational policy allows.
  • Apply least-privilege expectations to mobile app permissions and periodically revalidate that granted permissions remain necessary.
  • Preserve permission and app inventory evidence for privacy, audit, and incident-response readiness.
Analyst notes and limits

The supplied ATT&CK object is a detection strategy with no official description, detection text, tactics, platforms, or labels. The only behavioral context comes from its relationship to T1636 Protected User Data, which describes adversary use of standard OS APIs to collect data from permission-backed stores and notes Android manifest and iOS Info.plist permission declarations.

This take cannot provide a MITRE-specified analytic, query, data source list, or detection threshold because those fields were not supplied. Local mobile management coverage, app telemetry, privacy requirements, and bring-your-own-device policy will determine practical visibility and response options.

Official MITRE ATT&CK definition

Detection of Protected User Data

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 Protected User Data This object detects Protected User Data.
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
5ef706a34e0a98aa...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 5ef706a34e0a…
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 DET0681
    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.