DC0123: Application State
Application State represents the operational status and lifecycle context of a mobile application at a given point in time. This includes whether the application is running in the foreground or background, its activity state, recent user interaction, and transitions between lifecycle states.
Monitoring application state helps defenders identify suspicious behavior where an application performs sensitive actions while inactive, in the background, or without recent user interaction.
Application state is particularly useful when detecting malicious activity that occurs outside normal user-driven workflows.
Examples Android
- Application transitions from foreground to background - Application running as a background service - Application started via broadcast receiver - Application launched automatically after device boot
iOS
- Application entering active, inactive, or background state - Background task execution - Background fetch activity - Application wake events triggered by push notifications or system services
Data Collection Measures - Mobile EDR / MTD runtime monitoring - OS lifecycle event telemetry - Application runtime instrumentation - Mobile security platform behavioral monitoring
Analyst context for executives and security teams
Application State is mobile telemetry that shows whether an app is active, inactive, in the foreground, running in the background, launched at boot, or awakened by system events. Its business value is context: it helps distinguish user-driven mobile activity from behavior occurring when the user is not actively interacting with the app, which can matter for mobile fraud, privacy, data access, and incident triage.
Executive priority
Treat this as a mobile security visibility requirement, not a standalone control. Leaders should ask whether managed detection, mobile threat defense, or application instrumentation can prove when sensitive app behavior occurred relative to user interaction and lifecycle state. This supports incident decision-making, compliance evidence for mobile data handling, and prioritization of mobile EDR/MTD coverage where mobile applications handle regulated, identity, financial, or operationally sensitive data.
Technical view
For SOC, detection engineering, and IR teams, Application State should be used to add lifecycle context to mobile behavioral alerts. Validate whether telemetry can show foreground-to-background transitions, background service execution, launch after device boot, broadcast-receiver starts, active/inactive/background states, background tasks, background fetch, and wake events from push notifications or system services. Because no official detection logic or ATT&CK relationships are supplied, this data component should be treated as supporting context for suspicious mobile activity rather than a complete detection by itself.
Likely telemetry
- Mobile EDR / Mobile Threat Defense runtime monitoring
- Mobile OS lifecycle event telemetry
- Application runtime instrumentation
- Mobile security platform behavioral monitoring
- Foreground and background transition events
Detection direction
- Confirm that mobile monitoring captures app lifecycle transitions with timestamps precise enough to correlate with sensitive actions.
- Tune detections for sensitive behavior occurring while an app is inactive, backgrounded, automatically launched, or lacking recent user interaction.
- Use application state as correlation context with other mobile behavioral telemetry rather than as a sole indicator of maliciousness.
- Account for legitimate background activity such as background fetch, push-notification wake events, system services, and expected mobile app workflows to reduce false positives.
- Identify blind spots where MTD, OS telemetry, or app instrumentation cannot observe lifecycle events for managed or unmanaged devices.
Mitigation priorities
- Prioritize visibility first: ensure mobile EDR/MTD, OS lifecycle telemetry, or application instrumentation can collect application state events for relevant mobile apps and devices.
- Define normal lifecycle behavior for high-risk mobile applications, especially those handling identity, financial, regulated, or operational data.
- Require incident response playbooks to preserve and review mobile lifecycle context when investigating suspicious app activity.
- Use collected application state evidence to support compliance and audit narratives around mobile monitoring and sensitive-data access controls.
- Where telemetry is sparse, document residual risk and decide whether additional mobile security tooling or app instrumentation is justified.
Analyst notes and limits
The supplied ATT&CK object is a data component in the mobile ATT&CK domain. It provides examples for Android and iOS lifecycle states, but the Platforms field is not specified and no relationships or official detection are provided. The practical value is strongest when correlated with other telemetry showing what the application did during each state.
No official detection, tactics, platforms, relationships, threat actors, software, campaigns, or active exploitation context were supplied. Local app behavior, mobile management scope, device ownership model, and telemetry availability are required to determine coverage and risk.
Application State
Application State represents the operational status and lifecycle context of a mobile application at a given point in time. This includes whether the application is running in the foreground or background, its activity state, recent user interaction, and transitions between lifecycle states.
Monitoring application state helps defenders identify suspicious behavior where an application performs sensitive actions while inactive, in the background, or without recent user interaction.
Application state is particularly useful when detecting malicious activity that occurs outside normal user-driven workflows.
Examples Android
- Application transitions from foreground to background - Application running as a background service - Application started via broadcast receiver - Application launched automatically after device boot
iOS
- Application entering active, inactive, or background state - Background task execution - Background fetch activity - Application wake events triggered by push notifications or system services
Data Collection Measures - Mobile EDR / MTD runtime monitoring - OS lifecycle event telemetry - Application runtime instrumentation - Mobile security platform behavioral monitoring
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 | a19521a64ac2… |
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 DC0123Open 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.