Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

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.

MobileT1437TechniqueObject v1.2 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

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.

Official MITRE ATT&CK definition

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.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
Mobile T1437.001 Web Protocols Sub-technique Web Protocols subtechnique of this object.
Associated objects

Groups, software, and campaigns

Malware Mobile

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]

Android
Malware Mobile

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]

Android
Malware Mobile

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]

Android
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.2
Created
Modified
Raw hash
a0f3376d36e56986...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.2 Current bundle a0f3376d36e5…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    NIST Mobile Threat Catalogue APP-29
    Open source URL
  2. [2]
    mitre-attack T1437
    Open source URL
Source and licensing

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.