Mobile T1544 Ingress Tool Transfer: Detecting Command and Control Channels on Mobile Devices

The app that passes store review is often only a loader: the modules, configuration and overlay pages that do the damage arrive later over the command and control channel. MITRE ATT&CK for Mobile records this as T1544 Ingress Tool Transfer, a Command and Control technique listed for Android and iOS. ATT&CK maps no mitigations to it, so defenders rely on store policy, platform code-signing rules, network visibility and app vetting. This guide covers what ATT&CK records on both platforms, how Android and iOS limit downloaded code, what MDM, MTD and network logs can show, and how to measure coverage. It is for mobile security engineers, SOC analysts and app vetting teams.

Key takeaways

• Both platforms appear in ATT&CK. Android families such as SharkBot and Chameleon, and the iOS campaign Operation Triangulation and LightSpy, are recorded retrieving further stages or files from the C2.
• Not only code moves. ATT&CK records configuration files (CherryBlos), HTML overlay pages (Chameleon) and additional APKs (GodFather), alongside modules loaded into memory (TriangleDB).
• Store rules forbid it for apps. Google Play policy says an app may not download executable code such as dex, JAR or .so files from outside Play; Apple's Guideline 2.5.2 says apps may not download, install or execute code that changes their features.
• Network evidence is your best live signal. Android Enterprise network logging records DNS lookups and TCP connections per package on fully managed devices and work profiles.
• Detect the download-then-write pair. ATT&CK's DET0718 alerts when an app writes a newly retrieved binary, archive, native library, DEX, script or opaque payload soon after fetching it from a non-CDN source.

What T1544 covers on mobile

ATT&CK describes the technique as transferring tools or other files from an external system onto a compromised device to enable follow-on actions, either through the C2 channel or over another protocol such as FTP. As of ATT&CK v20.1 it is listed for Android and iOS with no sub-techniques and no mitigations. It is close to T1407 Download New Code at Runtime, a Defense Evasion technique that focuses on evading store review with code fetched after install; T1544 is the transfer itself, whatever is transferred. It mirrors Enterprise T1105; see the T1105 Ingress Tool Transfer Defensive Guide for the desktop view, and the MITRE ATT&CK for Mobile Guide for the matrix.

Procedure examples from ATT&CK

The transferred item decides the risk. Configuration and overlay pages change what an installed banking trojan targets without any new code; new stages and modules change what the app can do. The iOS examples involve exploit-based campaigns rather than store apps, which is why OS updates and Lockdown Mode matter more on iOS than app vetting alone.

Platform and store controls

Prevention

1. Restrict install sources. On Android Enterprise devices block unknown sources and use managed Google Play. GodFather's APK downloads show why sideloading permission is a key control.
2. Keep OS versions current. ATT&CK mitigations M1001 Security Updates and M1006 Use Recent OS Version reduce the exploit paths that iOS campaigns such as Triangulation used to stage further code.
3. Offer Lockdown Mode. For iOS users at risk of targeted spyware, Lockdown Mode reduces message and web attack surface. See the Commercial Spyware Guide.
4. Control egress for managed traffic. Route work profile or managed app traffic through a per-app VPN or secure web gateway that can block uncategorised and newly registered domains.
5. Check your own apps and SDKs. Confirm no SDK downloads executable code at runtime; Google lists this as a policy violation even when the app developer did not write it. See the Android App Security Guide.

Detection and measurement

ATT&CK's DET0718 Detection of Ingress Tool Transfer correlates permission state, managed app state and file creation evidence. On Android the analytic looks for an app writing a newly retrieved binary, archive, native library (.so), DEX or script into its files or cache directories or shared storage shortly after a network retrieval from a non-CDN source. On iOS it looks for a managed app writing a container-local file, dylib-like resource or opaque payload after a download from a non-CDN source. It warns not to infer payload content from management state alone.

• Network logging (Android): DevicePolicyManager.setNetworkLoggingEnabled() on a device owner (Android 8.0 and later) or work profile owner (Android 12 and later, work profile traffic only). Each DnsEvent and ConnectEvent carries the package name. Android notes UDP is not logged and apps making direct system calls or using fixed IPs may be missed, so treat it as partial.
• Baseline destinations: for each managed app, record expected domains; alert on new domains, raw IP connections and FTP use.
• App vetting: in dynamic analysis, flag apps that fetch and write DEX, .so or script files after first launch, or use class loaders on downloaded content.
• MTD and DNS: combine on-device agent alerts with protective DNS on managed traffic. See the Mobile Threat Defense Buyer's Guide.
• Forensics: MVT checks iOS backups, filesystem dumps and sysdiagnose files, and Android backups, against published indicators. See the Mobile Verification Toolkit (MVT) guide.

Metrics:

• Percentage of corporate-owned Android devices and work profiles with network logging collected in the SIEM.
• Percentage of managed apps with a documented destination baseline.
• Number of devices allowing installs from unknown sources.
• Percentage of app releases and SDK updates checked for runtime code download.
• Percentage of iOS devices on the current major version and latest security update.

Where identity fits

Transferred configuration often tells malware which banking or enterprise apps to target and where to send stolen credentials. On your side, mobile backends should not let a single static API key embedded in the app fetch configuration or code; use app attestation and per-install credentials so a cloned or modified client cannot pull resources. See the Mobile App Attestation guide.

Common failure patterns

• Relying on store review alone. ATT&CK's examples show apps fetching overlays, configuration and further stages after install, outside what review saw.
• No network visibility on corporate devices. Network logging is available on fully managed devices and work profiles but is often left off.
• Allowing unknown sources for convenience. Once sideloading is allowed, downloaded APKs can be installed with a single user tap.
• Ignoring third-party SDKs. SDKs that download code put your own app in breach of store policy and create the same risk.
• Delaying iOS updates for high-risk users. Exploit-based staging on iOS depends on unpatched devices.

Framework mapping

Practitioner checklist

• Block unknown sources on managed Android devices and work profiles.
• Enable network logging where you own the device or work profile and send it to the SIEM.
• Baseline expected destinations for each managed app and alert on new ones.
• Add runtime code download checks to app vetting and to your own SDK reviews.
• Enforce current iOS and Android versions through MDM compliance.
• Offer Lockdown Mode to high-risk iOS users.
• Use app attestation and per-install credentials on mobile backends.

Standards and references

• MITRE ATT&CK: T1544 Ingress Tool Transfer (Mobile)
• MITRE ATT&CK: T1105 Ingress Tool Transfer (Enterprise)
• Google Play: Device and Network Abuse policy
• Apple: App Review Guidelines
• Apple Platform Security: Security of runtime process in iOS, iPadOS and visionOS
• Android Developers: Network activity logging
• Google: Play Protect client protections
• Apple Support: About Lockdown Mode

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Malware Guide · Android Banking Trojans Guide · Mobile Device Management Security Guide · Mobile Spyware Infection Response Playbook