Mobile T1407 Download New Code at Runtime is an app that passes store review clean and then fetches and executes code that was never in its package, turning a harmless-looking app into malware after installation. MITRE ATT&CK for Mobile v20 lists it under Defense Evasion for Android and iOS, and states its main purpose plainly: to evade static analysis and pre-publication scans in official app stores. It is the reason "it came from the official store" is not a full answer in an investigation. This guide is for mobile security engineers, app vetting teams, MDM administrators and SOC analysts: how the technique works on each platform, what the platform and store rules already block, how to detect the download and load sequence, and how to respond. For the matrix overview see the MITRE ATT&CK for Mobile Guide.
Key takeaways
- Both major stores forbid it. Google Play policy bars downloading executable code (dex, JAR, .so) from anywhere but Google Play; Apple Guideline 2.5.2 bars downloading code that introduces or changes app features.
- The platform narrows it. Apps targeting Android 10 cannot execve files in their home directory, and apps targeting Android 14 must mark dynamically loaded files read-only.
- Interpreted code is the gap. Store rules exempt code running in an interpreter such as JavaScript in a WebView, which is how Bread and TERRACOTTA delivered functions.
- Detect the sequence. ATT&CK's Android analytic pairs an unchanged app version in MDM with code loaded from a network download.
- Vet over time, not once. A store app that is clean at install can become a dropper on the next server-side change.
How T1407 works on Android and iOS
ATT&CK describes T1407 as downloading and executing dynamic code not included in the original application package after installation. It has no sub-techniques. The closest Enterprise behaviour is the T1105 Ingress Tool Transfer Defensive Guide, but on mobile the point is evading app review rather than moving tools.
- Android: ATT&CK lists native code, Dalvik code, and JavaScript using the WebView JavascriptInterface capability. Variants recorded include multi-stage droppers that install further APKs (Mandrake, BRATA, eSurv), modules loaded into the running app (HenBox, EventBot, CHEMISTGAMES) and WebView JavaScript served by the operator (Bread, TERRACOTTA via eval).
- iOS: ATT&CK notes dynamic code can be downloaded and executed through third-party libraries such as JSPatch. Recorded iOS examples include YiSpecter, which used private APIs to download and install further components and other malicious apps, and ZergHelper, which tried to extend its capabilities by dynamic code updates.
Procedure examples and what they teach
| Software | Platform | Behaviour as ATT&CK records it | Lesson |
|---|---|---|---|
| Judy (S0325) | Android | Bypassed Google Play protections by downloading its payload at runtime after installation | Store review is a point-in-time check |
| Triada (S0424) | Android | Used a backdoor in a Play Store app to install further trojanised apps from the C2 server | Watch for installs initiated by apps, not users |
| SharkBot (S1055) | Android | Downloads the full malware after initial compromise | A small, clean first stage is common in banking malware; see the Android Banking Trojans Guide |
| Bread (S0432) | Android | JavaScript in WebViews loaded functions from an operator-controlled URL | Interpreter exemptions are a real path; inspect WebView bridges |
| Anubis (S0422), Cerberus (S0480) | Android | Download attacker-specified APKs; update payload modules on command | Malware-as-a-service families update features from C2 |
| YiSpecter (S0311) | iOS | Used private APIs to download and install other components and apps | Private API use is a vetting red flag on iOS |
| ZergHelper (S0287) | iOS | Attempted dynamic code updates to extend capabilities | Apps that change behaviour after review break Guideline 2.5.2 |
Prevention: platform, store and enterprise controls
| Layer | Android | iOS |
|---|---|---|
| ATT&CK M1006 Use Recent OS Version | Apps targeting API level 29 (Android 10) cannot execve files in the app home directory; apps targeting Android 14 must mark dynamically loaded DEX, JAR or APK files read-only or the system throws an exception | Code signing enforcement means downloaded native code cannot run outside a signed bundle; keep devices on a current release |
| Store policy | An app may not download executable code (dex, JAR, .so) from a source other than Google Play; code in a VM or interpreter with indirect API access, such as JavaScript in a WebView, is exempt | Guideline 2.5.2: apps may not download, install or execute code which introduces or changes features or functionality; 4.7 allows HTML5 and JavaScript mini apps that the developer is responsible for, and 4.7.2 bars exposing native APIs to them without permission |
| Platform scanning | Google Play Protect scans all installed apps daily, wherever they came from | App Review before distribution |
| Enterprise | Block unknown sources; restrict which apps hold the install unknown apps permission; managed Google Play only | App Store and Apple Business Manager only; restrict enterprise and profile-based app installs |
For your own apps, the OWASP MASVS-PLATFORM category covers WebView use, and the Android Developers guidance on Android 14 recommends avoiding dynamic code loading wherever possible. See the Android App Security Guide and the iOS App Security Guide.
Detection with MDM, MTD and forensics
ATT&CK v20 detection guidance for Android correlates three signals: the MDM app version is unchanged while code is loaded from the network (so it is not a legitimate update), a DexClassLoader, System.load or WebView javascript call loads content that came from a download, and network logs show the download. For iOS it relies on application vetting of entitlements and Info.plist usage keys plus secure web gateway and per-app VPN data.
- New packages without user action: on Android 14 and later company-owned devices, SecurityLog TAG_PACKAGE_INSTALLED records each install with the package name, version code and user ID. A new package shortly after a non-store app runs is a dropper signal.
- Process to APK mapping: TAG_APP_PROCESS_START records the SHA-256 of the base APK. A process whose hash is unknown to your vetting service needs triage.
- Network: downloads of APK, DEX, JAR, .so or large JavaScript bundles to an app whose declared backend does not include that host. Android network logging gives DNS and connect events; per-app VPN gives flows on both platforms.
- MTD: dynamic analysis engines that detect runtime code loading and apps that install other apps.
- Re-vetting: re-run dynamic analysis of business-critical third-party apps periodically, since server-side changes are invisible to version checks.
- Forensics: on suspected targeted cases, MVT checks iOS backups, filesystem dumps and sysdiagnose archives, and Android backups, against indicator sets. See the Mobile Spyware Infection Response Playbook.
How to implement
- Set a minimum OS: enforce current major versions so the Android 10 and 14 restrictions apply to most apps, and record exceptions.
- Restrict install paths: block unknown sources and the install unknown apps permission on managed Android devices; restrict non-store app installs on iOS. Run in report-only mode first to find business dependencies.
- Collect the logs: forward SecurityLog and network logs from company-owned Android devices; enable per-app VPN or a secure web gateway for high-risk groups on both platforms.
- Write the correlation: new package installed or executable content downloaded, with no MDM version change, from an app outside the catalogue. Tune on a pilot ring before alerting fleet-wide.
- Respond: remove the parent app and every package it installed, block its hosts, check the fleet for the same hashes, and revoke tokens the apps could reach. Rollback for a false positive is restoring the app from the managed store.
Decision guidance
- Allow WebView-heavy apps: hybrid apps legitimately load remote JavaScript. Accept them from known publishers; scrutinise those that expose a JavascriptInterface bridge to sensitive APIs.
- Feature flags and over-the-air updates in your own apps: configuration is fine; shipping new executable logic outside the store breaks store rules and your own integrity guarantees.
- Small organisations: app source restriction and Play Protect cover most commodity droppers. Larger organisations add log correlation, MTD and periodic re-vetting.
Where identity fits
Downloaded modules run with the parent app's identity and permissions, including any OAuth tokens or API keys it holds. A dropper in a trusted app therefore inherits its access. Keep high-value tokens in hardware-backed storage, bind them to the app with attestation, and revoke them when an app is found loading external code. See the Mobile App Attestation guide.
Detection and measurement
- Share of devices on OS versions where the Android 10 and 14 restrictions apply to all managed apps.
- Apps holding the install unknown apps permission on managed devices (target zero outside approved tools).
- Packages installed without a matching managed store install event, per month.
- Third-party business apps re-vetted in the last quarter.
- Median time from detection to removal of a dropper and its children.
Framework mapping
| Framework | Reference | Relevance to T1407 |
|---|---|---|
| MITRE ATT&CK Mobile | M1006 Use Recent OS Version | Listed mitigation |
| NIST SP 800-53 Rev 5 | CM-11 User-installed Software; CM-14 Signed Components | Install path and code signing |
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection; SI-7(15) Code Authentication | Detect and block unsigned or changed code |
| NIST CSF 2.0 | PR.PS-05, DE.CM-09 | Prevent unauthorised software, monitor runtime |
| ISO/IEC 27001:2022 Annex A | A.8.19 Installation of software on operational systems; A.8.7 Protection against malware | Software installation and malware control |
Common failure patterns
- Trusting the store badge: Judy and Triada both reached users through Google Play before downloading malicious code.
- Vetting the version, not the behaviour: the app version never changes when the payload arrives from a server.
- Leaving install permissions open: one app with the install unknown apps permission is enough for a dropper chain.
- Ignoring WebView bridges: remote JavaScript plus a JavascriptInterface is a code delivery channel.
- Removing only the parent app: child packages and their tokens stay behind.
Practitioner checklist
- Enforce minimum OS versions on both platforms.
- Block unknown sources and audit the install unknown apps permission.
- Keep Play Protect on and monitor its verdict.
- Collect TAG_PACKAGE_INSTALLED, TAG_APP_PROCESS_START and network logs on company-owned Android.
- Alert on executable downloads with no MDM version change.
- Re-vet business-critical third-party apps periodically.
- Avoid dynamic code loading in your own apps; follow MASVS.
- On response, remove child packages and revoke inherited tokens.
Standards and references
- MITRE ATT&CK: Download New Code at Runtime (Mobile T1407)
- Google Play Console Help: Device and Network Abuse policy
- Apple: App Review Guidelines
- Android Developers: Behavior changes in Android 10
- Android Developers: Behavior changes in Android 14
- Android Developers: SecurityLog
- Google: Google Play Protect
- OWASP: Mobile Application Security Verification Standard
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile App Security Guide · Mobile Malware Guide · Mobile Device Management Security Guide