Almost every piece of mobile malware catalogued by MITRE starts by asking the phone who it is and how it is connected: phone number, IMEI, IMSI, SIM operator, IP and MAC address, Wi-Fi or cellular, roaming or at home. ATT&CK for Mobile tracks this as T1422 System Network Configuration Discovery, a Discovery (TA0032) technique on Android and iOS, with two sub-techniques: T1422.001 Internet Connection Discovery and T1422.002 Wi-Fi Discovery. The answers let an operator confirm the right target, decide when to beacon and plan what to do next. This guide is for mobile security engineers, MDM administrators and SOC analysts who need to know what the platforms still allow, where the telemetry is, and how to reduce what an app can learn. It goes deeper than our MITRE ATT&CK for Mobile Guide; the host equivalent is covered in T1016 System Network Configuration Discovery.
Key takeaways
- The platform already removed the worst of it. ATT&CK notes that since Android 10 only preloaded, carrier, default SMS, or device and profile owner apps can read telephony identifiers such as IMEI and IMSI, so OS version is your first control.
- iOS needs a privileged implant. ATT&CK states that gathering network configuration on iOS is not possible without root access; the iOS cases it records come from spyware with exploit chains, such as Operation Triangulation.
- Wi-Fi data is location data. On Android,
WifiManager.getScanResults()still needsACCESS_FINE_LOCATIONeven for apps targeting Android 13, which makes the permission request itself a vetting signal. - Detection lives in app vetting and network logs, not on the handset. ATT&CK's detection strategies DET0634, DET0708 and DET0709 point to dynamic analysis, EMM app inventory, Android Enterprise network logging and per-app VPN flow data.
- Discovery is a stage, not the goal. Treat a hit as evidence of a resident app that will also collect, exfiltrate or call home, and respond to the device as compromised.
What the technique covers
ATT&CK v20 describes adversaries looking for details about network configuration and settings, such as IP and MAC addresses, of devices they access. On Android, ATT&CK names the java.net.NetworkInterface class as the route to onboard interface details and the TelephonyManager class as the historical route to IMSI, IMEI and phone number, now restricted from Android 10. On iOS it states plainly that the information is not reachable without root access. Both platforms are listed for the parent and both sub-techniques.
| ID | Name | Platforms (v20) | What is collected | ATT&CK mitigation | Detection strategy |
|---|---|---|---|---|---|
| T1422 | System Network Configuration Discovery | Android, iOS | IP and MAC addresses, IMEI, IMSI, ICCID, phone number, operator, MCC and MNC, cell IDs | M1006 Use Recent OS Version | DET0634 |
| T1422.001 | Internet Connection Discovery | Android, iOS | Whether the device is online, Wi-Fi or cellular, roaming, metered, routes, redirectors and proxies | M1009 Encrypt Network Traffic | DET0708 |
| T1422.002 | Wi-Fi Discovery | Android, iOS | Network names, BSSIDs, signal strength, security type, nearby and previously joined networks, sometimes passwords | M1006 Use Recent OS Version | DET0709 |
T1422.001 Internet Connection Discovery
The adversary checks whether the device can reach the internet before trying to contact command and control, and may use the responses to identify routes, redirectors and proxy servers. ATT&CK gives adb shell netstat as an Android example, which matters for anyone who leaves USB debugging on: see Android Platform Tools and ADB. In practice the malware recorded under this sub-technique checks the active interface: Pegasus for Android (S0316) checks for Wi-Fi, cellular and roaming, Monokle (S0407) checks Wi-Fi or mobile data, and TERRACOTTA (S0545) checks whether the active connection is metered.
T1422.002 Wi-Fi Discovery
ATT&CK describes searching for Wi-Fi network names and passwords, for use in discovery or credential access. Recorded examples include LightSpy (S1185), whose WifiList plugin collects SSID, BSSID, signal strength, channel, security type and previously connected networks; VajraSpy (S9006), which scanned for Wi-Fi networks; and DocSwap (S9005), which checked for the ACCESS_WIFI_STATE and CHANGE_WIFI_STATE permissions. BSSIDs from nearby access points are a location fix, so this sub-technique overlaps with location tracking even when the app never asks for GPS. Our Wi-Fi Tracking Guide explains why.
How adversaries use it: real cases
ATT&CK v20 records dozens of procedure examples for T1422. The pattern is consistent: identifiers are collected in the first contact so the operator can validate the target and key the infection.
- Target validation by commercial spyware: ATT&CK records that Exodus (S0405) stage one queried the IMEI and phone number to validate the target of a new infection, citing Security Without Borders.
- iOS implants with root: during Operation Triangulation (C0054), ATT&CK records the implant's heartbeat beacons carrying IMEI, MEID and serial number, and the Binary Validator (S1215) collecting phone number and IMEI, citing Kaspersky's Securelist analysis. This is the iOS case ATT&CK's root-access statement anticipates.
- Surveillanceware from state-linked groups: ATT&CK records APT-C-23 (G1028) collecting phone number, device information and IMSI, and BOULDSPY (S1079) collecting IP address, SIM and Wi-Fi information, citing Lookout.
- Banking trojans: TrickMo (S0427) collects IMSI, IMEI and Wi-Fi connection state; Exobot (S0522), Rotexy (S0411) and Gustuff (S0406) send the IMEI to command and control. See the Android Banking Trojans Guide.
The Commercial Spyware Guide covers the spyware families above in context.
What each platform allows
| Data | Android (third-party app) | iOS (App Store app) |
|---|---|---|
| IMEI, IMSI, phone number | Since Android 10, restricted to preloaded, carrier, default SMS, and device or profile owner apps (ATT&CK, citing the TelephonyManager reference). Android's permission guidance states that from Android 10 apps cannot read the IMEI and should use an app-scoped identifier instead. | ATT&CK: not possible without root access. |
| Interface addresses | Available through java.net.NetworkInterface (ATT&CK). | ATT&CK: not possible without root access. |
| Connectivity state | Connectivity APIs; ATT&CK's analytic names ConnectivityManager.getActiveNetworkInfo() and InetAddress.isReachable(). | ATT&CK's analytic names NWPathMonitor and SCNetworkReachabilityGetFlags(). |
| Wi-Fi scan and current network | getScanResults() and startScan() need ACCESS_FINE_LOCATION; apps targeting Android 13 or higher that manage Wi-Fi request NEARBY_WIFI_DEVICES. | ATT&CK's analytic names CNCopyCurrentNetworkInfo() and NEHotspotHelper, gated by code-signing entitlements and Info.plist usage descriptions. |
The practical reading: on a current, unrooted Android device a store app can still learn connectivity and interface details, and with location permission it can scan Wi-Fi. On a current iPhone the identifiers in the ATT&CK cases appear only after a privilege escalation. That shifts your iOS effort towards exploit resistance: updates and, for high-risk users, the Apple Lockdown Mode Guide.
What to detect and where
ATT&CK v20's analytics for this technique are explicit that you should correlate analyst-visible evidence and not infer unobserved API calls from management state alone. The table summarises the sources they name.
| Source | Android | iOS | What it tells you |
|---|---|---|---|
| App vetting, dynamic analysis | Runtime traces of NetworkInterface.getNetworkInterfaces(), connectivity checks and WifiManager.getScanResults() outside an allow-list | Runtime traces of NWPathMonitor, reachability and Wi-Fi info calls outside an allow-list | Which apps collect network and identity data, and when (at launch, on a schedule, without user action) |
| Permission and entitlement review | Manifest permissions and DevicePolicyManager.getPermissionGrantState() | Entitlements and Info.plist usage descriptions | Apps asking for Wi-Fi state and location without a functional reason |
| EMM inventory | Managed package inventory and metadata | MDM InstalledApplicationList, ManagedApplicationList, DeviceInformation, SecurityInfo, ProfileList | Unexpected apps, profiles and compliance drift |
| Network evidence | Android Enterprise network logging: DnsEvent and ConnectEvent per package | Network Extension, per-app VPN or secure web gateway flow metadata | Connectivity probes and first beacons from an unexpected package |
Android network logging: Android's DPC documentation describes setNetworkLoggingEnabled() and retrieveNetworkLogs(), available to the device owner from Android 8.0 and to the profile owner of a work profile from Android 12, where it covers only work profile activity. Each DnsEvent and ConnectEvent carries the package name. Know its limits from the same page: UDP is not recorded, apps that make direct system calls or connect to fixed IPs bypass parts of it, and batches are deleted if not retrieved. Android itself advises network-layer reporting at a VPN gateway or firewall where complete coverage matters.
Forensics: where you suspect an implant, the Amnesty Security Lab's Mobile Verification Toolkit supports consensual analysis of iOS backups, filesystem dumps and sysdiagnose archives, and Android backups, against published indicators. See the Mobile Verification Toolkit (MVT) guide and the Mobile Spyware Infection Response Playbook.
Reducing what discovery reveals
- Enforce minimum OS versions. M1006 is the only ATT&CK mitigation on the parent. Set an EMM compliance rule that blocks corporate access below your supported Android and iOS versions, and patch level as well as major version.
- Control where apps come from. Keep Google Play Protect on: Google documents a daily scan, checks on apps from outside Google Play at install, and automatic removal of the most harmful apps. On managed devices block unknown sources; on iOS, rely on managed app distribution. See the Android Enterprise Security Guide and the iOS and iPadOS Enterprise Security Guide.
- Treat location and Wi-Fi permissions as high-risk. Pre-grant or deny runtime permissions through managed configuration where your EMM supports it, and review any app that requests Wi-Fi state with location. Our Mobile App Permissions guide covers the policy.
- Encrypt and route traffic. M1009 on T1422.001 reduces what an observer learns from connectivity probes; a per-app or always-on VPN also gives you the flow data you need for detection.
- Turn off developer paths. Disable USB debugging and developer options on managed Android devices so
adb-based discovery is not available. - Raise the bar for high-risk users. Lockdown Mode on iOS and Android Advanced Protection reduce the exploit surface that root-level implants depend on.
Where identity fits
Device identifiers are often used as identity signals. A backend that binds a session, a device trust decision or an API key to an IMEI, phone number or MAC address is trusting data that T1422 is designed to harvest. Use platform attestation and app-scoped identifiers instead, as Android's own guidance recommends, and keep API keys and refresh tokens out of places where a resident app or an implant can read them. See the Mobile App Attestation Guide and the Mobile Access Credentials Guide.
Measuring whether it works
- OS currency: percentage of managed devices on a supported OS and patch level; target above 95 per cent.
- Vetting coverage: percentage of approved apps with a dynamic analysis report that lists network and Wi-Fi API use.
- Permission exceptions: number of apps holding Wi-Fi state plus fine location without a documented reason; trend to zero.
- Telemetry reach: percentage of corporate-owned Android devices with network logging retrieved in the last 24 hours, and of iOS devices on per-app VPN.
- Time to isolate: median time from an MTD or vetting alert to the device losing corporate access.
Common failure patterns
- Ignoring the permission signal: approving a utility app that asks for Wi-Fi state and precise location because "it needs network access".
- Trusting device identifiers as authenticators: using IMEI or phone number to recognise a trusted device, which turns discovery into a credential.
- Enabling network logging and never retrieving it: Android deletes batches to make room for new ones, and unaffiliated users or profiles block retrieval.
- Assuming iOS is out of scope: ATT&CK's iOS cases are rare but high-impact; skipping updates and Lockdown Mode for exposed staff leaves the path open.
- Leaving USB debugging on in the fleet: developer options on shared or kiosk devices expose
adbto anyone with a cable.
Framework mapping
| Framework | Reference | Why it applies |
|---|---|---|
| ATT&CK for Mobile v20 | M1006 Use Recent OS Version; M1009 Encrypt Network Traffic | Mitigations mapped to T1422 and its sub-techniques |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring; CM-8 System Component Inventory; SI-2 Flaw Remediation; SC-8 Transmission Confidentiality and Integrity | Telemetry, app and device inventory, OS updates, encrypted transport |
| NIST CSF 2.0 | DE.CM-09; ID.AM-02; PR.PS-02 | Monitoring devices and software, inventory, maintaining software |
| OWASP MASVS | MASVS-PRIVACY; MASVS-NETWORK | For your own apps: collect only the device data you need and protect it in transit |
Practitioner checklist
- Set EMM compliance rules for minimum Android and iOS versions and patch levels.
- Block unknown sources on managed Android and keep Play Protect enabled.
- Add network, connectivity and Wi-Fi API use to your app vetting report template.
- Flag apps requesting Wi-Fi state with precise location and require a business reason.
- Enable and actually collect Android Enterprise network logging, or deploy per-app VPN flow logging on both platforms.
- Disable USB debugging and developer options on managed devices.
- Remove IMEI, phone number and MAC address from any device trust or authentication logic.
- Offer Lockdown Mode and Android Advanced Protection to high-risk staff, and keep an MVT-based triage route ready.
Standards and references
- MITRE ATT&CK: T1422 System Network Configuration Discovery (Mobile)
- MITRE ATT&CK: T1422.001 Internet Connection Discovery
- MITRE ATT&CK: T1422.002 Wi-Fi Discovery
- Android Developers: Wi-Fi permissions
- Android Developers: Network activity logging
- Android Developers: Minimise your permission requests
- Apple: About Lockdown Mode
- Amnesty International Security Lab: Mobile Verification Toolkit documentation
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · T1016 System Network Configuration Discovery · Mobile Device Management Security Guide · Mobile Threat Defense Buyer's Guide