AN1711: Analytic 1711
The defender correlates foreground service start or promotion activity with persistent-notification presentation, long-lived application execution, and continued access to while-in-use sensors or network activity outside expected user-driven context. The analytic looks for an application invoking foreground service APIs, sustaining a foreground state longer than expected for its declared role, and retaining camera, microphone, location, or other sensor access while the device is locked, the app lacks recent interaction, or the notification identity/function does not match the application’s behavior.
Analyst context for executives and security teams
This Android mobile analytic matters because it focuses on apps that keep themselves visibly “foregrounded” while continuing to use sensors or network access after normal user context has ended. For leaders, the practical question is whether mobile monitoring can distinguish legitimate long-running app behavior from suspicious persistence around camera, microphone, location, or network use when the device is locked or the user has not recently interacted with the app.
Executive priority
Prioritize this where Android devices are used for sensitive work, regulated operations, executive communications, field activity, or cyber-physical workflows. The decision value is in validating whether mobile security, privacy, and incident response processes can prove when an app is legitimately using foreground services versus retaining access beyond its declared purpose. This supports control assurance, compliance evidence around mobile sensor access, and faster triage when a mobile app behaves outside expected business use.
Technical view
For Android, validate correlation across foreground service start or promotion events, persistent notification presentation, app execution duration, recent user interaction, device lock state, sensor access, and network activity. The analytic is not a standalone signature; it depends on context: whether the app’s notification identity and function match observed behavior, whether the foreground state is unusually long for the app’s declared role, and whether camera, microphone, location, or other sensor access continues outside expected user-driven activity. No ATT&CK tactic mapping, relationship context, or official detection implementation was supplied, so teams should treat this as a detection design pattern to operationalize with local telemetry and baselines.
Likely telemetry
- Android foreground service start or promotion activity
- Persistent notification creation, content, identity, and lifecycle metadata
- Application foreground/background state and long-lived execution duration
- Camera, microphone, location, and other sensor access events
- Device lock state and recent user interaction signals
Detection direction
- Correlate foreground service activity with persistent notifications, long-lived execution, sensor access, device lock state, and lack of recent user interaction rather than alerting on any single event.
- Establish expected behavior by application role so legitimate long-running foreground use is not treated as inherently suspicious.
- Review cases where notification identity or described function does not align with observed camera, microphone, location, sensor, or network behavior.
- Tune for duration, lock-state, and interaction thresholds using local Android fleet behavior; ATT&CK does not provide thresholds in the supplied object.
- Account for blind spots where mobile telemetry does not expose foreground service APIs, notification metadata, sensor access, or user interaction state consistently.
Mitigation priorities
- Inventory Android apps approved for business use and document which apps have a legitimate need for foreground services and sensitive sensors.
- Review and restrict camera, microphone, location, and other sensor permissions according to business need and device role.
- Use mobile device management or mobile security controls, where available, to enforce app approval, permission governance, and visibility into long-running app behavior.
- Define incident response playbooks for suspicious mobile foreground-service behavior, including evidence preservation, app review, permission changes, and device containment decisions.
- Provide compliance-ready evidence that sensitive mobile sensor access is governed, monitored, and reviewed for high-risk user groups or regulated workflows.
Analyst notes and limits
The supplied object is a detection analytic for Android in the mobile ATT&CK domain. Its value is strongest as a correlation and validation pattern for mobile SOC, IR, IAM/mobile governance, and compliance teams. Because no relationships were supplied, this take does not infer associated techniques, malware, campaigns, or adversary procedures.
Official detection content was not provided, and the object has no supplied tactics or relationship context. Practical coverage depends on the organization’s Android telemetry depth, mobile management controls, sensor-access visibility, notification metadata, and ability to baseline expected app behavior. This summary does not assert active exploitation, attribution, or guaranteed detection.
Analytic 1711
The defender correlates foreground service start or promotion activity with persistent-notification presentation, long-lived application execution, and continued access to while-in-use sensors or network activity outside expected user-driven context. The analytic looks for an application invoking foreground service APIs, sustaining a foreground state longer than expected for its declared role, and retaining camera, microphone, location, or other sensor access while the device is locked, the app lacks recent interaction, or the notification identity/function does not match the application’s 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.1 | Current bundle | e011d78cd384… |
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 AN1711Open 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.