DET0636: Detection of System Network Connections Discovery
This detection strategy is intended to help identify mobile behavior where an actor tries to learn what networks a compromised device can see or is connect...
Analyst context for executives and security teams
This detection strategy is intended to help identify mobile behavior where an actor tries to learn what networks a compromised device can see or is connected to. Even though the ATT&CK detection object itself has no official detection guidance, its linked technique, System Network Connections Discovery, matters because mobile network context can help an intruder understand location, nearby infrastructure, connectivity options, and potential follow-on paths.
Executive priority
Treat this as a mobile security visibility and governance question: can the organization prove it has enough telemetry and policy control to notice suspicious access to Wi-Fi, Bluetooth, or cellular connection information on managed Android devices? The business value is strongest for environments where mobile devices support executives, field operations, regulated workflows, or cyber-physical operations, because network discovery from a device may expose operational context even before overt disruption occurs.
Technical view
DET0636 detects T1421, System Network Connections Discovery, in the mobile ATT&CK domain. The related technique description specifically references Android and collection of nearby or current network information through device APIs such as Wi-Fi, Bluetooth, cellular tower, and `WifiInfo`-related data. SOC and mobile security teams should validate whether their mobile telemetry can show application-level access to network connection data, permission use, relevant API access where available, and device context around Wi-Fi, Bluetooth, and cellular state changes. Because the official detection field is not provided, local engineering is required to define analytic logic and thresholds.
Likely telemetry
- Mobile device management or enterprise mobility management inventory and compliance data
- Android security telemetry where available from managed devices
- Application permission requests and permission grant history for network, location-adjacent, Wi-Fi, Bluetooth, or cellular-related capabilities
- Mobile application behavior logs or mobile threat defense alerts, if deployed
- Device network state information such as Wi-Fi association, Bluetooth visibility or connection state, and cellular connection context
Detection direction
- Confirm whether Android devices in scope generate telemetry for applications querying or accessing Wi-Fi, Bluetooth, or cellular connection information.
- Prioritize detections that correlate network-discovery-like behavior with suspicious application provenance, unusual permission use, recent installation, or broader compromise indicators rather than alerting on API access alone.
- Establish baselines for legitimate enterprise apps that need network context, such as connectivity, VPN, device management, or troubleshooting tools, to reduce false positives.
- Check for blind spots on unmanaged mobile devices, personally owned devices, devices outside MDM control, and applications where OS privacy controls limit telemetry visibility.
- Use the relationship to T1421 as the detection scope; the supplied ATT&CK object does not provide tactic mapping, detection pseudocode, or platform coverage beyond the related Android technique.
Mitigation priorities
- Start with mobile asset and management coverage: know which Android devices are enrolled, compliant, and capable of producing security telemetry.
- Limit application installation sources and review high-risk or unnecessary applications that request access to network connection context.
- Enforce mobile permission governance and user guidance for applications requesting Wi-Fi, Bluetooth, cellular, or related contextual access.
- Ensure incident response playbooks include mobile evidence collection and triage for suspicious applications accessing network context.
- Use compliance reporting to document mobile telemetry, MDM coverage, permission controls, and exceptions where detection is not technically available.
Analyst notes and limits
This ATT&CK object is a detection strategy record, not a technique. It has no official description or detection text, so the practical guidance must be derived from its relationship to T1421 and the supplied related technique description. The most important local validation is whether the organization can observe application behavior and permissions on Android devices closely enough to distinguish legitimate network-aware apps from suspicious discovery behavior.
ATT&CK provides no official detection logic, tactics, platforms, or description for DET0636. The related technique identifies Android and examples of network connection discovery, but local device management, OS version, privacy controls, and mobile security tooling will determine what can actually be detected.
Detection of System Network Connections Discovery
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1421 | System Network Connections Discovery | This object detects System Network Connections Discovery. |
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 | 1.0 | Current bundle | 21821341e55e… |
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 DET0636Open 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.