AN1793: Analytic 1793
A defender observes an application establishing application-layer network sessions (e.g., HTTP(S), WebSocket, DNS, SMTP/IMAP) with destinations and request patterns that deviate from the enterprise baseline for that app category, especially when sessions occur during background execution or while the device is locked and exhibit beacon-like periodicity, anomalous SNI/Host patterns, or suspicious request/response size symmetry consistent with command polling and tasking over legitimate-looking protocols.
Analyst context for executives and security teams
This analytic is about spotting Android apps whose network behavior no longer looks normal for their app category, especially background or locked-device traffic that resembles periodic command polling over common protocols such as HTTP(S), WebSocket, DNS, or email protocols. For leaders, the value is not the protocol itself; it is whether the organization can distinguish expected mobile app activity from covert, legitimate-looking communications that may evade simple allow/block controls.
Executive priority
Prioritize this as a mobile visibility and resilience question: do security teams have enough baseline, device-state, and network-session evidence to recognize abnormal Android application communications before they become an incident decision problem? It is relevant to managed detection, incident response readiness, mobile security governance, and compliance evidence where the organization must show monitoring of enterprise mobile devices or managed apps.
Technical view
For SOC and detection teams, validate whether Android network telemetry can be tied to the originating application and enriched with device state such as background execution or locked-screen activity. Detection engineering should focus on deviations from enterprise baselines for app categories, including unusual destinations, SNI/Host values, request timing, beacon-like periodicity, and suspicious request/response size symmetry. Because no official detection logic is provided and no relationships are supplied, teams should treat this as an analytic design requirement rather than a ready-to-run rule.
Likely telemetry
- Android application-to-network session metadata
- HTTP(S), WebSocket, DNS, SMTP, and IMAP connection or request metadata where available
- Destination domains, IPs, SNI, Host headers, and URL/request pattern metadata where policy permits
- Request and response sizes or byte counts
- Connection timing, recurrence, and periodicity data
Detection direction
- Build baselines by managed Android app or app category before alerting on deviations; generic anomaly alerts without baseline context are likely to be noisy.
- Correlate network sessions with application identity and device state, especially background or locked-device execution.
- Look for combinations of indicators rather than a single feature: unusual destinations plus periodic timing, anomalous SNI/Host patterns, or symmetric request/response sizes.
- Tune for legitimate background services, push notifications, synchronization, and enterprise apps that naturally communicate while devices are idle.
- Validate blind spots where encrypted traffic limits content inspection, where DNS/SNI visibility is reduced, or where telemetry cannot attribute sessions to a specific app.
Mitigation priorities
- Establish approved mobile app inventories and expected network behavior baselines for managed Android environments.
- Ensure mobile device management, mobile threat defense, network monitoring, or equivalent controls can associate traffic with Android applications and device state.
- Restrict or review unmanaged applications and unexpected background network activity according to enterprise mobile policy.
- Create incident response playbooks for suspicious mobile app communications, including device isolation, app review, evidence preservation, and user/business-owner coordination.
- Use findings to support compliance evidence for mobile monitoring and policy enforcement, while documenting telemetry gaps where full packet or app attribution is unavailable.
Analyst notes and limits
The ATT&CK object is a mobile detection analytic for Android, external ID AN1793, associated with DET0685. It describes anomalous application-layer network sessions that deviate from enterprise baselines and may resemble command polling over legitimate-looking protocols. No tactics, relationships, aliases, labels, or official detection logic were supplied.
This take is limited to the supplied official STIX fields and external reference. It does not establish active exploitation, threat actor attribution, impact, or guaranteed detection coverage. Local mobile management scope, privacy constraints, app inventory quality, and available network telemetry will determine whether this analytic is actionable.
Analytic 1793
A defender observes an application establishing application-layer network sessions (e.g., HTTP(S), WebSocket, DNS, SMTP/IMAP) with destinations and request patterns that deviate from the enterprise baseline for that app category, especially when sessions occur during background execution or while the device is locked and exhibit beacon-like periodicity, anomalous SNI/Host patterns, or suspicious request/response size symmetry consistent with command polling and tasking over legitimate-looking protocols.
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 | 935ab7370260… |
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 AN1793Open 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.