DET0688: Detection of Out of Band Data
DET0688 is a mobile ATT&CK detection strategy for identifying use of out-of-band data channels associated with T1644, Out of Band Data. The business signif...
Analyst context for executives and security teams
DET0688 is a mobile ATT&CK detection strategy for identifying use of out-of-band data channels associated with T1644, Out of Band Data. The business significance is that compromised mobile devices may communicate or move data through channels that are not covered by normal Wi-Fi or cellular Internet monitoring, such as SMS, NFC, Bluetooth, or push-notification-related access on Android. For leaders, this matters because mobile security coverage can look complete while missing alternate command-and-control or exfiltration paths.
Executive priority
Treat this as a mobile visibility and control-gap question rather than a single alert rule. Security leaders should ask whether enterprise mobile programs can provide evidence for non-standard communication paths on Android and iOS devices, especially where mobile devices support privileged users, regulated data, field operations, or operational environments. The priority is validating whether managed detection, mobile device management, incident response playbooks, and compliance evidence account for out-of-band communication channels, not just conventional network telemetry.
Technical view
The supplied ATT&CK object has no official detection text, platforms, or tactics of its own, but it detects mobile technique T1644, which is associated with Android and iOS. SOC and detection teams should validate what evidence is available for SMS, NFC, Bluetooth, push notification access where applicable, and device/application behaviors that may indicate communication outside normal Internet-providing networks. IR teams should ensure mobile triage procedures do not rely only on proxy, DNS, firewall, or EDR-style network logs, because the related technique explicitly involves out-of-band streams that may evade conventional network traffic monitoring.
Likely telemetry
- Mobile device management or enterprise mobility management inventory and policy state
- Mobile security or mobile threat defense alerts, where deployed
- Device permission and application inventory data, especially permissions related to SMS, Bluetooth, NFC, notifications, and background activity
- SMS or messaging metadata available through approved enterprise controls and lawful processes
- Bluetooth and NFC configuration or usage evidence where available
Detection direction
- Map existing mobile telemetry to the out-of-band channels named in the related ATT&CK technique: SMS, NFC, Bluetooth, and Android push-notification access.
- Validate blind spots explicitly: many SOC pipelines collect Wi-Fi, VPN, proxy, DNS, or cellular Internet indicators but may not collect usable evidence for SMS, NFC, Bluetooth, or notification access.
- Tune detections around unusual mobile application permissions, unexpected enablement or use of local radios, and mobile security alerts, while accounting for legitimate business apps that use Bluetooth, NFC, SMS, or notifications.
- Use relationship-driven context: this detection strategy is only linked to T1644, so coverage claims should be scoped to mobile out-of-band data behavior and not generalized to all mobile command-and-control or exfiltration.
- During incidents, correlate mobile device state, application permissions, and available local communication-channel evidence with timelines, rather than assuming lack of network traffic means lack of activity.
Mitigation priorities
- Establish mobile asset and application governance first: know which Android and iOS devices and apps are authorized in enterprise contexts.
- Review and restrict mobile permissions and capabilities related to SMS, Bluetooth, NFC, notifications, and background access where business requirements allow.
- Ensure MDM/EMM and mobile security tooling policies produce auditable evidence for relevant mobile communication controls and exceptions.
- Update mobile incident response playbooks to include collection and review of out-of-band communication evidence, not only network logs.
- Use risk-based prioritization for devices used by executives, administrators, regulated-data users, field staff, or cyber-physical operations where alternate mobile channels could materially affect response decisions.
Analyst notes and limits
The ATT&CK detection-strategy object itself is sparse: it provides no official description, detection logic, platforms, or tactics. The useful context comes from its relationship to T1644, Out of Band Data, in the mobile domain, with related platforms Android and iOS and examples including SMS, NFC, Bluetooth, and Android push-notification access. Any production detection plan must be validated against the organization’s actual mobile management, privacy, legal, and telemetry constraints.
This take is based only on the supplied STIX fields, external reference, and the stated relationship to T1644. It does not assert active exploitation, adversary attribution, specific tool behavior, or guaranteed detection coverage. Local device ownership models, MDM/EMM capabilities, mobile security tooling, logging permissions, and legal constraints will determine what can actually be monitored or investigated.
Detection of Out of Band Data
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1644 | Out of Band Data | This object detects Out of Band Data. |
All related ATT&CK context
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.0 | Current bundle | 2af4abdd55fe… |
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 DET0688Open 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.