AN1710: Analytic 1710

Defender observes an app (package/UID) repeatedly querying device networking context APIs (Wi-Fi scan results/current SSID/BSSID, Bluetooth device discovery, or cellular tower lists) at a rate or timing inconsistent with the app’s normal UX, often while backgrounded. Correlate API calls with permission usage (fine location, nearby devices/Bluetooth) and concurrent connectivity probes (DNS lookups/ARP/port reachability) to distinguish automated discovery from user-initiated settings checks. The detection is based on observed API execution + permission use + rate/sequence, not the specific API method name.

MobileAN1710AnalyticObject v1.1 Modified May 12, 2026, 16:30 UTC (UTC+00:00)

This analytic matters because an Android app that repeatedly checks Wi-Fi, Bluetooth, or cellular network context outside normal user activity may be gathering environmental awareness rather than serving an expected feature. For leaders, the value is not the API name itself but whether mobile security, privacy, and incident response teams can tell normal app behavior from automated discovery that could expose location, nearby devices, or reachable network services.

Executive priority

Prioritize this as a mobile visibility and governance question: do approved Android apps have a business reason to use fine location, nearby-device/Bluetooth, and network-context permissions, and can the organization produce evidence when those permissions are used abnormally? This supports risk decisions around mobile device management, acceptable app use, privacy/compliance evidence, and incident triage for suspicious background activity on Android devices.

Technical view

Validate whether telemetry can associate an Android package or UID with repeated network-context API activity, permission use, foreground/background state, and related connectivity probes. The supplied analytic focuses on observed execution plus rate, timing, and sequence, not matching a specific API method name. SOC and detection teams should baseline expected app UX behavior, then look for repeated Wi-Fi scan/current SSID/BSSID checks, Bluetooth discovery, or cellular tower list access that occurs while backgrounded or at a cadence inconsistent with user-initiated settings or connectivity workflows.

Likely telemetry

Android package name and UID activity records
Observed use of Wi-Fi scan results, current SSID/BSSID, Bluetooth discovery, or cellular tower list access
Permission usage events for fine location and nearby devices/Bluetooth where available
App foreground/background state and timing context
DNS lookup, ARP, or port reachability probe evidence correlated to the same app/UID

Detection direction

Confirm that detections are behavior-based: package/UID, rate, timing, permission use, and sequence, rather than brittle matching on a single API method name.
Build baselines for apps that legitimately perform network or device discovery as part of visible user workflows, such as settings, connectivity, or device-pairing functions.
Tune for background execution and repeated polling because those conditions are central to distinguishing automated discovery from user-driven checks.
Correlate network-context access with concurrent DNS, ARP, or port reachability probes to strengthen triage confidence.
Document blind spots where Android telemetry cannot expose API execution, permission-use timing, or per-app network probes.

Mitigation priorities

Review Android app permission grants, especially fine location and nearby-device/Bluetooth permissions, against business need.
Limit or remove apps that do not require network-context discovery for approved functions.
Use mobile management or policy controls, where available, to govern risky permissions and background behavior.
Ensure incident response playbooks include collection of package/UID, permission, background-state, and connectivity-probe evidence for suspicious Android apps.
Maintain compliance evidence showing why sensitive mobile permissions are allowed and how abnormal use is monitored.

Analyst notes and limits

The ATT&CK object is a mobile detection analytic for Android and provides a useful behavioral description, but no separate official detection text and no relationship context were supplied. Local baselining is essential because legitimate apps may query network context during expected user workflows.

Tactics are not specified, no related techniques, software, or groups were supplied, and there is no claim of active exploitation or attribution. Coverage depends on whether the environment can collect Android app/UID-level API, permission, background-state, and connectivity telemetry.

Official MITRE ATT&CK definition

Analytic 1710

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

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.1
Created: Oct 21, 2025, 15:10 UTC (UTC+00:00)
Modified: May 12, 2026, 16:30 UTC (UTC+00:00)
Raw hash: 46537439dbe7746d...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.1	May 12, 2026, 16:30 UTC (UTC+00:00)	Current bundle	`46537439dbe7…`

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.

Open mirrored raw JSON Open MITRE-hosted copy

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]
mitre-attack AN1710
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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use