T1509: Non-Standard Port
Adversaries may generate network traffic using a protocol and port pairing that are typically not associated. For example, HTTPS over port 8088 or port 587 as opposed to the traditional port 443. Adversaries may make changes to the standard port used by a protocol to bypass filtering or muddle analysis/parsing of network data.
Analyst context for executives and security teams
Non-Standard Port matters because mobile malware can make its network traffic harder to filter or interpret by running a protocol on an unexpected port, such as HTTPS on something other than 443. For leaders, the issue is not the port number itself; it is whether mobile traffic monitoring, egress controls, and SOC parsing are based on protocol reality or on assumptions that “443 equals HTTPS” and “other ports are low priority.”
Executive priority
Prioritize this where mobile devices access sensitive business systems or where mobile spyware/banking trojan risk affects executives, regulated users, or high-value operations. Ask whether security teams can prove visibility into Android and iOS network traffic patterns, including protocol/port mismatches, and whether mobile egress policy is enforceable enough to support incident response, audit evidence, and risk decisions.
Technical view
ATT&CK lists this as a mobile technique for Android and iOS with no tactic specified and no official detection text. The core validation task is to identify protocol and port pairings that are atypical for the environment, then determine whether they are expected application behavior, misconfiguration, tunneling, or suspicious mobile malware communications. Relationship context shows use by multiple mobile malware or surveillanceware families, including Exodus, FlexiSpy, INSOMNIA, Cerberus, Mandrake, Red Alert 2.0, Chameleon, and LightSpy, so detection engineering should treat this as a mobile network-analysis problem rather than a simple blocked-port rule.
Likely telemetry
- Mobile device network connection metadata from Android and iOS management or security tooling where available
- Firewall, secure web gateway, proxy, VPN, or mobile threat defense logs showing destination IP/domain, port, protocol, and application context
- DNS and TLS metadata that can help compare claimed or inferred protocol behavior against port usage
- Network security monitoring records capable of protocol identification independent of port number
- Incident response packet captures or flow logs for scoped mobile investigations
Detection direction
- Validate DET0706 or equivalent logic against protocol/port mismatches rather than relying only on static port allow/block lists.
- Tune detections against known business applications that legitimately use alternate ports to reduce false positives.
- Look for repeated or rare mobile connections where application identity, protocol, destination, and port do not align with expected baselines.
- Confirm whether monitoring tools parse protocol independently of port; blind spots often appear when logs label traffic based only on destination port.
- Use relationship context to enrich triage for mobile spyware and banking-trojan investigations, while avoiding attribution based solely on a non-standard port observation.
Mitigation priorities
- Establish and review mobile egress policies for sensitive user groups and managed devices.
- Prefer controls that identify protocol and application behavior, not only destination port.
- Require mobile security, proxy, VPN, or network monitoring coverage for devices that access business-critical services.
- Document approved non-standard protocol/port use so SOC teams can distinguish expected exceptions from suspicious activity.
- During incidents, collect mobile network telemetry early because port/protocol anomalies may be one of the few observable indicators in sparse mobile environments.
Analyst notes and limits
This technique is especially useful as a coverage test: can the organization see and reason about mobile network behavior when adversaries intentionally break normal protocol-to-port expectations? It is not sufficient by itself to prove compromise, but it can materially improve triage when combined with device, application, DNS, TLS, and destination reputation context.
The supplied ATT&CK object provides no official detection text and no tactic mapping. The relationships identify software that uses the technique, but they do not prove current activity in any environment. Local baselines, approved application behavior, and available mobile/network telemetry are required before assigning severity or response actions.
Non-Standard Port
Adversaries may generate network traffic using a protocol and port pairing that are typically not associated. For example, HTTPS over port 8088 or port 587 as opposed to the traditional port 443. Adversaries may make changes to the standard port used by a protocol to bypass filtering or muddle analysis/parsing of network data.
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.
Groups, software, and campaigns
S0480: Cerberus
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]
S0485: Mandrake
Mandrake is a sophisticated Android espionage platform that has been active in the wild since at least 2016. Mandrake is very actively maintained, with sophisticated features and attacks that are executed with surgical precision.
Mandrake has gone undetected for several years by providing legitimate, ad-free applications with social media and real reviews to back the apps. The malware is only activated when the operators issue a specific command.[1]
S0463: INSOMNIA
S1185: LightSpy
First observed in 2018, LightSpy is a modular malware family that initially targeted iOS devices in Southern Asia before expanding to Android and macOS platforms. It consists of a downloader, a main executable that manages network communications, and functionality-specific modules, typically implemented as `.dylib` files (iOS, macOS) or `.apk` files (Android). LightSpy can collect VoIP call recordings, SMS messages, and credential stores, which are then exfiltrated to a command and control (C2) server.[1]
S0408: FlexiSpy
S0539: Red Alert 2.0
Red Alert 2.0 is a banking trojan that masquerades as a VPN client.[1]
S0405: Exodus
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 | 2.1 | Current bundle | 92e9126b699b… |
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 T1509Open 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.