DET0685: Detection of Application Layer Protocol
DET0685 is a mobile ATT&CK detection strategy for identifying use of application layer protocols associated with technique T1437. The business issue is tha...
Analyst context for executives and security teams
DET0685 is a mobile ATT&CK detection strategy for identifying use of application layer protocols associated with technique T1437. The business issue is that mobile command-and-control or data exchange can be hidden inside normal-looking web, file transfer, email, or DNS-style traffic, making simple network allow/block decisions insufficient. For leaders, the key question is whether mobile security, network monitoring, and incident response processes can distinguish expected app communications from unusual protocol use without relying on unsupported assumptions.
Executive priority
Prioritize this as a mobile visibility and resilience question rather than a single alert rule. Organizations with managed mobile devices, mobile access to sensitive business systems, or regulated data should be able to show what mobile network telemetry is collected, who reviews suspicious protocol behavior, and how investigations link device, user, app, and network evidence. This supports incident decision-making, compliance evidence, and control prioritization around mobile device management, network monitoring, and identity-aware access.
Technical view
The supplied ATT&CK object has no official detection text, platforms, or tactics of its own, but it detects mobile technique T1437, Application Layer Protocol, which applies to Android and iOS. SOC and detection teams should validate whether they can observe mobile device communications that use common application layer protocols, including web, file transfer, email, and DNS-related traffic, and correlate that activity with device identity, user identity, installed apps, destination infrastructure, and timing. Detection should focus on anomalous or policy-inconsistent protocol use rather than protocol presence alone, because these protocols are common in legitimate mobile activity.
Likely telemetry
- Mobile device management or enterprise mobility inventory showing device, OS, user, and app context
- Mobile threat defense or endpoint security events where deployed
- DNS query and resolver logs associated with mobile devices or mobile network egress
- Web proxy, secure web gateway, firewall, VPN, or network flow logs for mobile device traffic
- Email or file-transfer gateway logs where mobile access is in scope
Detection direction
- Confirm whether Android and iOS traffic can be attributed to a specific device, user, and app; without this, application layer protocol detections may be too ambiguous for reliable triage.
- Baseline normal mobile protocol use by managed apps, operating system services, and business workflows before treating protocol use as suspicious.
- Tune for unusual destinations, rare protocols for a device population, unexpected DNS patterns, protocol use outside approved mobile paths, or traffic that conflicts with device posture or app inventory.
- Correlate network observations with mobile management state, recent app installation or configuration changes, and identity events to reduce false positives.
- Document blind spots such as unmanaged/BYOD devices, encrypted traffic, privacy restrictions, split tunneling, carrier network paths, and mobile apps that bypass enterprise proxies.
Mitigation priorities
- Establish mobile asset and ownership visibility first, including which Android and iOS devices are managed and allowed to access business services.
- Route in-scope mobile traffic through monitored enterprise controls where business and privacy requirements permit.
- Use mobile device management and access policy to limit risky configurations, unauthorized apps, and unmanaged access to sensitive services.
- Maintain DNS, proxy, VPN, firewall, identity, and mobile security logs at retention levels that support incident response and audit needs.
- Create response playbooks for suspicious mobile protocol activity, including device containment, user verification, app review, and evidence preservation.
Analyst notes and limits
This take is based on a sparse detection-strategy object. MITRE provides the object name and relationship showing it detects T1437, Application Layer Protocol, in the mobile ATT&CK domain. The related technique description supports focusing on adversary communications embedded in common application layer protocols to blend with normal traffic. Local architecture determines which telemetry sources are available and legally appropriate.
The official detection strategy contains no description, detection guidance, platforms, or tactics. The only platform specificity comes from the related T1437 technique, which lists Android and iOS. This summary does not assert active exploitation, attribution, impact, or guaranteed detection coverage.
Detection of Application Layer Protocol
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 | T1437 | Application Layer Protocol | This object detects Application Layer Protocol. |
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 | b5b7bc5f5eb6… |
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 DET0685Open 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.