AN1715: Analytic 1715
Correlates (1) changes to application visibility or user-facing presence such as launcher component disablement, icon suppression, or reduced discoverability, (2) continued application execution or privileged framework activity after that visibility reduction, and (3) follow-on behavior such as background network communication, sensor access, or persistence-related state transitions. The defender observes a causal chain where an application becomes less visible to the user while retaining or increasing operational activity.
Analyst context for executives and security teams
Analytic 1715 is about spotting Android applications that become less visible to the user while continuing to run or expand activity in the background. For security leaders, the value is not the icon change itself; it is the combination of reduced user discoverability plus ongoing execution, network use, sensor access, or persistence-related state changes. That pattern can undermine user trust, mobile fleet governance, and incident response visibility because the app may appear absent or inactive to the person holding the device while still operating.
Executive priority
Prioritize this analytic where Android devices support business operations, privileged access, sensitive communications, or regulated workflows. Leaders should ask whether mobile security monitoring can prove when an app hides or reduces its user-facing presence and whether the SOC can correlate that with continued activity. This is a control-validation issue for mobile security, identity access risk, compliance evidence, and incident decision-making: if visibility changes and background activity are not retained in telemetry, responders may underestimate mobile device exposure or miss policy violations.
Technical view
For Android, validate whether telemetry can correlate three elements from the official analytic description: application visibility or user-facing presence changes, continued execution or privileged framework activity after the visibility reduction, and follow-on behavior such as background network communication, sensor access, or persistence-related state transitions. The analytic depends on sequence and causality, not a single event. SOC and detection teams should test whether launcher component disablement, icon suppression, reduced discoverability, background execution, framework activity, network communication, sensor access, and persistence-related state changes are observable with timestamps and application identity sufficient for correlation. No ATT&CK tactic or relationship context was supplied, so local mapping to incident playbooks and escalation criteria is required.
Likely telemetry
- Android application/package state and component visibility changes
- Launcher component enablement or disablement events where available
- Mobile device management or enterprise mobility management application inventory and compliance records
- Application execution and background activity indicators
- Privileged framework or system service activity associated with an application
Detection direction
- Validate correlation logic across a causal chain: reduced application visibility followed by continued or increased operational activity.
- Tune for legitimate cases where applications intentionally reduce launcher presence, run background services, or change components as part of updates, device management, accessibility, or enterprise workflows.
- Require application identity consistency across visibility, execution, network, sensor, and persistence telemetry to avoid weak correlations.
- Look for blind spots where mobile telemetry captures inventory but not runtime activity, or runtime activity but not launcher/component visibility changes.
- Confirm retention and timestamp quality are sufficient to reconstruct the sequence during incident response.
Mitigation priorities
- Establish an approved baseline for Android applications that are allowed to run without normal user-facing visibility.
- Use mobile management controls to maintain application inventory, configuration state, and compliance posture for managed Android devices.
- Limit unnecessary application permissions, especially those involving sensors, background activity, and privileged access, according to business need.
- Ensure incident response procedures include mobile app visibility changes and background activity review, not only installed-app lists.
- Retain mobile telemetry long enough to support compliance evidence and post-incident reconstruction.
Analyst notes and limits
This object is a MITRE ATT&CK mobile detection analytic for Android. Its practical value is in validating whether defenders can correlate visibility reduction with continued operation and follow-on activity. The supplied object has no tactics, no relationships, and no official detection implementation, so the take emphasizes coverage validation, telemetry requirements, and response questions rather than a specific detection rule.
The assessment is limited to the supplied official STIX fields, the MITRE external reference, and the absence of relationship context. No active exploitation, threat actor attribution, concrete impact, or guaranteed detection coverage is implied. Local Android management architecture, available telemetry, privacy constraints, and approved application behavior determine whether this analytic is feasible and how it should be tuned.
Analytic 1715
Correlates (1) changes to application visibility or user-facing presence such as launcher component disablement, icon suppression, or reduced discoverability, (2) continued application execution or privileged framework activity after that visibility reduction, and (3) follow-on behavior such as background network communication, sensor access, or persistence-related state transitions. The defender observes a causal chain where an application becomes less visible to the user while retaining or increasing operational activity.
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.1 | Current bundle | 0d5bd84ed20c… |
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 AN1715Open 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.