AN1683: Analytic 1683
Defender correlates an app escalating file visibility (permissions/flags, legacy storage modes) with enumeration of other apps’ storage or exported ContentProviders, followed by bulk reads/copies from target paths (including shared/external storage) and optional archive/encode then share/upload. Sequence: storage capability/permission gain → target discovery (provider queries, directory listing) → high-volume cross-app data reads from writable/shared paths → archive/encode → exfil/share within a short window.
Analyst context for executives and security teams
This Android detection analytic is about spotting an app that first increases its ability to see files, then discovers other apps’ storage or exported ContentProviders, and then rapidly reads, copies, archives, encodes, or shares/uploads large amounts of cross-app data. For leaders, the decision value is whether mobile fleet monitoring can distinguish normal app storage behavior from a short-window data collection and exfiltration pattern that could affect sensitive business data on Android devices.
Executive priority
Prioritize this where Android devices handle regulated, confidential, or operationally sensitive data. The business question is not only whether mobile devices are managed, but whether teams can produce evidence that app permission changes, storage access behavior, provider queries, bulk file reads, and outbound sharing/upload activity are visible and reviewable. This supports incident response readiness, compliance evidence, mobile data-loss risk decisions, and control prioritization for app permissions and managed device policy.
Technical view
Validate whether Android telemetry can correlate the full sequence described by the analytic: storage capability or permission gain, target discovery through ContentProvider queries or directory listing, high-volume cross-app reads from writable or shared paths including shared/external storage, and optional archive/encode followed by share or upload within a short time window. Because the supplied object has no ATT&CK tactic and no official detection text beyond the analytic description, teams should treat this as a behavior-correlation use case rather than a single-event alert.
Likely telemetry
- Android app permission and storage access changes, including broad file visibility, storage flags, or legacy storage modes where available
- ContentProvider query activity, especially against exported providers
- Directory listing and file access events for shared, external, writable, or cross-app storage paths
- Volume and rate indicators for file reads and copies from target paths
- Archive or encoding activity associated with recently collected files
Detection direction
- Build correlation around the ordered sequence rather than alerting on permission changes alone; legitimate apps may request storage access or enumerate files for expected functions.
- Tune for short-window combinations of permission expansion, target discovery, high-volume reads, and follow-on archive/share/upload behavior.
- Baseline approved enterprise apps that legitimately access shared or external storage, backup files, or exported providers to reduce false positives.
- Check blind spots around unmanaged Android devices, limited mobile telemetry, scoped storage visibility gaps, and lack of ContentProvider or file-access logging.
- Use app inventory and permission history to distinguish newly installed or recently changed apps from known managed applications.
Mitigation priorities
- Restrict Android app installation and permission grants through managed device policy where appropriate.
- Minimize broad storage access and legacy storage modes for enterprise-approved apps when business function allows.
- Review exposure of exported ContentProviders and shared/external storage use in internally developed or managed apps.
- Ensure mobile telemetry sources retain enough detail to reconstruct permission changes, provider access, bulk file reads, and share/upload activity.
- Prepare incident response playbooks for mobile data exposure triage, including device isolation, app removal, evidence preservation, and scope assessment.
Analyst notes and limits
This is a mobile ATT&CK detection analytic for Android, external ID AN1683, under DET0621. The official description provides a useful behavioral sequence, but the official detection field is not provided and no relationship context is supplied. Treat it as guidance for validating telemetry and correlation logic rather than as a complete detection rule.
The source object does not specify tactics, related techniques, mitigations, data components, adversaries, or active exploitation. Effectiveness depends on local Android management posture, telemetry depth, app inventory quality, and whether file, provider, permission, and outbound sharing events are actually collected.
Analytic 1683
Defender correlates an app escalating file visibility (permissions/flags, legacy storage modes) with enumeration of other apps’ storage or exported ContentProviders, followed by bulk reads/copies from target paths (including shared/external storage) and optional archive/encode then share/upload. Sequence: storage capability/permission gain → target discovery (provider queries, directory listing) → high-volume cross-app data reads from writable/shared paths → archive/encode → exfil/share within a short window.
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.1 | Current bundle | 1dcb2d06e1b0… |
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 AN1683Open 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.