Mobile T1474 Supply Chain Compromise: Detection and Prevention for Android and iOS Fleets

A phone can arrive compromised, or receive a trusted app that was poisoned before it was ever signed, and no user action is needed for either. MITRE ATT&CK for Mobile tracks this as T1474 Supply Chain Compromise, an Initial Access technique that applies to both Android and iOS. ATT&CK v20 splits it into three sub-techniques: compromised development tools and dependencies, compromised hardware, and compromised software distribution or system images. This guide covers each one with the real cases ATT&CK records, what the operating systems already enforce, what an enterprise can detect through MDM and mobile threat defence (MTD) telemetry, and how app teams protect their own build and publishing credentials. It is for mobile security engineers, endpoint and MDM administrators, and app security leads. For the matrix as a whole, start with the MITRE ATT&CK for Mobile Guide; this page goes deeper on one technique.

Key takeaways

• Three different supply chains, three different owners. T1474.001 is your developers' toolchain and SDKs, T1474.002 is the device hardware, and T1474.003 is firmware, pre-installed apps and app update channels.
• Platform integrity checks are the first line. ATT&CK maps M1001 Security Updates to this technique and M1004 System Partition Integrity (keep Verified Boot on) to T1474.003, and Apple's code signing rules limit which libraries an iOS app can load.
• Buying policy is a security control. Pre-installed malware such as Triada and Adups reached users through the device production chain, so approved models and sourcing channels matter as much as app policy.
• Detection works on change against a baseline. ATT&CK's analytics for T1474 look for a known app that, after an update, requests new permissions, contacts new destinations or uses new protected APIs.
• Developer accounts and signing keys are non-human identities worth protecting. CHEMISTGAMES spread as updates after attackers took over legitimate developers' Google Play accounts.

How T1474 works on mobile

ATT&CK describes T1474 as manipulating products or delivery mechanisms before a final consumer receives them. The listed stages include development tools, development environments, source repositories, open source dependencies, update and distribution mechanisms, system images, replaced software builds, counterfeit products and shipment interdiction. ATT&CK notes that on mobile, popular open source dependencies and in particular third-party advertising libraries are attractive targets because one compromise reaches every app that embeds them.

The technique is the mobile counterpart of the Enterprise technique covered in MITRE ATT&CK T1195 Supply Chain Compromise. The difference on phones is who controls the trust anchors: Google, Apple and device makers sign the operating system, app stores review and sign distribution, and the enterprise mostly influences what is bought, what is allowed to install and what is watched.

T1474.001: poisoned toolchains and SDKs

The reference case is XcodeGhost. Palo Alto Networks Unit 42 reported in 2015 that trojanised installers of Xcode 6.1 to 6.4 were shared through a Chinese cloud file service and linked from developer forums. The extra code sat in Xcode's default framework search path, so every iOS app built with the tainted copy linked it in, and the resulting apps sent device and app details to attacker servers over HTTP. Unit 42 confirmed that at least two of those apps passed App Store review. The lesson is that the developer's environment sits upstream of every store control: the app was correctly signed by a real developer and still carried the payload.

The same pattern applies on Android through Gradle and Maven dependencies, and on both platforms through advertising, analytics and crash reporting SDKs. An SDK runs with the full permissions of the host app, so a malicious or compromised SDK inherits access to anything the app's users have granted.

• Install toolchains only from the publisher: Xcode from Apple, Android Studio and SDK tools from Google, and check code signing integrity of installed tools, as Unit 42 advised.
• Pin and review dependencies: lock files, checksum or signature verification, and a review step for every new or changed SDK. The Maven Central and Gradle Supply Chain Security Guide covers the Android build side.
• Keep a software bill of materials for every release: so that when an SDK is reported as malicious you can find every affected build within hours. See the SBOM Guide.
• Test behaviour, not only code: run each release through dynamic analysis and compare network destinations and permission use with the previous version, which is what ATT&CK's detection analytics describe.

T1474.002: compromised hardware

ATT&CK v20 lists no mobile procedure examples for hardware supply chain compromise, and the only mitigation it maps is M1001 Security Updates, on the basis that updates may improve integrity checks. In practice the enterprise controls are procurement controls: buy approved models through authorised channels, record serial numbers and IMEIs at receipt, enrol devices into management through zero-touch or automated enrolment so that a device that has been opened and re-provisioned stands out, and retire models that no longer receive security updates. Hardware tampering at scale is hard to detect on the device itself; ATT&CK's analytic for this sub-technique relies on anomalies at activation, such as privileged or telephony access from system context before setup completes, observed through MTD, proxy or forensic data. The Hardware Trojans and Chip Supply Chain Guide covers the wider hardware problem.

T1474.003: system images, pre-installed apps and update channels

This is the sub-technique with the most recorded mobile cases, and most of them are on Android, where many device makers and their subcontractors build system images.

• Triada: Google's Android security team reported in 2019 that Triada was added to system images by a third-party vendor during production, after a device maker sent its image out for extra features such as face unlock. The later variant was a backdoor in the Android framework that could run code inside other apps and install apps through the Google Play context without enabling unknown sources. Google removed known samples with Play Protect, worked with device makers on over-the-air updates, and added Triada indicators to its Build Test Suite scans of system images.
• Adups: ATT&CK records that Adups software was pre-installed on Android devices from some vendors.
• Allwinner: a Linux kernel distributed by Allwinner reportedly contained a simple backdoor that could give root access, believed by ATT&CK's source to have been left in by mistake.
• Stealth Mango: ATT&CK notes that in at least one case it may have been installed through physical access to a device at a repair shop, a reminder that repair and refurbishment are part of the supply chain.
• CHEMISTGAMES: distributed as updates to legitimate apps after attackers compromised the developers and gained access to their Google Play developer accounts.

On iOS, Apple signs the operating system and requires all executable code to be signed with an Apple-issued certificate. Apple's platform security guide states that at launch the system checks the signature of every dynamic library a process links against, and allows only platform libraries or libraries with the same 10-character team identifier as the app. That narrows the room for a swapped library, but it does not help when the developer's own build is poisoned, as XcodeGhost showed. On Android, Android Verified Boot builds a chain of trust from a hardware root through the bootloader to the boot, system and vendor partitions, and its rollback protection stops a device being returned to an older, vulnerable version. Verified Boot confirms that the image is the one the manufacturer signed; it cannot tell you the manufacturer's image was clean, which is why Triada passed it. The Pre-Installed Apps and Bloatware Security Guide covers how to assess and disable unwanted system apps.

Prevention controls by platform

Android and iOS are listed alphabetically. Each row describes what the platform provides and the setting or decision the enterprise owns.

For the management side, see the Android Enterprise Security Guide and the iOS and iPadOS Enterprise Security Guide.

Detection and measurement

ATT&CK v20's detection strategies for T1474 and its sub-techniques use the same evidence on both platforms: application inventory and state from management, permission and entitlement review from app vetting, runtime behaviour from dynamic analysis, and network metadata from a proxy or secure web gateway where one is deployed. They treat MDM state queries as periodic observations rather than real-time events.

Useful measures: percentage of fleet on models still receiving security updates; percentage of devices reporting Verified Boot or OS integrity as compliant; time from a public malicious SDK or pre-install report to a list of affected devices and apps; share of your own app releases with an SBOM and a behavioural diff; and number of developer and store accounts protected by phishing-resistant MFA. If spyware-grade compromise is suspected on a specific device, the Mobile Verification Toolkit (MVT) and the Mobile Spyware Infection Response Playbook cover forensic triage.

Rolling it out

1. Inventory: list device models, OS versions, sourcing channels and enrolment methods; list your own apps with their SDKs.
2. Set compliance baselines: require OS integrity, supported OS versions and blocked unknown sources, in report-only mode first so you see the impact before blocking access.
3. Tighten procurement: approved model list with update support dates, authorised resellers, automated enrolment, receipt checks and a rule for repaired devices to be wiped and re-enrolled.
4. Secure the app pipeline: publisher-only toolchains, dependency pinning, SBOM per release, dynamic behavioural diff before each store submission.
5. Protect publishing identities: see the next section.
6. Enforce and monitor: move compliance from report to block in rings, alert on permission and destination changes after updates, and keep a rollback path such as reverting a managed app to its previous approved version.

Where identity fits

The software supply chain of a mobile app runs on non-human identities: store developer accounts, App Store Connect and Google Play API keys used by CI, upload and signing keys, and the service credentials SDKs carry. CHEMISTGAMES shows what happens when a developer's store account is taken over: the attacker's code ships as a legitimate update to existing users. Treat these as privileged credentials: hardware-backed MFA for store accounts, separate CI API keys with the narrowest role, keys held in a managed secrets store rather than on build agents, rotation after any staff or vendor change, and alerts on new releases outside the release process. See Secrets in mobile apps for credentials that end up inside the app itself.

Framework mapping

Common failure patterns

• Trusting the signature as proof of safety: Verified Boot and code signing prove origin, not intent; Triada and XcodeGhost both shipped properly signed.
• Buying devices from any reseller without model approval: Triada reached users because a device maker outsourced system image work to a third party, a risk the buyer only controls by choosing makers and channels.
• No SBOM for in-house apps: when an SDK is reported as malicious, teams cannot say which releases contain it.
• Store accounts protected by a shared password: one phished developer login lets an attacker push an update to every user.
• Repaired devices returned straight to users: a device that has been out of your custody should be wiped and re-enrolled.
• Keeping devices past their update window: M1001 only works while the maker still ships updates.

Practitioner checklist

• Publish an approved device model list with security update end dates and authorised sources.
• Enrol all corporate devices through zero-touch or Automated Device Enrollment.
• Require OS integrity, locked bootloader and supported OS versions in compliance policy.
• Block unknown sources on Android and untrusted enterprise developer approval on iOS.
• Wipe and re-enrol any device returned from repair or found outside custody.
• Install Xcode, Android Studio and SDKs only from the publisher and verify their signatures.
• Produce an SBOM and a permission and network behaviour diff for every app release.
• Protect store developer accounts and CI publishing keys with hardware MFA and least privilege.
• Alert when a managed app gains new permissions or destinations after an update.

Standards and references

• MITRE ATT&CK: Supply Chain Compromise (Mobile T1474)
• MITRE ATT&CK: Compromise Software Dependencies and Development Tools (T1474.001)
• MITRE ATT&CK: Compromise Software Supply Chain (T1474.003)
• Android Open Source Project: Verified Boot
• Apple: App code signing process in iOS and iPadOS
• Google: Google Play Protect
• Google Security Blog: PHA Family Highlights, Triada
• Palo Alto Networks Unit 42: XcodeGhost modifies Xcode and infects iOS apps

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · MITRE ATT&CK T1195 Supply Chain Compromise · Pre-Installed Apps and Bloatware Security Guide · Mobile Device Management Security Guide · Secrets in mobile apps