Join our Newsletter — 33% off our NHI Course
Home› Guides› Mobile ATT&CK Discovery Tactic: Detecting Device and Network…
Guide Endpoint Security

Mobile ATT&CK Discovery Tactic: Detecting Device and Network Reconnaissance on Android and iOS

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 12 November 2026 13 min read
On this page

Almost every piece of mobile malware first asks where it is: which phone, which apps, which network, which country, and whether anyone is watching, and the answers decide whether it fully infects the device. The Discovery tactic (TA0032) in MITRE ATT&CK for Mobile covers that reconnaissance. In v20 it holds eight techniques and five sub-techniques, and 102 distinct software, group and campaign entries use at least one of them, second only to Collection among Mobile tactics. Discovery is quiet and runs through normal operating system APIs, so it is rarely blocked outright, but it is shaped heavily by OS permissions and is visible to app vetting and, in part, to network monitoring. This hub explains what the tactic means on Android and iOS, which techniques matter most, how discovery feeds the rest of an intrusion, and how to limit and detect it. It is written for mobile security engineers, app vetting teams and SOC analysts. For the matrix as a whole, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

  • Discovery is near universal and decides the next step. ATT&CK repeatedly notes that discovery results shape "whether or not to fully infect the target", so it is where targeting, sandbox avoidance and security tool evasion begin.
  • Four techniques carry most of the data. Location Tracking (T1430), System Information Discovery (T1426), Software Discovery (T1418) and System Network Configuration Discovery (T1422) each have close to or more than 50 recorded users in v20.
  • The OS is the main control. Use Recent OS Version (M1006) is the most frequently mapped mitigation, because Android and iOS have steadily removed app access to process lists, device identifiers and installed app lists.
  • Permissions are the leading indicator. Location, nearby devices, package visibility and accessibility permissions are what make deep discovery possible, and they are visible to app vetting and MDM before any data is taken.
  • Network scanning from a phone is the enterprise risk. Network Service Scanning (T1423) has only one recorded user, LightSpy, but it is the step that turns a compromised phone into a pivot into internal networks.

What discovery means on a phone

ATT&CK defines the tactic as techniques that let the adversary "gain knowledge about the characteristics of the mobile device and potentially other networked systems", and observes that "the operating system may provide capabilities that aid in this post-compromise information-gathering phase". On a mobile device that means four questions:

  • What device is this? Model, OS version, patch level and identifiers (T1426), to choose exploits and to recognise emulators.
  • What else is installed and running? Installed apps (T1418), security tools (T1418.001) and processes (T1424), to find banking or messaging targets and to avoid or disable defences.
  • Where is the device and what network is it on? Location (T1430), network configuration and connectivity (T1422 and sub-techniques), current and nearby connections (T1421).
  • What is reachable and what is stored? Network services on the local network or over VPN (T1423) and files and directories (T1420).

The tactic matters to defenders less because discovery itself causes harm (location tracking is the exception) and more because it is the earliest behaviour that distinguishes a malicious app from a benign one. Banking trojans enumerate apps to find targets for overlays; spyware profiles the device before deploying its full implant.

Every technique in the tactic

The table lists every current technique and sub-technique under TA0032 in ATT&CK for Mobile v20. Each technique has its own guide on this site.

IDTechniqueSub-techniquesPlatformsUsers in v20Mitigations mapped
T1418Software Discovery.001 Security Software DiscoveryAndroid, iOS55User Guidance, Use Recent OS Version
T1420File and Directory DiscoveryNoneAndroid, iOS21Use Recent OS Version
T1421System Network Connections DiscoveryNoneAndroid10None
T1422System Network Configuration Discovery.001 Internet Connection Discovery, .002 Wi-Fi DiscoveryAndroid, iOS49Use Recent OS Version, Encrypt Network Traffic
T1423Network Service ScanningNoneAndroid, iOS1None
T1424Process DiscoveryNoneAndroid, iOS13Use Recent OS Version, Attestation
T1426System Information DiscoveryNoneAndroid, iOS58None
T1430Location Tracking.001 Remote Device Management Services, .002 Impersonate SS7 NodesAndroid, iOS61Use Recent OS Version, Enterprise Policy, User Guidance, Interconnection Filtering

Method: counts come from the ATT&CK for Mobile v20.0 STIX bundle. "Users" is the number of distinct, non-revoked, non-deprecated software, group and campaign objects with a "uses" relationship to the technique or any of its sub-techniques. Location Tracking also sits in the Collection tactic. Across the tactic ATT&CK records two groups (APT-C-23 and Windshift) and three campaigns, including Operation Triangulation and Operation Dust Storm.

Ranked: the techniques to cover first

  1. T1430 Location Tracking (61 users). The one discovery technique that is also direct harm, especially for executives, journalists and staff in sensitive roles. On Android it depends on ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION, and from Android 10 on ACCESS_BACKGROUND_LOCATION for background access; on iOS on location authorisation keys and user consent. Two sub-techniques sit outside the device entirely: tracking through a compromised MDM or cloud device-finder account (.001) and through SS7 signalling (.002, recorded for Circles), which the device cannot detect. See the Mobile Communications Protection for High-Risk Individuals Guide.
  2. T1426 System Information Discovery (58 users) and T1418 Software Discovery (55 users). Device profiling and app enumeration are the targeting step for banking trojans and the pre-check for spyware. ATT&CK records Operation Triangulation obtaining a list of installed applications and collecting device and user information, and LightSpy collecting the installed app list, phone number, IMEI and hardware details. ATT&CK notes that iOS typically lets apps query only the device model and OS version, while Android exposes more through android.os.Build. Since Android 11, package visibility filtering limits which installed apps an app can see unless it declares them or holds QUERY_ALL_PACKAGES, which Google Play subjects to approval.
  3. T1422 System Network Configuration Discovery (49 users). IP and MAC addresses, Wi-Fi details and internet reachability checks, which tell malware whether it is on a corporate network and whether its command server is reachable. ATT&CK records LightSpy gathering SSID, BSSID, signal strength, security type and previously saved networks. From Android 10, telephony identifiers such as IMEI are limited to preloaded, carrier, default SMS and device or profile owner apps; ATT&CK states that on iOS network configuration is not available without root.
  4. T1418.001 Security Software Discovery. Only three recorded users, but it is the bridge to defence evasion: finding the MTD agent or Play Protect state in order to avoid or disable it. See the Mobile ATT&CK Defence Evasion Tactic hub.
  5. T1423 Network Service Scanning (1 user). ATT&CK records LightSpy using a module to enumerate devices on the same Wi-Fi network through active scanning. Rare in the data, but the precursor to T1428 Exploitation of Remote Services. See the Mobile ATT&CK Lateral Movement Tactic hub.

T1424 Process Discovery and T1420 File and Directory Discovery are increasingly constrained by the platforms. ATT&CK notes that from Android 7 apps cannot obtain the process list without elevated privileges because of the kernel's hidepid mount option, that iOS removed the sysctl route, and that file discovery on both platforms is restricted by sandboxing and SELinux unless the attacker has escalated privileges. Seeing either technique in a sample is therefore a strong hint of a rooted device or an exploit chain.

How discovery chains with other tactics

Discovery resultWhat the adversary does nextFollow-on tactic
Emulator, root or analysis tools detected (T1426, T1418)Stays dormant or exitsDefense Evasion: T1633.001 System Checks
Security app or Play Protect found (T1418.001)Disables or avoids the toolDefense Evasion: T1629.003 Disable or Modify Tools
Target banking or wallet app installed (T1418)Shows overlays or captures input for that appCredential Access and Collection
Wrong country or language (T1426, T1430)Withholds the payloadDefense Evasion: T1627.001 Geofencing
Internet reachable, on Wi-Fi (T1422.001, T1421)Chooses when to beacon and upload large dataCommand and Control, Exfiltration
On corporate Wi-Fi or VPN with reachable services (T1422, T1423)Probes and exploits internal servicesLateral Movement: T1428

Two chains recur in the procedure data. Commodity Android banking malware runs device and app discovery immediately after install to decide whether the device is worth targeting. Advanced spyware, such as Operation Triangulation and LightSpy in ATT&CK's records, runs extensive discovery after an exploit chain has given it privileges, collecting identifiers, apps, processes, files, Wi-Fi and location as the basis for collection. Pegasus for iOS is recorded monitoring connection state and network type, potentially to judge whether full data can be sent.

Prevention priorities, Android and iOS

Counting "mitigates" relationships across the tactic in v20, Use Recent OS Version (M1006) appears 7 times, User Guidance (M1011) 4, Interconnection Filtering (M1014) 2, Enterprise Policy (M1012) 2, Attestation (M1002) 1 and Encrypt Network Traffic (M1009) 1. Three techniques have no mitigation mapped: T1421, T1423 and T1426. Platforms are listed alphabetically.

PriorityAndroidiOS and iPadOSTechniques reduced
Keep OS currentMinimum OS and security patch level in compliance policy; retire devices without updatesMinimum OS version in compliance policyT1418, T1420, T1422, T1424, T1430
Limit location exposureDISALLOW_CONFIG_LOCATION where location must stay under policy; review apps holding background locationReview location authorisation keys and usage strings in app vetting and through MDM app inventoryT1430
Control which apps are installedManaged Google Play allow list; block unknown sources; review apps requesting QUERY_ALL_PACKAGESSupervised app restrictions; block untrusted in-house developersT1418, T1426
Detect compromised devicesPlay Integrity device integrity verdictsMDM compliance and MTD compromised device detectionT1424, T1420 (privileged discovery)
Protect the management planeStrong, phishing-resistant authentication for EMM consoles and Google accountsStrong, phishing-resistant authentication for MDM consoles and Apple AccountsT1430.001
Segment the networkPer-app VPN or ZTNA for managed apps; separate mobile Wi-Fi from server networksT1423, T1422

T1430.002 is mitigated by mobile operators through interconnection filtering of signalling traffic, not by the enterprise. For high-risk staff, the practical controls are awareness, end-to-end encrypted communications and the guidance in the Mobile Communications Protection for High-Risk Individuals Guide.

Detection priorities

ATT&CK v20 detection strategies for this tactic draw mainly on application vetting and instrumented dynamic analysis, EMM and Apple MDM state, and enterprise network logs. On-device API calls are not visible to an MDM, so the realistic order is:

  1. App vetting before deployment. Static review of declared permissions (location, background location, nearby devices, package visibility, accessibility) and dynamic analysis of the API calls the app makes in its first minutes. Discovery bursts right after first launch, especially enumeration of installed apps and device identifiers, are a strong malicious indicator.
  2. MDM and MTD posture. Inventory of apps holding sensitive permissions, sideloaded apps, and integrity status. Privileged discovery (processes, file system) implies a compromised device.
  3. Network monitoring. A mobile address scanning many internal hosts or ports is unusual and high value. On Android device owner devices (Android 8.0 and later) and work profiles (Android 12 and later), network logging records DNS lookups and TCP connections per package, though it misses UDP and connections that bypass DNS.
  4. Management plane audit. For T1430.001, review MDM and device-finder location queries in console audit logs, and alert on location lookups by unexpected administrators.
  5. Forensics. If spyware is suspected, use the Mobile Verification Toolkit (MVT); see the Mobile Spyware Infection Response Playbook.

Metrics

  • Background location exposure: number of managed apps holding background location, trended over time.
  • Vetting coverage: percentage of managed apps and updates that passed dynamic analysis.
  • OS currency: percentage of devices at or above the minimum OS and patch level.
  • Mobile scanning alerts: internal scanning events sourced from mobile address ranges, with time to triage.
  • Console location queries: number of MDM location lookups per month, each tied to a ticket.

Where identity fits

MDM, EMM and cloud device-finder consoles can locate, inventory and sometimes wipe every enrolled device, which is why ATT&CK lists Remote Device Management Services as a location tracking sub-technique. The accounts that run these consoles, and any API credentials that integrate them with other tools, are high-value identities. Protect them with phishing-resistant MFA, least privilege roles, and audit of location and inventory queries. See the Mobile Device Management Security Guide.

Common failure patterns

  • Accepting permissions at face value. Apps that ask for location or package visibility "for features" are approved without checking whether the feature needs it.
  • Vetting only once. An update can add discovery and background location; permission changes on update are not reviewed.
  • Weak MDM console security. The console can locate every device, but administrators sign in with passwords alone and location queries are not audited.
  • Mobile traffic invisible to the SOC. VPN and Wi-Fi logs do not identify the device, so scanning from a phone looks like noise from a pool address.
  • Old devices in service. Devices stuck on unsupported OS versions keep discovery routes the platforms have since closed.

Coverage checklist and framework mapping

FrameworkWhere this tactic sits
NIST SP 800-124 Rev. 2Mobile device management, app vetting and mobile endpoint protection across the device lifecycle
NIST SP 800-53 Rev. 5AC-19 Access Control for Mobile Devices, CM-7 Least Functionality, SI-4 System Monitoring, SC-7 Boundary Protection
CIS Controls v8.1Control 2 Inventory and Control of Software Assets, Control 4 Secure Configuration of Enterprise Assets and Software, Control 13 Network Monitoring and Defense
NIST CSF 2.0PR.PS Platform Security; DE.CM Continuous Monitoring

Practitioner checklist

  • Map all eight techniques to a prevention, a detection or an accepted gap, noting the three with no mitigation (T1421, T1423, T1426).
  • Enforce minimum OS and patch levels and retire unsupported devices.
  • Review managed apps for background location, package visibility and accessibility permissions, on first approval and every update.
  • Run dynamic analysis that records discovery API calls in the first minutes after launch.
  • Gate access on device integrity so privileged discovery on a rooted or jailbroken device triggers quarantine.
  • Protect MDM, EMM and device-finder accounts with phishing-resistant MFA and audit every location query.
  • Tag VPN, ZTNA and Wi-Fi logs with device identity and alert on scanning from mobile ranges.
  • Brief high-risk staff on location tracking, including network-level tracking the device cannot see.

Standards and references

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile App Permissions · Mobile Malware Guide · Mobile Threat Defense Buyer's Guide

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 12 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org