T1437: Application Layer Protocol
Adversaries may communicate using application layer protocols to avoid detection/network filtering by blending in with existing traffic. Commands to the mobile device, and often the results of those commands, will be embedded within the protocol traffic between the mobile device and server.
Adversaries may utilize many different protocols, including those used for web browsing, transferring files, electronic mail, or DNS.
Analyst context for executives and security teams
Application Layer Protocol (T1437) matters because mobile malware can hide command-and-control or data exchange inside ordinary-looking app traffic such as web, file transfer, email, or DNS protocols. For leaders, the risk is not the protocol itself; it is whether mobile security monitoring can distinguish expected business/mobile app communications from suspicious device-to-server behavior on Android and iOS.
Executive priority
Prioritize this as a mobile resilience and visibility question: do security teams have evidence of what mobile devices and managed apps are communicating with, and can they investigate suspicious protocol use when a device is suspected of compromise? This technique is especially relevant to mobile threat detection, incident response readiness, identity protection for users operating from mobile devices, and audit evidence showing that mobile network activity is monitored where feasible. The presence of related malware and campaign relationships, including Android software and an iOS-targeting campaign, makes this a practical coverage validation item rather than an abstract protocol concern.
Technical view
SOC and IR teams should validate monitoring for Android and iOS mobile network communications where policy, privacy, and architecture allow. ATT&CK provides no official detection text for this technique, but the related DET0685 detection strategy indicates that detection logic exists in ATT&CK context. Because T1437.001 covers web protocols, teams should pay particular attention to HTTP/HTTPS-like traffic and mobile notification or web service patterns without assuming all encrypted web traffic is malicious. Investigations should correlate network destinations, protocol use, app identity, device posture, installation source, user context, and any mobile malware indicators associated with related software such as DoubleAgent, Drinik, Chameleon, and DCHSpy.
Likely telemetry
- Mobile device network connection metadata, including destination domains, IPs, ports, protocol, timing, and volume
- Mobile threat defense or EMM/MDM security events for Android and iOS devices
- DNS query and response logs associated with mobile devices or mobile network segments
- Proxy, secure web gateway, VPN, or carrier/network logs where mobile traffic is routed through monitored infrastructure
- Application inventory and app identity data from managed mobile devices
Detection direction
- Validate whether DET0685 or equivalent local analytics are implemented for mobile application-layer protocol abuse rather than relying only on perimeter web filtering.
- Baseline normal mobile app communications by app, device group, geography, and business role to reduce false positives from legitimate cloud, notification, and web services.
- Tune detections for unusual destinations, newly observed domains, rare protocols, abnormal beaconing patterns, or traffic inconsistent with the claimed app function.
- Correlate network anomalies with mobile app installation events, risky permissions, device compliance changes, and user-reported suspicious behavior.
- Account for blind spots from encrypted HTTPS, unmanaged/BYOD devices, split-tunnel mobile VPNs, privacy restrictions, and traffic that never traverses enterprise monitoring points.
Mitigation priorities
- First, establish mobile asset and app visibility for Android and iOS devices that access business resources.
- Route managed mobile traffic through approved monitoring or inspection paths where lawful, appropriate, and technically feasible.
- Restrict access to enterprise resources based on device compliance, managed app status, and mobile security posture.
- Maintain allowlist or risk-based controls for approved mobile applications and investigate apps that communicate with unexpected services.
- Integrate mobile telemetry into SOC triage and incident response workflows so suspicious protocol use can be tied to a user, device, app, and business service.
Analyst notes and limits
This Glexia take is based on ATT&CK technique T1437 in the mobile domain, its Android and iOS platform scope, the official description, the NIST Mobile Threat Catalogue APP-29 reference, and the supplied relationships. The strongest relationship-driven context is the sub-technique for web protocols and the listed campaign/software that use this behavior. Because tactics are not specified in the supplied object, the analysis is framed around mobile command-and-control style communications described by ATT&CK rather than assigning a tactic.
MITRE provides no official detection guidance for this object in the supplied fields, and the related DET0685 details are not included beyond its existence. Local conclusions require environment-specific evidence about mobile device management, network routing, privacy constraints, app inventory, and available telemetry. This assessment does not claim active exploitation, local exposure, attribution, or guaranteed detection coverage.
Application Layer Protocol
Adversaries may communicate using application layer protocols to avoid detection/network filtering by blending in with existing traffic. Commands to the mobile device, and often the results of those commands, will be embedded within the protocol traffic between the mobile device and server.
Adversaries may utilize many different protocols, including those used for web browsing, transferring files, electronic mail, or DNS.
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.
Related techniques
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.001 | Web Protocols Sub-technique | Web Protocols subtechnique of this object. |
Groups, software, and campaigns
S1083: Chameleon
Chameleon is an Android banking trojan that can leverage Android’s Accessibility Services to perform malicious activities. Believed to have been first active in January 2023, Chameleon has been observed targeting users in Australia and Poland by masquerading as official applications. A new variant of Chameleon has expanded its targets to include Android users in the United Kingdom and Italy.[1][2]
S1243: DCHSpy
DCHSpy is an Android spyware likely used by MuddyWater. DCHSpy uses political decoys and masquerades as legitimate applications, such as VPNs and banking applications, to trick victims into downloading the malware. Once downloaded, DCHSpy collects information from the device and exfiltrates the data to the command and control (C2) server.[1]
S0550: DoubleAgent
DoubleAgent is a family of RAT malware dating back to 2013, known to target groups with contentious relationships with the Chinese government.[1]
S1054: Drinik
Drinik is an evolving Android banking trojan that was observed targeting customers of around 27 banks in India in August 2021. Initially seen as an SMS stealer in 2016, Drinik resurfaced as a banking trojan with more advanced capabilities included in subsequent versions between September 2021 and August 2022.[1]
C0054: Operation Triangulation
Operation Triangulation is a mobile campaign targeting iOS devices.[1] The unidentified actors used zero-click exploits in iMessage attachments to gain Initial Access, then executed exploits and validators, such as Binary Validator before finally executing the TriangleDB implant.
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.2 | Current bundle | a0f3376d36e5… |
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]
NIST Mobile Threat Catalogue APP-29Open source URL
-
[2]
mitre-attack T1437Open 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.