AN1681: Analytic 1681
Defender observes an application establishing recurrent HTTPS or FCM-based communication sessions exhibiting structured cadence, asymmetric request/response sizes, or persistent low-volume polling inconsistent with declared application functionality, potentially embedding command data within web protocol traffic.
Analyst context for executives and security teams
This analytic matters because Android applications can use ordinary-looking HTTPS or Firebase Cloud Messaging-style traffic to maintain quiet, recurring communications that may not match the app’s stated purpose. For leaders, the practical issue is not the protocol itself, but whether mobile security teams can distinguish expected app behavior from persistent low-volume command-like communications without relying only on malware signatures.
Executive priority
Prioritize this as a mobile visibility and governance question: do you know which Android apps are allowed in the environment, what network behavior is normal for them, and whether SOC or mobile security teams can produce evidence when an app communicates on a suspicious cadence? This is relevant to incident triage, mobile device risk decisions, and compliance evidence around monitoring and approved application use.
Technical view
For Android environments, validate whether defenders can observe application-level network sessions showing recurrent HTTPS or FCM-based communication, structured timing, asymmetric request/response sizes, or persistent low-volume polling that is inconsistent with declared application functionality. Because no ATT&CK detection logic or relationships are supplied, teams should treat this as a behavioral validation target rather than a ready-to-run rule.
Likely telemetry
- Android application inventory and package identity
- Mobile device network connection metadata
- HTTPS session timing, frequency, and destination metadata
- Request and response size patterns where available
- FCM-related communication indicators where observable
Detection direction
- Baseline approved Android application behavior before alerting on cadence alone.
- Look for recurring low-volume sessions, unusual polling intervals, or asymmetric request/response sizes that do not align with the application’s declared function.
- Tune for false positives from legitimate push notification, telemetry, sync, and messaging behavior.
- Prioritize cases where traffic can be tied to a specific app and where the app’s purpose does not justify persistent background communication.
- Document visibility gaps where HTTPS encryption, mobile OS restrictions, or unmanaged devices prevent attribution of network behavior to an app.
Mitigation priorities
- Maintain an approved Android application inventory and remove or restrict apps that lack a business need.
- Use mobile device management or equivalent controls to enforce application governance where available.
- Ensure mobile network and device telemetry can support incident response questions about app identity, destination, timing, and volume.
- Review privacy and operational constraints before expanding mobile traffic monitoring.
- Create response playbooks for suspicious mobile app communications, including containment, app removal, and evidence preservation.
Analyst notes and limits
The supplied object is a detection analytic for the mobile ATT&CK domain and Android platform. It describes behavioral indicators involving recurrent HTTPS or FCM-based communication but provides no official detection logic, tactics, relationships, or procedure examples. Local baselining is essential because many legitimate Android apps use background polling, push messaging, and encrypted web protocols.
This take is limited to the supplied ATT&CK fields and external reference. It does not establish active exploitation, adversary attribution, business impact, or guaranteed detectability. No relationship context was provided, so technique mapping and broader campaign context should not be inferred.
Analytic 1681
Defender observes an application establishing recurrent HTTPS or FCM-based communication sessions exhibiting structured cadence, asymmetric request/response sizes, or persistent low-volume polling inconsistent with declared application functionality, potentially embedding command data within web protocol traffic.
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 | 5a0e1bf136b1… |
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 AN1681Open 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.