T1423: Network Service Scanning
Adversaries may attempt to get a listing of services running on remote hosts, including those that may be vulnerable to remote software exploitation. Methods to acquire this information include port scans and vulnerability scans from the mobile device. This technique may take advantage of the mobile device's access to an internal enterprise network either through local connectivity or through a Virtual Private Network (VPN).
Analyst context for executives and security teams
Network Service Scanning on mobile matters because a compromised or misused Android or iOS device can become a reconnaissance point inside an enterprise network, especially when it has local network access or a VPN connection. The business issue is not the scan itself; it is what the scan can reveal next: reachable internal services, exposed management interfaces, or vulnerable systems that were never expected to be probed from a phone or tablet.
Executive priority
Treat this as a mobile-to-enterprise network visibility and segmentation question. Leaders should ask whether mobile devices on Wi-Fi or VPN can enumerate internal services, whether that activity would be noticed, and whether SOC and incident response teams have evidence to distinguish legitimate network diagnostics from suspicious scanning. This technique is relevant to resilience, audit evidence, and control prioritization because it tests whether mobile access paths are governed with the same rigor as traditional endpoints.
Technical view
For SOC, detection engineering, and IR teams, validate monitoring for port-scan or vulnerability-scan-like behavior originating from Android and iOS devices, particularly across VPN connections or internal wireless networks. ATT&CK provides no official detection text for T1423, but the relationship to DET0696 indicates a detection strategy exists for Network Service Scanning. The LightSpy relationship shows this behavior is represented in ATT&CK as used by mobile malware, so investigations should consider whether mobile-originated scanning is part of broader device compromise or post-compromise discovery activity.
Likely telemetry
- VPN connection logs showing mobile device source identity, assigned IPs, and internal destinations
- Wireless network logs or NAC records mapping mobile devices to internal network access
- Firewall, proxy, or network sensor events showing many connection attempts across ports or hosts
- IDS/NDR alerts for port scanning or vulnerability scanning patterns from mobile-assigned addresses
- Mobile device management or endpoint inventory data identifying Android and iOS devices associated with the source
Detection direction
- Baseline expected mobile traffic on internal Wi-Fi and VPN, then tune for unusual fan-out across many hosts or ports from Android or iOS devices.
- Correlate network scan indicators with device identity from MDM, VPN, NAC, DHCP, and authentication sources to avoid treating mobile IP addresses as anonymous infrastructure.
- Account for false positives from authorized vulnerability scanners, IT diagnostics, network monitoring tools, or troubleshooting activity that may share scanning characteristics.
- Review DET0696, where available in the ATT&CK data set, for detection-strategy context rather than relying on the T1423 object alone, because this technique has no official detection text supplied.
- Prioritize alert triage when scanning originates from mobile access paths that should not normally reach broad internal address ranges or sensitive service tiers.
Mitigation priorities
- Limit mobile device reachability to internal services based on business need, especially over VPN and enterprise wireless networks.
- Use segmentation and access controls so mobile devices cannot broadly enumerate internal hosts or management interfaces.
- Maintain reliable device identity and ownership mapping through mobile management, VPN, NAC, and network inventory processes.
- Ensure incident response playbooks include mobile-originated reconnaissance as a scenario, including steps to preserve network logs and assess the associated mobile device.
- Use the technique as a validation point for compliance and audit evidence: prove who can access internal networks from mobile platforms, what they can reach, and how scanning would be detected or investigated.
Analyst notes and limits
This take is based on the supplied ATT&CK object for T1423 Network Service Scanning, its Android and iOS platform scope, the official description, the absence of official detection text, and the stated relationships to DET0696 and LightSpy. The key defensive value is validating whether mobile access paths create under-monitored internal reconnaissance opportunities.
ATT&CK fields supplied here do not specify tactics, mitigations, data sources, or official detection logic for T1423. Local network architecture, VPN design, mobile management coverage, and logging quality are required to determine actual exposure or detection coverage. The LightSpy relationship supports relevance to mobile malware behavior but does not by itself imply current activity in any environment.
Network Service Scanning
Adversaries may attempt to get a listing of services running on remote hosts, including those that may be vulnerable to remote software exploitation. Methods to acquire this information include port scans and vulnerability scans from the mobile device. This technique may take advantage of the mobile device's access to an internal enterprise network either through local connectivity or through a Virtual Private Network (VPN).
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.
Groups, software, and campaigns
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]
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.1 | Current bundle | 15ab5a15a30f… |
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 T1423Open 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.