AN1687: Analytic 1687
Mobile security products can potentially detect rogue Wi-Fi access points if the adversary is attempting to decrypt traffic using an untrusted SSL certificate. Application vetting services should look for applications that request VPN access. These applications should be heavily scrutinized since VPN functionality is not very common. On both Android and iOS, the user must grant consent to an application to act as a VPN. Both platforms also provide visual context to the user in the top status bar when a VPN connection is active. The user can see registered VPN services in the device settings.
Analyst context for executives and security teams
This analytic is about mobile defense against risky network interception conditions and unusual VPN-capable applications on Android. For leaders, the practical issue is trust in mobile traffic: if a device is connecting through a rogue Wi-Fi access point, accepting an untrusted SSL certificate, or running an app with VPN privileges, business communications may be exposed or redirected. The object does not provide a full detection rule, so its value is mainly as a validation checklist for mobile security monitoring and application vetting.
Executive priority
Prioritize this where Android devices access corporate email, identity services, cloud applications, or sensitive data over unmanaged networks. Security leaders should ask whether mobile security tooling can surface untrusted certificate events, whether app vetting flags VPN permission requests, and whether users and support teams can verify when a VPN is active. This supports mobile risk management, incident triage, and audit evidence for controls around device trust and application governance.
Technical view
For SOC, mobile security, and IR teams, validate Android telemetry around rogue Wi-Fi indicators, SSL certificate trust failures or user acceptance of untrusted certificates, and applications requesting or registering VPN functionality. Because no official detection logic is supplied and no ATT&CK tactics are specified, teams should treat AN1687 as a detection strategy component rather than a complete analytic. Application review workflows should heavily scrutinize apps requesting VPN access, since the official description notes VPN functionality is uncommon. IR playbooks should include checks of device settings for registered VPN services and user-visible VPN status indicators.
Likely telemetry
- Mobile security product alerts for rogue or suspicious Wi-Fi access points
- Android certificate trust or untrusted SSL certificate events, where available
- Mobile application permission and capability metadata, especially VPN access requests
- Inventory of installed applications and registered VPN services on devices
- Device settings or management data showing active VPN state
Detection direction
- Confirm whether mobile security tooling can detect rogue Wi-Fi access points specifically when untrusted SSL certificates are involved.
- Tune application vetting to flag Android applications that request VPN access for enhanced review rather than automatic blocking without context.
- Validate visibility into registered VPN services on managed Android devices and whether that evidence is available to SOC or mobile administrators.
- Account for false positives from legitimate corporate VPN clients, privacy tools, and approved network security applications.
- Document blind spots for unmanaged devices, devices outside mobile management, and cases where certificate or VPN-state telemetry is not collected.
Mitigation priorities
- Maintain an approved inventory of Android VPN applications and scrutinize new or unknown apps requesting VPN access.
- Use application vetting or mobile management processes to review VPN-capable apps before deployment or approval.
- Educate users and support teams to recognize platform VPN indicators and to report unexpected VPN activity.
- Ensure mobile security controls monitor for suspicious Wi-Fi and untrusted certificate conditions where supported.
- Preserve mobile telemetry needed for incident response, including installed app inventory, VPN registration state, and relevant network/certificate alerts.
Analyst notes and limits
This object is a detection analytic in the mobile ATT&CK domain with Android listed as the platform. The official description references both Android and iOS user consent and visual VPN indicators, but the supplied platform field only supports Android for this object. There are no supplied relationships, tactics, aliases, labels, or official detection logic, so the take focuses on defensive validation and governance rather than a specific rule implementation.
The source does not include a detection query, data source list, tactic mapping, technique relationship, or evidence of active exploitation. Local mobile management coverage, certificate telemetry, app inventory quality, and user/device ownership model will determine whether this analytic can be operationalized.
Analytic 1687
Mobile security products can potentially detect rogue Wi-Fi access points if the adversary is attempting to decrypt traffic using an untrusted SSL certificate. Application vetting services should look for applications that request VPN access. These applications should be heavily scrutinized since VPN functionality is not very common. On both Android and iOS, the user must grant consent to an application to act as a VPN. Both platforms also provide visual context to the user in the top status bar when a VPN connection is active. The user can see registered VPN services in the device settings.
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 | a2e6240f049a… |
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 AN1687Open 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.