Mobile T1423 Network Service Scanning: Stopping Phones Becoming Internal Network Scanners

A compromised phone on the office Wi-Fi or the corporate VPN is a scanner sitting inside your network perimeter, and most networks were never designed to treat it that way. MITRE ATT&CK for Mobile tracks this as T1423 Network Service Scanning, a Discovery (TA0032) technique on Android and iOS: listing services on remote hosts, including those that may be open to remote exploitation, through port and vulnerability scans run from the mobile device. ATT&CK stresses that the technique takes advantage of the device's access to the enterprise network through local connectivity or a VPN. This short guide is for network, mobile and SOC teams deciding how much network a mobile device should see and how to catch scanning that starts from one. It builds on our MITRE ATT&CK for Mobile Guide.

Key takeaways

• The control is on the network, not the handset. ATT&CK v20 lists no mitigation for T1423, and its detection strategy says scanning is hard to see on the device itself.
• Reachability is the risk. A phone that can reach every subnet over the VPN gives an implant the same view a laptop would; limit mobile access to the services it needs.
• Per-app VPN shrinks the scanner. Apple documents that with per-app VPN only managed apps reach the private network, which keeps an unmanaged or malicious app off it.
• Detect where packets land. Network detection, firewall and VPN gateway logs see a phone address touching many hosts or ports, even when the phone shows nothing.
• Recorded use is rare but real. ATT&CK records one procedure example, the LightSpy iOS implant, whose plugin enumerates devices on the same Wi-Fi network.

What the technique covers

ATT&CK v20 describes adversaries attempting to get a listing of services running on remote hosts, by port scans and vulnerability scans from the mobile device. There are no sub-techniques. Both Android and iOS are listed. The technique sits in the mobile matrix because the device is the vantage point: it connects to guest and corporate Wi-Fi, home networks and the VPN, and it often holds the credentials for all three. The enterprise counterpart, scanning from servers and workstations, is ATT&CK T1046 Network Service Discovery.

The real case: LightSpy

ATT&CK records that LightSpy (S1185) uses its landevices module to enumerate devices on the same Wi-Fi network through active scanning. ThreatFabric's October 2024 analysis of the iOS implant lists landevices as a Wi-Fi network scanning plugin alongside WifiList, which exfiltrates Wi-Fi network data. The same report describes delivery through a Safari WebKit exploit (CVE-2020-9802) and privilege escalation (CVE-2020-3837), targeting iOS versions up to 13.3. Two lessons follow. First, the scanning capability arrived as one plugin among many, after full device compromise, so the same implant was also taking messages, contacts and Wi-Fi details. Second, every vulnerability in that chain had a patch: OS currency stopped this one. See the Commercial Spyware Guide for the wider family.

Limit what a phone can reach

• Apple per-app VPN: Apple's deployment guide states that per-app VPN lets each app that a device management service manages communicate with the private network, and that unmanaged apps are kept off it. On iOS and iPadOS the app must be managed. Always On VPN (IKEv2) routes all traffic and drops IP traffic if the tunnel is down, which helps inspection but widens what any app on the device can reach.
• Android Enterprise VPN: the Android Management API exposes alwaysOnVpnPackage for an always-on VPN, with vpnConfigDisabled to stop users changing it. Pair it with a VPN gateway policy that limits destination networks per user group; the device setting decides whether traffic is tunnelled, the gateway decides where it may go.
• Client isolation on Wi-Fi: on guest and BYOD SSIDs, enable client isolation in the wireless controller so devices cannot see each other. See the Wi-Fi Security Guide.

What to detect and where

Follow ATT&CK's advice: do not expect the handset to tell you. Build the detection where the scan lands, and in parallel watch the earlier stages that put the implant on the device.

1. VPN gateway and firewall: alert on a single mobile client address or VPN session reaching many distinct internal hosts or ports in a short window, or touching ports no mobile app uses (SMB on 445, RDP on 3389, SSH on 22, database ports).
2. Network detection and response: put the mobile segment and VPN pool in scope of your NDR sensors. See the NDR Guide.
3. Wireless controller: where the controller logs inter-client traffic or isolation violations, forward them to the SIEM.
4. Correlate with device state: join the VPN or Wi-Fi session to the device in your EMM by user and device identifier, then check OS version, compliance and recent app installs.
5. Earlier stages: exploit delivery and implant install are where mobile threat defence and OS telemetry help; for suspected spyware use the Mobile Verification Toolkit (MVT) and the Mobile Spyware Infection Response Playbook.

Where identity fits

Network access from a phone is granted to an identity: a VPN certificate or profile pushed by MDM, a Wi-Fi 802.1X credential, or a ZTNA session token. When an implant scans, it is using those credentials. Issue device certificates per device, not shared across a fleet, so a scanning session points to one device, and revoke them as part of response. Authorise mobile identities for named applications, not network ranges. See the 802.1X and EAP-TLS Enterprise Wi-Fi Guide and the Mobile Access Credentials Guide.

Measuring whether it works

• Reachable surface: number of internal subnets and ports reachable from the mobile VPN pool; trend down.
• Per-app coverage: percentage of managed iOS and Android devices using per-app VPN or app-level access rather than full network access.
• Sensor coverage: mobile Wi-Fi segments and VPN pools inside NDR and firewall logging scope, as a percentage.
• Response: median time from a scan alert to revoking the device's VPN or Wi-Fi credential.

Common failure patterns

• One flat VPN pool: phones and laptops share a pool with any-to-any rules, so a phone sees everything a laptop does.
• Corporate Wi-Fi with no client isolation: BYOD phones can probe each other and any printer, camera or controller on the same segment.
• No logging on the mobile segment: NDR and firewall logging covers servers and user LANs but not the wireless or VPN ranges.
• Shared device credentials: one VPN certificate or Wi-Fi password across the fleet, so a scan cannot be traced to a device or revoked without disrupting everyone.

Framework mapping

Practitioner checklist

• Place managed and BYOD mobile devices on dedicated Wi-Fi segments with client isolation.
• Replace full-network mobile VPN with per-app VPN or application-level access.
• Restrict VPN gateway rules for mobile pools to named destinations and ports.
• Bring mobile segments and VPN pools into NDR and firewall logging, with a fan-out alert.
• Issue per-device certificates for Wi-Fi and VPN and include revocation in the response runbook.
• Enforce minimum OS versions so exploit-delivered implants have fewer paths in.

Standards and references

• MITRE ATT&CK: T1423 Network Service Scanning (Mobile)
• MITRE ATT&CK: LightSpy (S1185)
• MITRE ATT&CK: T1046 Network Service Discovery
• Apple Platform Deployment: VPN overview for Apple devices
• Google: Android Management API policies reference
• ThreatFabric: LightSpy implant for iOS

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · NDR Guide · ZTNA Guide · Mobile Device Management Security Guide