AN1827: Analytic 1827
The defender correlates app-attributed outbound sessions where protocol indicators such as TLS handshake, HTTP method and header patterns, DNS semantics, or other application-layer characteristics are observed over a destination port outside the approved baseline for that protocol and app role. The strongest Android evidence is repeated or persistent app-attributed traffic using HTTPS-, HTTP-, DNS-, WebSocket-, or other recognizable application behavior over uncommon destination ports, especially when the app is backgrounded, while the device is locked, without recent user interaction, or when the app is unmanaged or not approved for that protocol-to-port pairing.
Analyst context for executives and security teams
AN1827 is an Android-focused detection analytic for finding apps that send recognizable application traffic, such as HTTPS, HTTP, DNS, or WebSocket behavior, over destination ports that are not approved or expected for that app’s role. Its business value is in exposing mobile apps or managed devices that may be bypassing normal network expectations, operating in the background, or communicating in ways that policy, monitoring, or review processes did not anticipate.
Executive priority
Security leaders should treat this as a mobile monitoring and governance validation point: do Android controls and network telemetry show which app generated outbound traffic, whether the protocol matches the destination port, and whether the app is approved to use that protocol? This can support incident triage, mobile device policy enforcement, compliance evidence for managed-device oversight, and prioritization of gaps in mobile network visibility.
Technical view
For SOC and detection teams, validate whether Android telemetry can correlate outbound sessions to the responsible app and inspect enough application-layer indicators to identify protocol behavior on non-baseline ports. The analytic is strongest when repeated or persistent app-attributed traffic is observed while the app is backgrounded, the device is locked, there has been no recent user interaction, or the app is unmanaged or not approved for the observed protocol-to-port pairing. Because no ATT&CK tactic, related technique, or formal detection logic is supplied, implementation should be based on local baselines for approved Android apps, ports, and expected protocol use.
Likely telemetry
- Android app-attributed outbound network session records
- Destination IP, destination port, protocol, and session timing metadata
- TLS handshake indicators where available
- HTTP methods and header patterns where available
- DNS semantics or DNS-like behavior where available
Detection direction
- Build or validate baselines of approved protocol-to-port pairings by Android app and app role.
- Prioritize repeated or persistent outbound sessions where recognizable HTTP, HTTPS, DNS, WebSocket, or similar behavior appears on uncommon destination ports.
- Increase confidence when traffic occurs while the app is backgrounded, the device is locked, or no recent user interaction is present.
- Tune for legitimate exceptions such as enterprise apps, proxies, development tools, or sanctioned services that intentionally use nonstandard ports.
- Check for blind spots where mobile telemetry lacks app attribution, encrypted-session metadata, device state, or user-interaction context.
Mitigation priorities
- Define approved Android app inventories and expected network behaviors, including protocol-to-port expectations where feasible.
- Ensure mobile device management or equivalent controls can distinguish managed, unmanaged, approved, and unapproved apps.
- Improve collection of app-attributed mobile network telemetry before relying on this analytic for SOC decisions.
- Use policy enforcement to restrict or review apps that do not have a business need for unusual outbound protocol-to-port behavior.
- Document known exceptions so detection tuning and audit evidence remain defensible.
Analyst notes and limits
This object is a detection analytic, not a technique or campaign. The supplied ATT&CK content provides a strong behavioral description but no formal detection logic, tactic mapping, mitigations, or relationship context. Local baselines are essential because uncommon destination ports and approved app roles are environment-specific.
Official detection content is not provided, and no relationships are supplied. The object only supports Android as the platform. This take does not infer adversary attribution, active exploitation, business impact, or guaranteed detection coverage.
Analytic 1827
The defender correlates app-attributed outbound sessions where protocol indicators such as TLS handshake, HTTP method and header patterns, DNS semantics, or other application-layer characteristics are observed over a destination port outside the approved baseline for that protocol and app role. The strongest Android evidence is repeated or persistent app-attributed traffic using HTTPS-, HTTP-, DNS-, WebSocket-, or other recognizable application behavior over uncommon destination ports, especially when the app is backgrounded, while the device is locked, without recent user interaction, or when the app is unmanaged or not approved for that protocol-to-port pairing.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.1 | Current bundle | a1b2882c8b7d… |
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 AN1827Open 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.