AN1770: Analytic 1770
The defender correlates outbound communication from an application or service to legitimate external web platforms with mobile runtime context showing that the communication is inconsistent with the app's approved role, expected destinations, user interaction pattern, or device state. The strongest Android evidence is a managed or installed app communicating with cloud storage, social, messaging, code-hosting, or generic HTTPS web-service infrastructure shortly after background activation, protected-resource use, or local staging activity, especially when the device is locked, user interaction is absent, or the app's historical network baseline does not include that service class.
Analyst context for executives and security teams
AN1770 is a mobile detection analytic for spotting Android apps that communicate with legitimate external web platforms in ways that do not fit the app’s approved role or the device context. Its business value is in reducing blind spots where suspicious activity blends into normal-looking HTTPS traffic to cloud storage, social, messaging, code-hosting, or other web-service infrastructure.
Executive priority
Prioritize this as a mobile security and SOC readiness question: can the organization explain which Android apps are allowed to contact which external service classes, and can it prove that background app activity, locked-device state, protected-resource use, and unusual destinations are visible to defenders? This matters for incident triage, compliance evidence, and mobile risk governance because the analytic depends on context, not just domain blocking.
Technical view
For Android, validate whether managed or installed app network activity can be correlated with mobile runtime context: app identity, expected destination classes, user interaction, device lock state, background activation, protected-resource use, local staging indicators, and historical network baselines. Because no official detection logic or ATT&CK relationships are supplied, teams should treat this as a detection design pattern rather than a ready-to-run rule.
Likely telemetry
- Android app network connection or DNS/HTTPS destination metadata
- Managed or installed app inventory and app identity
- Mobile device state such as locked/unlocked and foreground/background activity
- User interaction or absence-of-interaction context
- Protected-resource access events where available
Detection direction
- Correlate outbound app communication to legitimate web platforms with app role and approved destination expectations.
- Tune around service class, timing, and device context rather than treating all cloud, social, messaging, code-hosting, or HTTPS traffic as suspicious.
- Look for communication shortly after background activation, protected-resource use, or local staging activity, especially when the device is locked or user interaction is absent.
- Establish per-app baselines so rare-but-legitimate app integrations do not create excessive false positives.
- Document blind spots where mobile telemetry cannot show app-level attribution, device state, user interaction, or destination classification.
Mitigation priorities
- Define approved mobile app roles and expected external destination classes for managed Android environments.
- Improve mobile telemetry collection before relying on this analytic for SOC coverage claims.
- Use mobile device management or equivalent governance to maintain app inventory and policy context.
- Review apps with unnecessary external service access or unclear business justification.
- Feed confirmed anomalies into incident response playbooks for mobile device containment and evidence preservation.
Analyst notes and limits
This object is a detection analytic, not a technique, and the supplied ATT&CK fields provide no tactic, relationship context, or formal detection pseudocode. Its value is in guiding correlation between Android network behavior and runtime context for legitimate-looking external web services.
The official detection field is not provided, and no relationships are supplied. Local environment data is required to determine approved app roles, expected destinations, baseline behavior, available Android telemetry, and practical alert thresholds.
Analytic 1770
The defender correlates outbound communication from an application or service to legitimate external web platforms with mobile runtime context showing that the communication is inconsistent with the app's approved role, expected destinations, user interaction pattern, or device state. The strongest Android evidence is a managed or installed app communicating with cloud storage, social, messaging, code-hosting, or generic HTTPS web-service infrastructure shortly after background activation, protected-resource use, or local staging activity, especially when the device is locked, user interaction is absent, or the app's historical network baseline does not include that service class.
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 | 29bcea4f3ed3… |
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 AN1770Open 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.