AN1663: Analytic 1663
The defender correlates repeated or periodic app-attributed retrieval from a legitimate public web-service platform with runtime conditions showing that the retrieval is not aligned to normal foreground consumption, user interaction, or approved app role. The strongest Android evidence is a managed or installed app repeatedly issuing inbound-oriented GET, fetch, sync, or content-pull operations to social, collaboration, paste, code-hosting, cloud-storage, messaging, or generic HTTPS platforms while the app is backgrounded, while the device is locked, or without recent user interaction, and without a corresponding outbound writeback to that same service class during the operational window. The detection is strengthened when the retrieval is temporally adjacent to scheduled/background execution, local state changes, or later downstream effects that do not require the same public platform to receive output.
Analyst context for executives and security teams
This analytic matters because it focuses on Android apps that repeatedly pull content from legitimate public web services in ways that do not match normal user-driven app activity. For leaders, the practical issue is not the public service itself, but whether mobile devices can distinguish approved background sync from suspicious command-like or automation-driven retrieval while the app is backgrounded, the device is locked, or there has been no recent user interaction.
Executive priority
Prioritize this as a mobile monitoring and governance question: do managed Android devices provide enough app-attributed network, foreground/background, lock-state, and user-interaction evidence to explain why an app is repeatedly retrieving from public platforms? This can affect SOC readiness, incident scoping, mobile policy enforcement, and compliance evidence for managed-device oversight. It is especially useful for validating whether mobile security investments can separate legitimate collaboration/cloud sync from unexplained background retrieval patterns.
Technical view
For Android, validate whether telemetry can correlate app-attributed GET, fetch, sync, or content-pull activity to social, collaboration, paste, code-hosting, cloud-storage, messaging, or generic HTTPS platforms with runtime context such as app foreground state, device lock state, recent user interaction, approved app role, scheduled/background execution, local state changes, and downstream effects. The analytic is strongest when repeated inbound-oriented retrieval occurs without corresponding outbound writeback to the same service class during the operational window. No ATT&CK tactic or relationship context was supplied, so implementation should remain behavior-focused rather than mapped to a specific intrusion phase.
Likely telemetry
- Android app-attributed network connection or HTTP/S request metadata
- Destination service classification for public web-service platforms
- App foreground/background state
- Device locked or unlocked state
- Recent user interaction indicators
Detection direction
- Baseline approved background sync behavior for managed and installed Android apps before alerting on periodic retrieval.
- Correlate network retrieval with runtime context; network logs alone may over-alert on legitimate cloud, messaging, or collaboration apps.
- Tune for repeated or periodic inbound-oriented retrieval while backgrounded, locked, or lacking recent user interaction.
- Increase confidence when retrieval is adjacent to scheduled/background execution, local state changes, or later downstream effects that do not require output to the same public platform.
- Review false positives from legitimate backup, messaging, collaboration, code-hosting, storage, and content-refresh applications.
Mitigation priorities
- Confirm mobile device management or endpoint controls can inventory approved Android apps and their expected roles.
- Ensure SOC logging retains app-attributed network and runtime-state evidence needed for correlation.
- Define policy expectations for which apps may perform background sync or content retrieval from public services.
- Use mobile security reviews to reduce unapproved apps or unnecessary background activity where organizational policy allows.
- Prepare incident response playbooks to triage suspicious mobile background retrieval using app inventory, user context, and network history rather than destination reputation alone.
Analyst notes and limits
The supplied object is a detection analytic for Android in the mobile ATT&CK domain. Its value is in correlating legitimate public-service retrieval with app runtime conditions and expected role. Because no relationship context, tactic mapping, or official detection logic was supplied, the take avoids attribution and technique-stage assumptions.
Official detection content was not provided, and no related ATT&CK objects were supplied. Local device-management, mobile telemetry, app inventory, and service-classification quality will determine whether this can be implemented reliably. The analytic does not by itself prove malicious activity.
Analytic 1663
The defender correlates repeated or periodic app-attributed retrieval from a legitimate public web-service platform with runtime conditions showing that the retrieval is not aligned to normal foreground consumption, user interaction, or approved app role. The strongest Android evidence is a managed or installed app repeatedly issuing inbound-oriented GET, fetch, sync, or content-pull operations to social, collaboration, paste, code-hosting, cloud-storage, messaging, or generic HTTPS platforms while the app is backgrounded, while the device is locked, or without recent user interaction, and without a corresponding outbound writeback to that same service class during the operational window. The detection is strengthened when the retrieval is temporally adjacent to scheduled/background execution, local state changes, or later downstream effects that do not require the same public platform to receive output.
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 | 35f48ca33c95… |
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 AN1663Open 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.