AN1810: Analytic 1810
Network service scanning can be difficult to detect, and therefore enterprises may be better served focusing on detection at other stages of adversarial behavior.
Analyst context for executives and security teams
This analytic is a caution that network service scanning on Android may not be a reliable place to anchor detection. For security leaders, the practical value is prioritization: do not assume mobile network scanning will produce clean, timely alerts, and make sure the program has visibility and response coverage at other observable stages of suspicious mobile activity.
Executive priority
Treat this as a coverage-gap and investment-prioritization issue for mobile security. If Android devices are important to operations, executives should ask whether SOC and incident response plans depend too heavily on detecting scanning itself. The safer business decision is to validate compensating visibility, response procedures, and evidence collection around other stages of adversarial behavior rather than budgeting or reporting around an analytic that MITRE describes as difficult to detect.
Technical view
For Android environments, use this analytic to test assumptions rather than to claim coverage. MITRE provides no concrete detection logic and explicitly notes that network service scanning can be difficult to detect. SOC and detection engineering teams should review whether mobile network telemetry, device management data, and network monitoring can distinguish scanning-like behavior from benign discovery or application activity. IR teams should ensure playbooks do not require a scanning alert as the first signal before investigating related mobile compromise indicators.
Likely telemetry
- Android device management or mobile security events where available
- Network flow or connection metadata involving Android devices
- Wireless, VPN, proxy, or gateway logs that can associate traffic with mobile devices
- Asset and device inventory for identifying Android endpoints
- Incident timelines and correlated alerts from other stages of adversarial behavior
Detection direction
- Do not treat absence of scanning alerts as evidence of absence; MITRE states this behavior can be difficult to detect.
- Validate whether network telemetry can reliably identify Android-originated connection patterns without excessive false positives from normal apps, updates, diagnostics, or enterprise tools.
- Prioritize correlation with other observable behaviors because the supplied ATT&CK analytic recommends focusing detection at other stages.
- Document mobile visibility gaps explicitly in SOC coverage maps and audit evidence rather than representing this analytic as a complete detection.
Mitigation priorities
- Maintain accurate inventory and ownership of Android devices so suspicious network activity can be scoped quickly.
- Strengthen mobile device management, access controls, and network segmentation where applicable to reduce exposure if scanning is missed.
- Ensure incident response procedures can investigate Android devices using available device, identity, and network evidence.
- Use this analytic as a prompt to prioritize broader mobile detection coverage instead of relying on network service scanning alone.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for the mobile domain with Android as the only listed platform. No tactic, relationship context, or official detection logic is provided. The main decision value is recognizing that this behavior is hard to detect and should not be the sole basis for SOC coverage claims.
This take is limited to the official STIX fields and external reference supplied. There are no relationships, procedure examples, concrete detection queries, mitigations, or tactic mappings in the provided object, so local telemetry validation is required before making coverage, risk, or compliance assertions.
Analytic 1810
Network service scanning can be difficult to detect, and therefore enterprises may be better served focusing on detection at other stages of adversarial behavior.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 2d50e8e7276c… |
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 AN1810Open 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.