Mobile T1437 Application Layer Protocol: Detecting Command and Control Channels on Mobile Devices

Application Layer Protocol (T1437) is mobile malware talking to its operators over the same protocols every app uses, HTTP, HTTPS, WebSockets and push notification services, so that command and control blends into ordinary phone traffic. MITRE ATT&CK for Mobile v20 lists T1437 under Command and Control for Android and iOS, with one sub-technique, Web Protocols (T1437.001). Phones roam between networks and much of their traffic never crosses an enterprise proxy, which makes this harder to see than on a laptop. This guide is for mobile security engineers, MDM administrators and detection engineers. It covers what ATT&CK records, the telemetry you can actually collect on each platform, ATT&CK's v20 analytics and how to respond. For the general network side, read it with the MITRE ATT&CK T1071 Application Layer Protocol and Beaconing and C2 Detection Guide.

Key takeaways

• Blending in is the point. ATT&CK describes adversaries using application layer protocols to avoid detection and network filtering, with commands and results embedded in normal-looking traffic.
• Push services are part of the technique. T1437.001 names Firebase Cloud Messaging (two-way) and Apple Push Notification service (one-way, server to device) as channels abused on Android and iOS.
• ATT&CK lists no mitigations for T1437. Prevention comes from stopping the malware arriving; detection relies on app vetting and managed network telemetry.
• Visibility depends on enrolment. Android Enterprise network logging and Apple per-app VPN or content filters only see managed devices or managed apps, so coverage must be measured.
• Your own apps' push and API credentials matter too. The same channels carry your legitimate notifications, so protect the service credentials that send them.

What T1437 covers

ATT&CK's parent technique covers any application layer protocol used for command and control, giving web browsing, file transfer, email and DNS protocols as examples. The sub-technique T1437.001 Web Protocols covers HTTP and HTTPS, including the notification services native to the platforms. ATT&CK notes these services use HTTPS through their own APIs and are commonly abused on Android and iOS because their traffic is routine on every device and difficult for enterprises to inspect.

Related techniques have their own ATT&CK entries and are not covered here: Encrypted Channel (T1521), Web Service (T1481) for abuse of legitimate web services such as cloud storage, and Non-Standard Port (T1509). The Cloud Services Abuse for C2 Guide covers trusted-site abuse.

What the procedure examples show

ATT&CK v20 lists more than fifty entries for T1437 and T1437.001, nearly all Android families plus a smaller number of iOS implants.

The lesson is that protocol alone rarely separates malware from a legitimate app. Destination, timing pattern, the app that made the connection and whether that app should exist on the device are what give it away.

Detection: ATT&CK v20 analytics and the telemetry behind them

ATT&CK v20 attaches DET0685 Detection of Application Layer Protocol to T1437 and DET0620 Detection of Web Protocols to T1437.001, each with Android and iOS analytics.

• Android, network logging: both strategies use DevicePolicyManager.retrieveNetworkLogs() with its DnsEvent and ConnectEvent records, or VPN flow metadata. Android documents that network logging is available to a device owner from Android 8.0 and to the profile owner of a work profile from Android 12, where it covers only work profile activity. Each event carries the package name, so a connection can be tied to an app.
• Android, push registration: DET0620 looks for FirebaseMessaging.getToken() called for a Firebase project ID that is not on an allowlist, since registering with a rogue project enables C2 over Google infrastructure. This is an app vetting and dynamic analysis signal.
• iOS, push registration: DET0620 looks for remote notification registration where the sending Apple Team ID is not on an allowlist.
• iOS, network flows: Network Extension content filter flows, per-app VPN or secure web gateway metadata, combined with the MDM installed and managed application lists.
• Both, app state: DET0685 adds application permission and managed app inventory, so a connection from an app that is not in inventory, or that holds unexpected permissions, stands out.

Know the gaps. Android documents that network logging does not record UDP transfers, DNS queries made directly to a name server or through a Java DNS library, or apps that use direct system calls instead of standard network libraries, and recommends network-layer reporting such as a VPN gateway or firewall to complement it. Apple's content filter design keeps the filter data provider in a restrictive sandbox so user content cannot leave it, which limits what can be exported for analysis.

Prevention

ATT&CK lists no mitigations for T1437 or T1437.001. The following controls are NHI Mgmt Group practice: they reduce the chance that C2 starts and shorten its life.

• Stop the implant arriving: managed or official app stores only, no unknown sources on corporate devices, a minimum OS version and prompt updates.
• Route managed traffic through inspection: always-on or per-app VPN for managed apps, and a gateway that blocks newly registered and known malicious domains.
• Use MTD: mobile threat defence products add app risk and network threat signals that MDM alone does not see. See the Mobile Threat Defense Buyer's Guide.
• Harden your own apps: keep cleartext disabled, and use the Android network security configuration and iOS equivalents for certificate pinning where appropriate. See the OWASP Mobile Top 10 M5 Insecure Communication Guide.

Where identity fits

The push and API channels that malware abuses also carry your own apps' traffic, and they are protected by non-human credentials: push service credentials on your backend, API keys and OAuth client secrets in mobile backends. If those credentials leak, for example because they were embedded in an app package, someone else can send messages through your channel. Keep server credentials on the server, never in the app, scope them to the push or API function they serve and rotate them. See the Secrets in mobile apps guide.

How to implement

1. Measure coverage: count managed devices and apps that produce network telemetry (network logging, per-app VPN, gateway). This is the denominator for every other metric.
2. Baseline: collect two to four weeks of destinations per managed app before alerting, so normal SDK and analytics traffic is known.
3. Alert in audit mode: start with rare domain, beacon interval and unmanaged app signals, reviewed by an analyst, not automatic blocking.
4. Enforce gradually: add gateway blocking for high-confidence categories for a pilot ring, then widen. Roll back by moving the category to monitor only.
5. Feed vetting: add push registration and destination review to your app vetting process.

Decision guidance

• Network logging versus VPN: Android network logging is cheap and per app but misses UDP and direct DNS; a VPN or gateway sees more but changes the user's network path. Large fleets often use both.
• Fully managed versus work profile: device owner logging covers the whole device; work profile logging covers only work apps, which is correct for privacy but leaves personal apps unseen.
• Small organisations: app store restriction, a minimum OS rule and DNS filtering on managed traffic give most of the value without a detection team.

Responding to suspected mobile C2

• Contain: remove the device's access to corporate resources through conditional access, and block the destination at the gateway.
• Preserve: export network logs, MDM inventory and the app package before wiping. For iOS, capture a backup or sysdiagnose for analysis with the Mobile Verification Toolkit (MVT).
• Scope: search all network logs for the same destinations and package names.
• Rotate: revoke tokens and sessions held by apps on the device, including mobile access credentials. See the Mobile Spyware Infection Response Playbook.

Detection and measurement

• Telemetry coverage: percentage of managed devices sending network telemetry.
• Unmanaged app connections: connections from apps not in MDM inventory, trending to zero.
• Rare destination alerts: volume and true positive rate per month.
• Time to contain: time from alert to conditional access block.
• Vetting coverage: share of approved apps with destination and push registration review.

Framework mapping

Common failure patterns

• Assuming HTTPS means safe: nearly all modern mobile C2 in ATT&CK's list uses HTTPS or TLS.
• No telemetry off the corporate network: a phone on mobile data never touches the office proxy unless a VPN routes it.
• Logging enabled but not collected: Android deletes network log batches to make room for new ones, so a DPC that does not retrieve them promptly loses evidence.
• Wiping before preserving: destinations and package names are lost with the device.
• Push credentials shipped in the app: server-side keys embedded in a package can be extracted and reused.

Practitioner checklist

• Enable Android Enterprise network logging or managed VPN telemetry and measure coverage.
• Forward mobile network telemetry to the SIEM with the package name preserved.
• Baseline destinations per managed app before alerting.
• Alert on rare domains, beacon intervals and connections from unmanaged apps.
• Add push registration and destination review to app vetting.
• Keep push and API server credentials out of app packages and rotate them.
• Restrict corporate devices to managed or official app stores.
• Preserve logs and device evidence before any wipe.

Standards and references

• MITRE ATT&CK: Application Layer Protocol (T1437)
• MITRE ATT&CK: Web Protocols (T1437.001)
• Android Developers: Network activity logging
• Android Developers: Network security configuration
• Apple Developer: Content filter providers
• Kaspersky Securelist: Dissecting TriangleDB, a Triangulation spyware implant
• OWASP: Mobile Application Security Verification Standard
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Command and Control (C2) Guide · Mobile Malware Guide · Android Enterprise Security Guide