Mobile T1624 Event Triggered Execution: Finding Malicious Broadcast Receivers on Android

Mobile malware rarely needs the user to open it twice: it registers for system events such as boot completion, screen unlock or an incoming SMS, and the operating system starts it again every time those events fire. MITRE ATT&CK for Mobile tracks this as T1624 Event Triggered Execution, a Persistence technique with one sub-technique, T1624.001 Broadcast Receivers. ATT&CK v20 lists the technique for Android only. Broadcast receivers are an Android component, so this guide is Android-focused. It is written for mobile security engineers, MDM and MTD administrators, and app vetting teams who need to find and remove these footholds. For the wider matrix, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Boot and unlock events are the classic triggers. ATT&CK procedure examples show BOOT_COMPLETED, USER_PRESENT, SCREEN_ON and SMS intents used by Pegasus for Android, TrickMo, EventBot, SimBad and many others.
• Android 8 narrowed the attack, it did not remove it. Since API level 26, apps targeting Android 8 or higher cannot declare manifest receivers for most implicit broadcasts, but exempt broadcasts and context-registered receivers remain.
• This is mainly a vetting problem. MITRE's detection strategy for T1624.001 points to application vetting and dynamic analysis rather than a live device feed: compare requested receivers against an approved baseline.
• Persistence is usually a symptom. A receiver that relaunches malware after reboot is paired with other techniques, such as accessibility abuse or device admin, so removal must cover the whole app.
• iOS is not listed. Do not invent iOS detections for T1624; spend iOS effort on the techniques ATT&CK does list for that platform.

What T1624 is and how it works on Android

ATT&CK describes T1624 as abusing system mechanisms that trigger execution on specific events, for example receiving an SMS or the device finishing boot. On Android the mechanism is the intent: a message passed between apps and system components. A broadcast receiver is an app component that subscribes to broadcast intents, and the system can deliver them to every registered app.

Android offers two registration models, and they matter for defenders because they leave different evidence.

The context-registered model is why MITRE's detection strategy stresses dynamic analysis: an app can look clean in its manifest and still subscribe to sensitive broadcasts once it is running.

T1624.001 Broadcast Receivers in real campaigns

The table below summarises procedure examples recorded in ATT&CK v20 for T1624.001. They are listed as ATT&CK states them; attribution beyond that is not implied.

ATT&CK also lists parent-level examples: BOULDSPY uses a background service that restarts itself when its parent activity stops, and GodFather executes when victims use their banking apps by redirecting them to a malicious version. FlexiSpy is recorded using root access to set reboot hooks, which overlaps with Mobile T1625 Hijack Execution Flow.

Platform controls that limit the technique

• Android 8.0 (API 26) implicit broadcast limits: per the Android developer docs, apps targeting Android 8.0 or higher cannot use the manifest to declare a receiver for most implicit broadcasts; a small exempt list remains, and context-registered receivers still work while the user is using the app. ATT&CK maps this to mitigation M1006 Use Recent OS Version.
• Android 7.0 (API 24): apps targeting 7.0 or higher must register for CONNECTIVITY_ACTION with registerReceiver(); manifest declaration no longer works.
• Android 13 and 14 export flags: apps targeting Android 14 (API 34) that register context receivers must state RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED. This is a hygiene control for legitimate apps: it stops other apps sending unprotected broadcasts into them, which shrinks the attack surface malware can reuse.
• Android 14 cached-state deferral: the system defers less important broadcasts such as ACTION_SCREEN_ON while an app is cached, which reduces how often a background receiver fires.
• Managed app sources: on Android Enterprise devices, restricting installs to managed Google Play and keeping Google Play Protect on removes most sideloaded apps that carry these receivers. See the Android Enterprise Security Guide.

iOS: ATT&CK does not list iOS for T1624. Third-party iOS apps do not receive system-wide broadcast intents in the Android sense; persistence on iOS appears in other techniques and usually depends on exploitation. For iOS hardening, see the iOS and iPadOS Enterprise Security Guide.

Detection: what to look for and where

MITRE's detection strategy for Broadcast Receivers (DET0711) correlates application vetting and instrumented dynamic analysis evidence: an app that registers a receiver, by manifest or by registerReceiver(), for sensitive system intents such as BOOT_COMPLETED, SMS_RECEIVED, ACTION_PACKAGE_REPLACED, CONNECTIVITY_CHANGE or USER_PRESENT, when the app is not on an approved list. It then alerts on behaviour inconsistent with the app's baseline.

For consensual forensic review of a suspected device, the Amnesty International Security Lab's Mobile Verification Toolkit (MVT) supports Android backups and intrusion logs. See the Mobile Verification Toolkit (MVT) and the Mobile Forensics Guide.

Metrics that show coverage

• Percentage of managed Android devices restricted to managed Google Play or an approved store.
• Percentage of internally vetted apps whose receiver list is compared against an approved baseline.
• Percentage of devices on an OS version that supports current security updates.
• Median time from an MTD or Play Protect high-risk verdict to app removal.
• Number of apps in inventory with boot plus SMS receivers and no documented business need.

How to implement controls, step by step

1. Inventory first: pull the managed app list from the MDM and record install source for every app.
2. Define the approved receiver baseline: for in-house and approved apps, record which sensitive broadcasts each one needs, for example a messaging app and SMS intents.
3. Add receiver checks to app vetting: flag manifest receivers for boot, SMS, package-replaced and connectivity events, and run dynamic analysis to catch registerReceiver() calls.
4. Pilot install-source restrictions on one device group in audit mode where the MDM supports it, then enforce. Roll back by moving the group to the previous policy if line-of-business apps break.
5. Raise minimum OS level through MDM compliance rules so devices benefit from the Android 8 and later broadcast limits and current security patches (M1006 is the ATT&CK mapping; patching is general NHI Mgmt Group advice).
6. Wire MTD and Play Integrity verdicts into conditional access so a high-risk device loses access to corporate apps and tokens until cleaned.
7. Remediate: uninstall the app, revoke and reissue tokens the device held, and reimage if the app also held device admin or root. See the Mobile Spyware Infection Response Playbook.

Where identity fits

A persistent receiver keeps malware alive long enough to read SMS one-time codes and reuse OAuth refresh tokens and API keys stored by other apps. When a device is found with a malicious trigger, treat every token issued to that device as exposed: revoke refresh tokens, rotate any API keys embedded in managed apps, and re-enrol MDM certificates. See the OWASP Mobile Top 10 M1 Improper Credential Usage Guide and the OAuth for Native and Mobile Apps Guide.

Framework mapping

Common failure patterns

• Vetting the manifest only: context-registered receivers never appear there, so static review misses them.
• Treating boot receivers as always malicious: many legitimate apps restart sync after boot. Without an approved baseline, alert fatigue follows and real findings are ignored.
• Removing the app but not the access: tokens, SMS-delivered codes and saved credentials remain valid after uninstall.
• Allowing old OS versions: devices or apps that predate the API 26 limits keep the wide manifest broadcast surface.
• Exported receivers in your own apps: an in-house app that exports a receiver without need gives malware a ready trigger point.

Practitioner checklist

• Restrict Android installs to managed Google Play or approved stores on corporate devices.
• Keep Google Play Protect on and read its verdict through the Play Integrity API in sensitive apps.
• Maintain an approved list of apps allowed to receive boot, SMS and package-replaced broadcasts.
• Run static and dynamic receiver analysis on every app before approval.
• Enforce a minimum Android version and patch level through MDM compliance.
• Set android:exported="false" or RECEIVER_NOT_EXPORTED on receivers in your own apps unless another app must reach them.
• Feed MTD high-risk verdicts into conditional access.
• Revoke tokens and keys held by any device where a malicious receiver is confirmed.

Standards and references

• MITRE ATT&CK: Event Triggered Execution (Mobile T1624)
• MITRE ATT&CK: Broadcast Receivers (Mobile T1624.001)
• Android Developers: Broadcasts overview
• Android Developers: Behavior changes, apps targeting Android 14
• Android Developers: Play Integrity API integrity verdicts
• OWASP: Mobile Application Security Verification Standard
• Amnesty International Security Lab: Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · T1546 Event Triggered Execution Defensive Guide · Android Banking Trojans Guide · Mobile Threat Defense Buyer's Guide