AN1837: Analytic 1837
Correlates (1) application registration or activation of broadcast receivers tied to system or app-generated intents, (2) event-triggered execution while the application is not in the foreground, and (3) immediate follow-on actions such as network communication or data access. The defender observes a causal chain where an external event (e.g., BOOT_COMPLETED, SMS_RECEIVED, USER_PRESENT, CONNECTIVITY_CHANGE) triggers application execution that bypasses normal user-driven lifecycle expectations, followed by background processing or outbound activity.
Analyst context for executives and security teams
This analytic is about spotting Android apps that wake up and act because of system or app events, rather than because a user opened them. That matters because background execution after events such as boot, SMS receipt, user unlock, or connectivity changes can create persistence, covert processing, or unexpected outbound activity. For leaders, the practical question is whether mobile telemetry can show the full chain: event trigger, app activation while not foregrounded, and immediate follow-on behavior such as network communication or data access.
Executive priority
Prioritize this where Android devices are part of business operations, regulated workflows, executive mobility, or cyber-physical processes. The decision value is not simply detecting a receiver registration; it is validating whether the organization can prove which apps execute in the background, why they executed, and what they did next. This supports mobile incident response, compliance evidence around device activity, and risk decisions about managed versus unmanaged Android endpoints.
Technical view
SOC and detection teams should validate whether Android telemetry can correlate three elements: broadcast receiver registration or activation tied to system or application-generated intents; execution when the application is not in the foreground; and near-term follow-on actions such as outbound network activity or data access. Because no official detection logic or tactic mapping is supplied, teams should treat this as a detection design pattern rather than a ready rule. The core engineering challenge is causal correlation across lifecycle state, intent events, and subsequent behavior.
Likely telemetry
- Android application lifecycle and foreground/background state events
- Broadcast receiver registration or activation evidence
- System or app-generated intent events such as BOOT_COMPLETED, SMS_RECEIVED, USER_PRESENT, or CONNECTIVITY_CHANGE
- Process or application execution events following an external trigger
- Network connection or outbound communication records from the activated app
Detection direction
- Validate that telemetry preserves event ordering closely enough to prove the trigger-to-execution-to-action chain.
- Tune for applications executing while not in the foreground immediately after relevant intents, followed by network communication or data access.
- Avoid treating all broadcast receiver use as suspicious; legitimate Android apps may use receivers for normal notifications, connectivity handling, or startup tasks.
- Review false positives around enterprise agents, messaging apps, device management tools, accessibility-related apps, and communication applications that legitimately respond to system events.
- Identify blind spots on unmanaged Android devices or telemetry sources that capture app inventory but not lifecycle state, intent activation, or follow-on behavior.
Mitigation priorities
- Establish mobile visibility requirements for Android devices that handle business data, including app execution state and network activity where feasible.
- Use mobile application governance to review apps requesting background execution patterns or receiver behavior that is unnecessary for business use.
- Apply least-privilege and managed-device controls for apps with access to sensitive data, messaging, or network resources.
- In incident response playbooks, include checks for event-triggered background execution and immediate outbound or data-access activity.
- For compliance readiness, document whether mobile telemetry can support reconstruction of app behavior after system or user events.
Analyst notes and limits
AN1837 is a mobile ATT&CK detection analytic for Android. Its value is in correlation: a receiver or intent event alone is weak, but receiver activation plus non-foreground execution plus immediate follow-on network or data activity is more decision-useful. Local baselining is important because many legitimate applications rely on Android broadcasts and background processing.
The supplied ATT&CK fields provide an official description but no official detection logic, tactics, relationships, mitigations, data components, or associated techniques. This take therefore avoids claims about exploitation, attribution, impact, or guaranteed coverage. Practical detection depends on the organization’s Android management model and available mobile telemetry.
Analytic 1837
Correlates (1) application registration or activation of broadcast receivers tied to system or app-generated intents, (2) event-triggered execution while the application is not in the foreground, and (3) immediate follow-on actions such as network communication or data access. The defender observes a causal chain where an external event (e.g., BOOT_COMPLETED, SMS_RECEIVED, USER_PRESENT, CONNECTIVITY_CHANGE) triggers application execution that bypasses normal user-driven lifecycle expectations, followed by background processing or outbound 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 | 59ef3e0a0242… |
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 AN1837Open 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.