Mobile ATT&CK Persistence Tactic: Finding and Removing Footholds on Android and iOS

A mobile implant that cannot survive a reboot has to compromise the device again, so persistence decides whether one successful attack becomes weeks of surveillance. In MITRE ATT&CK for Mobile, Persistence (TA0028) covers any access, action or configuration change that gives an adversary a lasting presence on a device, and ATT&CK notes that attackers may need to survive reboots and potentially even factory data resets. ATT&CK v20 holds eight techniques and two sub-techniques under the tactic, split between app-level mechanisms that any installed app can abuse and system-level changes that need a rooted or jailbroken device, plus one account-level technique that needs no malware at all. This hub ranks them by the procedure data, explains how each family is found and removed, and covers the MDM, mobile threat defence, attestation and forensic controls that matter. It is written for mobile security engineers, incident responders, SOC analysts and MDM administrators. For the whole matrix, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Broadcast receivers are the workhorse. Broadcast Receivers (T1624.001) has 22 recorded software or campaign uses in the v20 Mobile dataset, nearly three times the next technique, Compromise Client Software Binary (T1645) with 8.
• Persistence comes in three depths. App-level (receivers, scheduled jobs, foreground services) is removed by uninstalling the app; system-level (boot scripts, modified binaries, runtime hijacking) survives a factory reset; account-level (Linked Devices, T1676) survives a new phone entirely.
• Integrity controls cover the dangerous half. ATT&CK maps Attestation (M1002), Lock Bootloader (M1003) and System Partition Integrity (M1004) to the system-level techniques, which makes Verified Boot state and attestation the key signals.
• Several techniques are Android only. Foreground Persistence, Compromise Application Executable, Event Triggered Execution and Hijack Execution Flow list Android as their only platform in v20; iOS persistence in the record relies on exploits and jailbreak-level changes.
• Remediation depth must match persistence depth. Uninstall for app-level, reflash or replace for system-level, and unlink sessions plus credential reset for account-level.

What Persistence means on a phone

Mobile operating systems kill background apps aggressively, restart often and give users an easy factory reset. Persistence techniques work around those three facts. An ordinary app with no special privilege can register to be woken by system events, schedule recurring work, or keep itself alive with a foreground service. An adversary with root or a jailbreak can go further and alter the system partition, boot scripts or the runtime itself, which is why ATT&CK's tactic description mentions surviving a factory reset. A third route skips the device: by adding an adversary-controlled device to the user's messaging account, access persists wherever the account goes.

Three techniques carry a second tactic in v20. Foreground Persistence (T1541) is also Defense Evasion, Scheduled Task/Job (T1603) is also Execution, and Linked Devices (T1676) is also Collection.

Every Persistence technique in ATT&CK v20

Method: counts are distinct malware, tool, group and campaign objects with a non-revoked "uses" relationship to the technique in mobile-attack-20.0.json; sub-technique uses are counted separately from the parent. The depth column is NHI Mgmt Group's grouping, based on ATT&CK's descriptions, of what a removal has to reach.

Where to start: ranked techniques for defenders

1. T1624.001 Broadcast Receivers: the most used and the easiest to review. Android 8.0 (API 26) restricted most implicit broadcasts for manifest-declared receivers, but BOOT_COMPLETED, LOCKED_BOOT_COMPLETED and SMS_RECEIVED_ACTION remain exempt, which is why malware such as AhRat registers for boot completion and banking trojans listen for incoming SMS. App vetting should flag boot and SMS receivers in apps with no business reason for them.
2. T1645, T1398 and T1625.001, system-level changes: fewer entries but the hardest to remove. Examples include Pegasus for Android and iOS, Monokle and BusyGasper for modified binaries, OldBoot for boot script changes, and Dvmap and Zen for runtime hijacking. These need root, so a locked bootloader, Verified Boot and attestation checks are the controls that matter.
3. T1676 Linked Devices: two entries, both state-linked. ATT&CK records Sandworm Team linking Signal accounts from devices captured on the battlefield and Star Blizzard linking WhatsApp accounts. Google Threat Intelligence Group reported Russian-aligned Signal targeting in February 2025, and Microsoft reported in January 2025 on a Star Blizzard WhatsApp campaign seen in November 2024 (sources below).
4. T1541 Foreground Persistence and T1603 Scheduled Task/Job: abuse of normal background APIs. Since Android 9, idle background apps lose sensor access, so spyware uses a foreground service to keep the camera or microphone; Android 14 requires a declared foreground service type and matching permission. WorkManager jobs persist across reboots. On iOS, the BGTaskScheduler framework (iOS 13 and later) lets the system run registered tasks while an app is suspended.
5. T1577 Compromise Application Executable: repackaging or modifying installed apps. ATT&CK names Agent Smith, BOULDSPY and YiSpecter. The Janus flaw (CVE-2017-13156) let attackers modify APKs signed only with the v1 scheme and was fixed in the 2017-12-01 Android security patch level; APK Signature Scheme v2 (Android 7.0) protects the whole file.

How Persistence chains with the rest of the matrix

Counting the tactics used by the 42 entities that have a Persistence procedure in v20: Defense Evasion 35, Collection 33, Discovery 32, Command and Control 27, Impact 23, Credential Access 20, Initial Access 17, Privilege Escalation 12, Execution 11 and Exfiltration 11. The most common techniques used alongside persistence are Software Discovery (T1418, 24 entities), SMS Messages (T1636.004, 23), Obfuscated Files or Information (T1406, 23) and System Information Discovery (T1426, 22).

• Commodity chain: a sideloaded app (see the Mobile ATT&CK Initial Access Tactic) registers boot and SMS receivers, schedules work, and hides behind obfuscation. Persistence lives inside the app, so uninstalling it ends the foothold.
• Root chain: an exploit or rooting component (see the Mobile ATT&CK Privilege Escalation Tactic) modifies system binaries or init scripts. The 12 entities that combine Privilege Escalation with Persistence are the ones a factory reset may not clean.
• Exploit-only iOS chain: research on LightSpy for iOS described boot persistence through a launch daemon plist, while noting that a rootless jailbreak does not survive a reboot. For iOS, many implants re-exploit after restart instead, which is why a reboot is a useful, if partial, step for high-risk users.
• Account chain: phishing or physical access to an unlocked phone links a new device to Signal or WhatsApp; the account then leaks messages regardless of the handset's state.

Detection priorities and telemetry

ATT&CK v20 attaches a detection strategy to every Persistence technique and sub-technique. The practical sources are below.

See the Mobile App Attestation guide and the Mobile Verification Toolkit (MVT) guide.

Metrics

• Share of managed devices reporting a green Verified Boot state and a passing attestation verdict.
• Time from an attestation or root alert to conditional access quarantine.
• Number of managed apps declaring boot receivers or exact alarm permissions, reviewed against business need.
• Share of high-risk users whose messaging linked devices were reviewed in the last quarter.
• Reinfection rate after remediation, by remediation type (uninstall, reset, reflash, replace).

Prevention and removal across Android and iOS

Removal by depth

1. Triage and preserve: before changing anything, capture what the forensic route needs (backup or sysdiagnose for MVT, MDM inventory, attestation history). See the Mobile Spyware Infection Response Playbook.
2. App-level: remove the app through MDM or by the user, confirm that boot receivers and scheduled work disappear with it, and revoke any permissions or device admin roles it held.
3. System-level: treat any failed attestation or modified system partition as a reflash with a verified factory image, or a device replacement. A factory reset clears user data but does not restore a modified system partition.
4. Account-level: unlink unknown devices in Signal and WhatsApp, reset registration PINs, and review cloud accounts the phone was signed into.
5. Verify: re-check attestation, re-run MVT where indicators exist, and monitor the user's accounts for reuse of stolen sessions.

Where identity fits

Linked Devices is an identity attack: the adversary adds an authenticator-like device to a messaging account and keeps access after the phone is cleaned or replaced. The same pattern applies to cloud accounts synced on the phone, where refresh tokens can outlive the device. Remediation should always pair device work with session revocation and a review of devices registered to the user's identity. See the Mobile Communications Protection for High-Risk Individuals Guide.

Common failure patterns

• Factory reset as the default fix: it removes app-level persistence but not a modified system partition. Check attestation after the reset, and reflash or replace when it fails.
• Allowing unlocked bootloaders for developers on production access: an unlocked bootloader disables the protection that makes system-level persistence detectable.
• Ignoring boot and SMS receivers in app vetting: they are legitimate APIs, so they only stand out when compared with the app's stated purpose.
• Cleaning the phone, not the account: linked messaging devices and synced cloud sessions survive device remediation.
• Assuming iOS persistence means malware is gone after reboot: an implant that re-exploits after restart will return unless the vulnerability is patched.

Framework mapping

For the Enterprise view of the same tactic, see the ATT&CK Persistence Tactic guide.

Practitioner checklist

• Require a locked bootloader and passing hardware attestation for corporate access, and alert on any change.
• Collect Verified Boot state from SecurityLog on fully managed Android devices.
• Vet managed apps for boot receivers, SMS receivers, foreground service types and exact alarms against business need.
• Block untrusted installs on Android and enterprise app trust on supervised iOS.
• Keep devices on supported OS versions and recent security patch levels.
• Define remediation by depth: uninstall, reflash or replace, and account unlink.
• Review Signal and WhatsApp linked devices for high-risk users and in every mobile incident.
• Pair device remediation with session and token revocation for the user.
• Offer Lockdown Mode or Android Advanced Protection and MVT triage to high-risk users.

Standards and references

• MITRE ATT&CK: Persistence, Mobile (TA0028)
• MITRE ATT&CK: Mobile Matrix
• Android Open Source Project: Verified Boot
• Android Developers: Implicit broadcast exceptions
• Apple Platform Security: Signed system volume security
• Google Threat Intelligence Group: Signals of Trouble, Russia-aligned targeting of Signal
• Microsoft Threat Intelligence: Star Blizzard spear-phishing campaign targets WhatsApp accounts
• Amnesty International Security Lab: Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide, Mobile ATT&CK Exfiltration Tactic, Android Enterprise Security Guide, Mobile Malware Guide.