Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1421: System Network Connections Discovery

Adversaries may attempt to get a listing of network connections to or from the compromised device they are currently accessing or from remote systems by querying for information over the network.

This is typically accomplished by utilizing device APIs to collect information about nearby networks, such as Wi-Fi, Bluetooth, and cellular tower connections. On Android, this can be done by querying the respective APIs:

* `WifiInfo` for information about the current Wi-Fi connection, as well as nearby Wi-Fi networks. Querying the `WiFiInfo` API requires the application to hold the `ACCESS_FINE_LOCATION` permission.

* `BluetoothAdapter` for information about Bluetooth devices, which also requires the application to hold several permissions granted by the user at runtime.

* For Android versions prior to Q, applications can use the `TelephonyManager.getNeighboringCellInfo()` method. For Q and later, applications can use the `TelephonyManager.getAllCellInfo()` method. Both methods require the application hold the `ACCESS_FINE_LOCATION` permission.

MobileT1421TechniqueObject v2.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This Android mobile technique matters because a compromised or intrusive app can learn what networks and nearby devices surround a user: Wi‑Fi, Bluetooth, and cellular tower context. For executives, the risk is not just “network discovery”; it can expose sensitive location and operating context for executives, field staff, facilities, or regulated environments where mobile devices bridge physical and digital operations.

Executive priority

Prioritize this where Android devices are used by high-value personnel, operational teams, or users in sensitive locations. Leaders should ask whether mobile app permissions, sanctioned monitoring/employee-control apps, and unmanaged Android devices are governed well enough to prove that location-adjacent network discovery is limited, logged, and reviewable. This is also useful audit evidence for mobile privacy, access governance, and incident response readiness.

Technical view

ATT&CK lists Android as the platform and identifies API-based collection through WifiInfo, BluetoothAdapter, and TelephonyManager methods for neighboring or all cell information. The object has no ATT&CK tactic or official detection text, but a related detection strategy, DET0636, is provided. SOC and mobile security teams should validate whether they can see apps requesting ACCESS_FINE_LOCATION and Bluetooth runtime permissions, correlate those permissions with observed or declared use of Wi‑Fi, Bluetooth, and cellular APIs, and review suspicious permission use during mobile malware or surveillanceware investigations. Relationship context shows multiple Android surveillanceware or spyware families and one campaign using this behavior, so the technique is relevant to mobile threat hunting, but local telemetry is required to determine exposure.

Likely telemetry

  • Android application permission inventory, especially ACCESS_FINE_LOCATION and Bluetooth-related runtime grants
  • Mobile device management or enterprise mobility management records for installed apps, app versions, and granted permissions
  • Android security, privacy, or app-behavior logs showing Wi‑Fi, Bluetooth, or TelephonyManager API access where available
  • Application manifest and static-analysis findings for use of WifiInfo, BluetoothAdapter, TelephonyManager.getNeighboringCellInfo(), or TelephonyManager.getAllCellInfo()
  • User consent and runtime permission grant events for location and Bluetooth access

Detection direction

  • Map DET0636 or local mobile detection content to this technique and verify what evidence it actually requires, since the ATT&CK object does not provide official detection guidance.
  • Tune around context: navigation, connectivity, device-management, and legitimate Bluetooth/Wi‑Fi utilities may need these permissions, while unrelated apps requesting location or Bluetooth access deserve review.
  • Hunt for apps that combine ACCESS_FINE_LOCATION with Wi‑Fi, Bluetooth, or cellular information collection APIs, especially if the app has no business need for local network awareness.
  • Validate Android-version handling because ATT&CK notes different TelephonyManager methods before Android Q versus Android Q and later.
  • Include surveillanceware and employee-monitoring app review in mobile threat hunting, because related software entries include multiple surveillanceware/spyware examples using this technique.

Mitigation priorities

  • Establish a mobile app approval and permission-review process for Android devices, focused on location, Wi‑Fi, Bluetooth, and telephony access.
  • Use device-management controls where available to inventory installed apps and permission grants on corporate Android devices.
  • Apply least-privilege expectations to mobile apps: require a documented business reason for ACCESS_FINE_LOCATION and Bluetooth permissions.
  • During IR, collect app inventories, manifests, granted permissions, and relevant mobile security logs before wiping devices, so evidence of network discovery behavior is preserved.
  • Review sanctioned monitoring, parental-control, or employee-monitoring tools for privacy, legal, and security governance, since similar categories appear in the relationship context.
Analyst notes and limits

This take is based on ATT&CK T1421, System Network Connections Discovery, version 2.1 in ATT&CK release 19.1. The technique is scoped to Android in the supplied object. Relationship context includes DET0636 as a detecting strategy; revoked technique T1507 now maps to this object; campaign C0033; and several software entries including Pallas, Exodus, Monokle, FlexiSpy, ViperRAT, FakeSpy, LightSpy, and Pegasus for iOS. Because one related software entry is iOS while the technique platform is Android, use the relationship as context only and do not infer iOS coverage for this technique record.

ATT&CK provides no official detection text and no tactic for this object. The supplied fields do not prove active exploitation in any specific environment, current customer exposure, or guaranteed detection by any tool. Confirm applicability through local Android fleet scope, app inventory, permission telemetry, and mobile security logging.

Official MITRE ATT&CK definition

System Network Connections Discovery

Adversaries may attempt to get a listing of network connections to or from the compromised device they are currently accessing or from remote systems by querying for information over the network.

This is typically accomplished by utilizing device APIs to collect information about nearby networks, such as Wi-Fi, Bluetooth, and cellular tower connections. On Android, this can be done by querying the respective APIs:

* `WifiInfo` for information about the current Wi-Fi connection, as well as nearby Wi-Fi networks. Querying the `WiFiInfo` API requires the application to hold the `ACCESS_FINE_LOCATION` permission.

* `BluetoothAdapter` for information about Bluetooth devices, which also requires the application to hold several permissions granted by the user at runtime.

* For Android versions prior to Q, applications can use the `TelephonyManager.getNeighboringCellInfo()` method. For Q and later, applications can use the `TelephonyManager.getAllCellInfo()` method. Both methods require the application hold the `ACCESS_FINE_LOCATION` permission.

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.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Mobile T1507 Network Information Discovery Network Information Discovery revoked by this object.
Associated objects

Groups, software, and campaigns

Malware Mobile

S0407: Monokle

Monokle is targeted, sophisticated mobile surveillanceware. It is developed for Android, but there are some code artifacts that suggests an iOS version may be in development.[1]

Android
Tool Mobile

S0408: FlexiSpy

FlexiSpy is sophisticated surveillanceware for iOS and Android. Publicly-available, comprehensive analysis has only been found for the Android version.[1][2]

FlexiSpy markets itself as a parental control and employee monitoring application.[3]

Android
Malware Mobile

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]

AndroidWindowsiOS
Malware Mobile

S0509: FakeSpy

FakeSpy is Android spyware that has been operated by the Chinese threat actor behind the Roaming Mantis campaigns.[1]

Android
Malware Mobile

S0405: Exodus

Exodus is Android spyware deployed in two distinct stages named Exodus One (dropper) and Exodus Two (payload).[1]

Android
Malware Mobile

S0506: ViperRAT

ViperRAT is sophisticated surveillanceware that has been in operation since at least 2015 and was used to target the Israeli Defense Force.[1]

Android
Relationship explorer

All related ATT&CK context

uses · Campaign C0033: C0033 Mobile uses · Malware S0407: Monokle Mobile uses · Tool S0408: FlexiSpy Mobile uses · Malware S0289: Pegasus for iOS Mobile uses · Malware S0399: Pallas Mobile uses · Malware S1185: LightSpy Mobile detects · Detection Strategy DET0636: Detection of System Network Connections Discovery Mobile uses · Malware S0509: FakeSpy Mobile revoked by · Technique T1507: Network Information Discovery Mobile uses · Malware S0405: Exodus Mobile uses · Malware S0506: ViperRAT Mobile
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
2.1
Created
Modified
Raw hash
c17efd6f703b171a...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.1 Current bundle c17efd6f703b…
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. [1]
    mitre-attack T1421
    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