Mobile ATT&CK Execution Tactic: How Malicious Code Runs on Android and iOS and How to Stop It

An attacker who reaches a phone still has to get code running inside a tightly sandboxed operating system, and the Execution tactic (TA0041) in MITRE ATT&CK for Mobile covers how that happens. ATT&CK v20 defines the tactic as the adversary "trying to run malicious code" and notes that execution techniques are usually paired with techniques from all other tactics. On mobile the list is short: native code, scheduled jobs, the Unix shell and exploits in client apps. This hub explains each of them, how they chain with delivery and privilege escalation, which signals MDM, mobile threat defence (MTD) and app vetting can produce on Android and iOS, and the controls that matter most. It is written for mobile security engineers, app security teams and MDM administrators. Each technique has its own deep page linked from the table below.

Key takeaways

• Four techniques, one sub-technique. ATT&CK for Mobile v20 lists T1575 Native API, T1603 Scheduled Task/Job, T1623 Command and Scripting Interpreter (with T1623.001 Unix Shell) and T1658 Exploitation for Client Execution under TA0041.
• Native code is the most common procedure. T1575 has 10 linked software entries in v20 plus Operation Triangulation, ahead of T1623.001 Unix Shell with 7.
• Exploitation is rare but severe. T1658 has only LightSpy, Pegasus for iOS and Operation Triangulation in v20, yet it is how zero-click chains start running code with no user action.
• Shell access depends on debugging or root. MITRE maps M1002 Attestation and M1010 Deploy Compromised Device Detection Method to T1623, because powerful shell use needs a rooted or jailbroken device or an enabled debug bridge.
• Execution is a pivot, not an end. All 19 software entries that use an execution technique in v20 also use Discovery and Collection techniques, so blocking or spotting execution early limits everything after it.

What execution means on a phone

On a desktop, execution usually means launching a binary or script. On Android and iOS, any installed app already runs code, so the question is how adversary code runs beyond what the app review and sandbox intended. ATT&CK for Mobile describes four routes:

• Native code (T1575, Android): using the Native Development Kit and the Java Native Interface to run compiled C or C++ code. Android's own NDK guidance says most apps do not need it and it exists for performance or to reuse existing libraries, so malware uses it to hide logic from Java-level analysis. It also sits under Defense Evasion.
• Scheduled jobs (T1603): using platform scheduling such as Android WorkManager, which ATT&CK notes wraps JobScheduler, GcmNetworkManager and AlarmManager, to run code at set times or conditions. It is also a Persistence technique.
• Shell and interpreters (T1623, T1623.001): Android is UNIX-like and includes a basic shell reachable through the Android Debug Bridge (ADB) or Java's Runtime package. ATT&CK notes that commands needing elevated privileges only work on a rooted or jailbroken device.
• Client exploitation (T1658): exploiting a flaw in a client app, such as a messaging, browser or media component, to run code. In Operation Triangulation, Kaspersky describes a malicious iMessage attachment exploiting a TrueType font flaw (CVE-2023-41990) with no visible sign to the user.

Event Triggered Execution (T1624) sounds related but sits under Persistence in v20, and Download New Code at Runtime (T1407) sits under Defense Evasion; see Mobile T1624 Event Triggered Execution and Mobile T1407 Download New Code at Runtime. For the full matrix, see the MITRE ATT&CK for Mobile Guide.

Every technique in the tactic

All current (not revoked or deprecated) techniques and sub-techniques with the execution phase in the ATT&CK for Mobile v20 dataset. Counts are distinct software (malware or tool) and campaign objects with a "uses" relationship; DET is the v20 detection strategy.

Mitigation names in v20: M1001 Security Updates, M1002 Attestation, M1010 Deploy Compromised Device Detection Method, M1011 User Guidance.

Where to start: ranked for defenders

1. T1658 Exploitation for Client Execution. Few procedures, highest consequence: it needs no user action in zero-click chains and leads straight to privilege escalation. The defence is patch speed plus Lockdown Mode for people at high risk. See the Zero-Click Exploits Guide.
2. T1575 Native API. Used by banking and spyware families in v20 including Asacub, Chameleon, GodFather, HenBox, TERRACOTTA and LightSpy. It is where app vetting needs to look hardest, since native libraries hide logic from bytecode analysis.
3. T1623.001 Unix Shell. AbstractEmu, DoubleAgent, HenBox, Sunbird and Tiktok Pro use it in v20. Its power depends on root or debugging access, so it is largely controlled by attestation and by disabling USB debugging on managed devices.
4. T1603 Scheduled Task/Job. Chameleon, GodFather, GPlayed, TERRACOTTA and Tiktok Pro use it in v20. Scheduling APIs are legitimate and common, so this technique is mostly detected through dynamic analysis of an app already under suspicion.

How it chains with other tactics

Method: 19 of the 129 software entries in ATT&CK for Mobile v20 that use any technique use at least one technique carrying the execution phase. All 19 also use Discovery and Collection techniques; 17 use Defense Evasion, 16 Command and Control, 12 Credential Access, and 11 each Impact, Initial Access and Persistence.

The pattern to note is that execution is rarely the first or last step. It follows delivery (see Mobile T1660 Phishing and Mobile T1476 Deliver Malicious Application via Other Means) and feeds escalation and collection.

Detection priorities

The v20 detection strategies for this tactic (DET0717, DET0707, DET0655, DET0607 and DET0629) follow the same mobile model as the rest of the matrix: correlate application vetting and instrumented dynamic analysis with Android Enterprise or Apple MDM state, and treat device state as periodic observations rather than live process events.

For forensic triage, see the Mobile Verification Toolkit (MVT); for building integrity checks into your own apps, see Mobile App Attestation.

Metrics that show coverage

• Vetting depth: share of catalogue apps that received dynamic analysis, not only a static scan.
• Debugging exposure: number of managed Android devices with USB or wireless debugging enabled, target zero outside developer groups.
• Patch latency: days from an Apple security release or Android security bulletin to 90 percent fleet adoption.
• Integrity failures handled: share of integrity failures that led to quarantine within an agreed time.
• Sideload exposure: managed Android devices allowed to install from unknown sources.

Prevention and hardening

• Disable debugging on managed devices: Android's ADB documentation shows that USB debugging is turned on in Developer options, which are hidden by default, and that wireless debugging exists from Android 11. On fully managed and work profile devices, apply the EMM restriction that blocks debugging features (Android's DISALLOW_DEBUGGING_FEATURES user restriction) except for developer groups.
• Keep the ADB key prompt meaningful: ADB requires the user to unlock the device and accept a computer's RSA key. Tell users never to accept that prompt on an unfamiliar computer or charging station, and revoke stored authorisations when devices change hands.
• Close sideloading and curate apps: most execution in v20 comes from apps the user installed; a managed catalogue with vetting removes most of it. See APK sideloading.
• Patch client apps and the OS quickly (M1001): Apple says it does not disclose security issues until fixes are available, so treat every release as urgent for exposed components such as messaging and browser engines.
• Lockdown Mode for targeted users: it blocks most message attachment types and complex web technologies, the surfaces most used by T1658 chains. It needs iOS 16 or later and blocks new MDM enrolment while on.
• Gate access on attestation (M1002, M1010): require device integrity before releasing corporate data so rooted or jailbroken devices, where shell execution is powerful, are excluded.

Rollout order

1. Report on debugging state, sideloading permission and patch level across the fleet.
2. Apply the debugging and sideloading restrictions to a pilot ring; keep a named developer group exempt.
3. Turn on attestation-based conditional access in report-only mode, then enforce.
4. Extend dynamic vetting to every new catalogue app and every major update; roll back individual app approvals rather than the policy.

Decision guidance

• BYOD fleets: you cannot restrict debugging on the personal side, so rely on work profile separation, app protection policies and integrity checks in work apps.
• Corporate-owned fleets: fully managed mode lets you disable debugging, block unknown sources and enforce update deadlines, which removes most of this tactic's easy routes.
• App developers: keep native code to what you need, ship it from your own build pipeline with integrity checks, and avoid running shell commands from app code. See the Mobile WebView Security Guide for a related client-side execution surface.

Where identity fits

Code that runs inside a work app's context can use that app's tokens and stored credentials. Store tokens in hardware-backed keystores, bind them to the device where the platform allows, and revoke them when the device fails integrity. See the Mobile Device Security Guide for the device baseline.

Common failure patterns

• Static-only app vetting: native libraries and code downloaded after install are invisible to a manifest and bytecode scan.
• Debugging left on after setup: devices staged with USB debugging enabled keep an execution path open.
• Slow messaging and browser patching: T1658 targets exactly the components that update with the OS.
• Allowing rooted devices for convenience: on a rooted device the shell can do almost anything, and T1623 controls stop working.
• Vetting once: droppers change behaviour after an update or a remote configuration change.

Framework mapping

Practitioner checklist

• Disable developer options and debugging on managed Android devices outside developer groups.
• Block installation from unknown sources on managed devices.
• Vet every catalogue app with dynamic analysis, including native libraries, and re-vet on update.
• Enforce OS and app update deadlines, with messaging and browser components treated as urgent.
• Require device integrity for access to corporate data.
• Offer Lockdown Mode and a consensual forensic check to high-risk users.
• Revoke tokens from any device found rooted, jailbroken or running unvetted code.

Standards and references

• MITRE ATT&CK: Execution, Mobile (TA0041)
• NIST: SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise
• Android Developers: Android Debug Bridge (adb)
• Android Developers: Get started with the NDK
• Android Developers: Play Integrity API integrity verdicts
• Apple: About Lockdown Mode
• Kaspersky Securelist: Operation Triangulation, the last (hardware) mystery
• Amnesty International Security Lab: Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide, Mobile ATT&CK Privilege Escalation Tactic, Mobile ATT&CK Command and Control Tactic, Mobile Malware Guide, Spyware and Stalkerware Guide.