Mobile T1509 Non-Standard Port: Spotting Unusual Port Use by Android and iOS Malware

A phone app talking HTTPS to a raw IP address on port 43111 is not normal, yet on a cellular connection there is usually no firewall in the path to notice it. MITRE ATT&CK for Mobile tracks this behaviour as T1509 Non-Standard Port, a Command and Control technique for Android and iOS: adversaries pair a protocol with a port it is not normally associated with, such as HTTPS over 8088 or 587 instead of 443, to bypass filtering or confuse traffic analysis. ATT&CK v20 records cases on both platforms, including the INSOMNIA iOS implant and Android families such as Cerberus, Mandrake and Red Alert 2.0. This short guide covers what those cases looked like, why the signal is useful on phones, how to get the traffic in front of a control, and what to do with a hit. It is for mobile security engineers and SOC analysts. The MITRE ATT&CK T1571 Non-Standard Port guide covers the network analysis techniques in depth for enterprise systems and is not repeated here.

Key takeaways

• Mobile apps have a narrow normal. Most legitimate app traffic is HTTPS on 443 to named hosts, so an app connecting to a raw IP on a high port stands out more on a phone than on a server.
• Both platforms have recorded cases. INSOMNIA on iOS used HTTPS on TCP 43111, 43223 and 43773; Android families used ports such as 7777, 7878 and 8888.
• Visibility is the hard part. Off the corporate network the only way to see or block ports is a VPN, a content filter or a mobile threat defence agent on the device.
• Ports change, the pattern does not. Volexity notes INSOMNIA's addresses, ports and certificates changed over time, so alert on the mismatch rather than a fixed port list.
• Default-deny egress works on routed traffic. Through a VPN gateway, allowing only the ports managed apps need turns a quiet channel into a blocked, logged attempt.

What ATT&CK records

T1509 has no sub-techniques and ATT&CK v20 maps no mitigations to it. Its procedure examples cover Android and iOS:

The vendor reports add detail. Volexity found that INSOMNIA, an implant installed after a watering hole exploit chain against iOS 12.3 to 12.3.2 and fixed in iOS 12.4, used HTTPS with a certificate embedded in the implant, and that its hardcoded endpoints were raw IP addresses on those high ports. Sophos found every Red Alert 2.0 sample it tested contacted an IP address on 7878/tcp. ThreatFabric reported that LightSpy's Android core used a single host and port for both WebSocket and HTTPS traffic. The common features are raw IP destinations, high or unusual ports, and HTTP or TLS spoken on them, which is exactly the mismatch T1509 describes.

Related techniques: the protocol carried is usually T1437 Application Layer Protocol, and the TLS layer is T1521 Encrypted Channel.

Getting the traffic in front of a control

Android and iOS are listed alphabetically.

Once traffic reaches a gateway, apply the enterprise approach: an outbound allowlist of ports (typically 443 and the few others your managed apps need), protocol identification independent of port, and logging of denied attempts. See the Mobile Threat Defense Buyer's Guide for on-device options.

Detection

ATT&CK v20's detection strategy for T1509 correlates MDM or EMM app inventory, permission review, proxy or gateway DNS and HTTP(S) metadata, and dynamic analysis showing a background scheduler, foreground service or persistent service starting the connection. Practical analytics:

• Raw IP on a non-standard port: any app connection to an IP address without a preceding DNS lookup, on a port outside your allowlist. On phones this is rare enough to review every fleet-rare destination.
• TLS or HTTP on the wrong port: gateway protocol identification showing TLS or HTTP on ports other than 443 and 80, the pattern in INSOMNIA, Cerberus and Red Alert 2.0.
• Denied egress bursts: repeated blocked attempts from one device to one IP and port, which is what a channel looks like once default-deny is in place.
• Background start: the connection begins while the app is not in the foreground, from a service or scheduled job.
• App context: the app holds sensitive permissions (SMS, accessibility, device admin) or was installed outside the managed catalogue.

Measures: share of corporate devices whose traffic passes through a gateway with port policy; number of distinct non-allowlisted destination ports per week; share of non-standard port hits attributed to an app; and time from first hit to device containment.

Response and prevention

1. Attribute: find the app that opened the connection and its install source.
2. Contain: mark the device non-compliant so conditional access blocks it, and block the destination at the gateway.
3. Preserve: gateway logs, the app package and the MDM inventory record; for suspected spyware on iOS, follow the Mobile Spyware Infection Response Playbook before wiping.
4. Hunt: search all devices for the same IP and port pair, and for neighbouring ports on the same address, since LightSpy and INSOMNIA used several.
5. Fix the entry point: INSOMNIA depended on unpatched iOS 12 devices, so enforce minimum OS versions; Android families here were installed off-store, so enforce install restrictions.

Where identity fits

Families in this table, such as Cerberus and FlexiSpy, are built to steal credentials, messages and one-time codes. A confirmed T1509 hit on a work device should trigger session and token revocation for the user and a check for new MFA methods, not only removal of the app. See the Mobile Access Credentials guide.

Framework mapping

Common failure patterns

• Assuming the office firewall covers phones: on cellular or home Wi-Fi it does not.
• Blocking a list of known bad ports: the ports in this table change between samples and campaigns.
• Per-app VPN only, then expecting malware traffic: malicious apps are rarely the managed apps assigned to the VPN.
• Allowing all ports through the mobile VPN: routing without an egress policy logs the channel but never stops it.
• Old iOS versions left in the fleet: the INSOMNIA chain worked only on iOS versions already patched.

Practitioner checklist

• Route corporate Android traffic through always-on VPN with vpnConfigDisabled set.
• Use per-app VPN on iOS for managed apps and mobile threat defence for the rest.
• Apply a port allowlist and port-independent protocol identification at the mobile gateway.
• Alert on raw IP connections and on TLS or HTTP outside 443 and 80 from mobile devices.
• Enforce minimum OS versions and off-store install restrictions.
• Include IP and port pair hunting in the mobile incident runbook.
• Revoke sessions and tokens for users on a device with a confirmed hit.

Standards and references

• MITRE ATT&CK: Non-Standard Port (Mobile T1509)
• Google: Android Management API, enterprises.policies reference
• Apple: Device management schema, App-Layer VPN payload
• Volexity: Evil Eye threat actor resurfaces with iOS exploit and updated implant
• ThreatFabric: LightSpy mAPT mobile payment system attack
• Sophos: Red Alert 2.0 Android trojan

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · MITRE ATT&CK T1571 Non-Standard Port · Command and Control (C2) Guide · Mobile Device Security Guide