DET0711: Detection of Broadcast Receivers
DET0711 is a mobile ATT&CK detection strategy tied to Android Broadcast Receivers, a persistence-related behavior where an app can be triggered by device o...
Analyst context for executives and security teams
DET0711 is a mobile ATT&CK detection strategy tied to Android Broadcast Receivers, a persistence-related behavior where an app can be triggered by device or system events such as boot completion, SMS receipt, or other broadcast intents. For leaders, the value is not that ATT&CK provides a complete detection recipe here—it does not—but that mobile security programs should verify whether they can see and assess apps that register for event-driven execution, because that behavior can affect persistence, incident scoping, and mobile device trust decisions.
Executive priority
Prioritize this as a mobile resilience and governance validation item: can the organization identify Android apps that can auto-start or react to sensitive system events, and can SOC/IR teams use that evidence during a mobile incident? This matters for business continuity where Android devices support operations, regulated workflows, executive communications, or field activity. Because the ATT&CK object has no official detection text, leaders should treat this as a coverage gap question rather than proof of existing detection coverage.
Technical view
SOC, mobile security, and IR teams should validate visibility into Android application broadcast receiver registrations and related intent-triggered execution paths. The relationship context supports focusing on T1624.001 Broadcast Receivers on Android. Practical validation should include whether teams can inventory apps that register receivers, distinguish expected app behavior from suspicious persistence-enabling behavior, and preserve this evidence during mobile triage. Since DET0711 does not specify tactics, platforms, or detection logic directly, detection engineering should be anchored to local Android telemetry sources and the related technique context rather than assuming a complete ATT&CK analytic exists.
Likely telemetry
- Android application manifest or package metadata showing registered broadcast receivers
- Runtime registration evidence for broadcast receivers where available
- Mobile device management or mobile threat defense app inventory and app permission/context data
- Device event or security logs showing app execution after system events such as boot completion or SMS-related activity, where collected
- Mobile incident response acquisition artifacts sufficient to review installed apps and receiver behavior
Detection direction
- Validate whether Android apps with broadcast receiver registrations are visible in existing mobile security tooling and incident response workflows.
- Prioritize receivers tied to high-value or sensitive system events, while accounting for legitimate apps that commonly rely on broadcasts for normal functionality.
- Tune review logic around unexpected apps, newly installed apps, sideloaded or unmanaged apps, or apps whose receiver behavior does not match business purpose, using local environment baselines.
- Avoid claiming coverage from DET0711 alone: the official object provides no detection text, so teams need documented local analytics, telemetry sources, and test evidence.
- Use the relationship to T1624.001 to connect findings to mobile persistence investigation playbooks.
Mitigation priorities
- Establish or validate an Android app inventory that includes receiver-related metadata where tooling supports it.
- Restrict unmanaged or untrusted app installation through mobile governance controls where appropriate.
- Ensure mobile incident response procedures include review of broadcast receiver registrations and event-triggered app execution indicators.
- Document acceptable business apps and expected broadcast receiver behavior to support tuning and audit evidence.
- Use findings to inform mobile security policy, app vetting, and risk acceptance decisions rather than relying on ATT&CK metadata alone.
Analyst notes and limits
This take is based on ATT&CK detection strategy DET0711 and its relationship to T1624.001 Broadcast Receivers. The object itself is sparse: no official description, no official detection guidance, no tactics, and no platform listed on the detection strategy. The Android platform and behavior context come from the related technique description.
Coverage and risk cannot be determined from the ATT&CK object alone. Local evidence is required: mobile device mix, Android management posture, app sources, available MDM/MTD/IR telemetry, and whether receiver registration data is actually collected and retained.
Detection of Broadcast Receivers
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1624.001 | Broadcast Receivers Sub-technique | This object detects Broadcast Receivers. |
All related ATT&CK context
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 | 91efc1d67bbe… |
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 DET0711Open 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.