AN1816: Analytic 1816
The defender correlates repeated inbound retrieval and outbound submission activity by the same Android app identity to the same legitimate public web-service class within a short operational window, where the two-way exchange is inconsistent with the app's approved role, interaction model, or background behavior baseline. The strongest Android evidence is app-attributed communication to collaboration, social, cloud storage, code-hosting, messaging, or generic HTTPS platforms where requests that retrieve content are followed by app-attributed posts, uploads, document updates, API writes, or repeated small bidirectional exchanges, especially when they occur while the app is backgrounded, while the device is locked, without recent user interaction, or shortly after local staging or protected-resource access.
Analyst context for executives and security teams
This analytic matters because it focuses on Android apps that appear to use legitimate public web services as a two-way channel: retrieving content and then submitting data back within a short window. For leaders, the risk is not the public service itself, but whether an app is communicating in ways that do not match its approved business purpose, user interaction pattern, or background behavior. That can affect mobile data protection, incident triage, and confidence in managed-device governance.
Executive priority
Prioritize this where Android devices handle sensitive business data, regulated information, collaboration content, cloud storage access, or operational workflows. Security leaders should ask whether mobile telemetry can attribute network activity to a specific app identity, whether approved app behavior is documented well enough to judge anomalies, and whether SOC or mobile security teams can distinguish legitimate sync behavior from suspicious background bidirectional exchange. This is especially relevant for audit evidence around mobile device governance and for incident response decisions involving potentially unauthorized app behavior.
Technical view
For Android, validate the ability to correlate app-attributed inbound retrievals and outbound submissions to the same class of legitimate public web service in a short operational window. The analytic is strongest when network activity can be tied to collaboration, social, cloud storage, code-hosting, messaging, or generic HTTPS services, and when the activity occurs while the app is backgrounded, the device is locked, without recent user interaction, or shortly after local staging or protected-resource access. Because ATT&CK provides no explicit detection logic and no relationships for this object, teams should treat this as a detection design pattern requiring local baselines for approved app roles, normal interaction models, and background behavior.
Likely telemetry
- Android app identity associated with network connections or HTTP(S) requests
- Inbound content retrieval events and outbound post, upload, document update, API write, or small bidirectional exchange indicators
- Destination service classification for collaboration, social, cloud storage, code-hosting, messaging, or generic HTTPS platforms
- Device state such as locked or unlocked status
- App foreground/background state
Detection direction
- Confirm whether network telemetry preserves Android app attribution; device-level or IP-only logs may not be sufficient.
- Build baselines for approved app role, expected destinations, background behavior, and normal sync frequency before treating bidirectional exchange as suspicious.
- Correlate retrieval followed by submission to the same public service class within a short window rather than alerting on single connections.
- Increase priority when activity occurs while the app is backgrounded, the device is locked, or there is no recent user interaction.
- Tune for benign collaboration, messaging, cloud backup, and document sync behavior, which can naturally produce repeated bidirectional exchanges.
Mitigation priorities
- Inventory and approve Android apps by business role, expected data access, and expected network services.
- Enforce mobile device management controls for approved apps, permissions, and access to protected resources where available.
- Require logging sources that can connect Android app identity, network activity, app state, and user interaction context.
- Define response playbooks for suspicious mobile app communications, including device containment, app removal or suspension, data access review, and preservation of mobile logs.
- Review cloud and collaboration service access controls so unauthorized uploads, document updates, or API writes can be investigated from both device and service-side evidence.
Analyst notes and limits
This is a mobile detection analytic for Android, not a specific adversary behavior claim. Its value depends heavily on local context: which Android apps are approved, what services they are expected to use, and whether telemetry can show app identity and device state. The absence of supplied tactics and relationships means analysts should map it to local detection strategy without over-interpreting ATT&CK coverage.
Official detection content was not provided, and no relationship context was supplied. The object identifies Android as the supported platform, but does not provide executable logic, thresholds, data component mappings, tactics, or associated techniques. Local telemetry quality and app behavior baselines are required before this can be operationalized with confidence.
Analytic 1816
The defender correlates repeated inbound retrieval and outbound submission activity by the same Android app identity to the same legitimate public web-service class within a short operational window, where the two-way exchange is inconsistent with the app's approved role, interaction model, or background behavior baseline. The strongest Android evidence is app-attributed communication to collaboration, social, cloud storage, code-hosting, messaging, or generic HTTPS platforms where requests that retrieve content are followed by app-attributed posts, uploads, document updates, API writes, or repeated small bidirectional exchanges, especially when they occur while the app is backgrounded, while the device is locked, without recent user interaction, or shortly after local staging or protected-resource access.
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 | 127b239c3e65… |
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 AN1816Open 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.