Most mobile malware that reaches a user never passes through an official app store: it arrives as a link in a text message, a file in a chat, or a page made to look like a store. MITRE ATT&CK for Mobile records this as T1476 Deliver Malicious Application via Other Means, an Initial Access technique for both Android and iOS. ATT&CK v20 lists more than thirty procedure examples for it but maps no mitigations or detection strategy, so the controls on this page come from Android and Apple management documentation. It covers the delivery routes ATT&CK records, the specific Android Management API and Apple MDM settings that close them, what to watch for, and how to roll the controls out without breaking legitimate in-house apps. It is for MDM administrators, mobile security engineers and SOC analysts. The MITRE ATT&CK for Mobile Guide gives the wider matrix, and the APK sideloading guide goes deeper on Android install mechanics.
Key takeaways
- Three routes, one goal. ATT&CK lists attachments, links (email, SMS, iMessage, WhatsApp, websites, QR codes) and third-party app stores as the ways an app is delivered outside an authorised store.
- Android managed devices block untrusted installs by default. In the Android Management API, untrustedAppsPolicy defaults to DISALLOW_INSTALL and Play Protect verification defaults to VERIFY_APPS_ENFORCED; the risk is an exception that widens them.
- iOS abuse runs through enterprise certificates and profiles. YiSpecter and ZergHelper abused enterprise or personal signing certificates and XLoader for iOS used a web-hosted device profile; allowEnterpriseAppTrust and allowUIConfigurationProfileInstallation address both.
- Personal devices are the gap. Work profile and user enrolment controls protect the managed side only, so delivery through a personal app still matters when a device also holds work credentials.
- Delivery is usually social engineering first. Pair the technical block with user guidance (ATT&CK M1011) about install prompts, and with smishing reporting.
How T1476 works
ATT&CK v20 defines T1476 as directing victims to download malicious applications in ways that avoid an authorised store such as Google Play or the Apple App Store, for example by downloading an APK directly from a domain. The stated reason is to reduce the chance of detection. Some Android malware also installs further apps itself, either automatically or on command, which ATT&CK records under the same technique for families such as SimBad, Bread, GolfSpy, Pallas and Twitoor.
T1476 sits next to two related techniques. T1660 Phishing covers the lure itself, and T1655 Masquerading covers the fake app name and icon. This page is about the delivery path and the device settings that decide whether the install can happen at all.
Delivery routes ATT&CK records
| Route | Platform | Examples in ATT&CK v20 |
|---|---|---|
| SMS phishing link to an APK or download site | Android | FakeSpy, RuMMS, Asacub, Rotexy (sent as AvitoPay.apk), Tiktok Pro, MazarBOT; Gustuff and Riltok were sent to contacts taken from infected phones |
| Fake store or fake update pages | Android | Red Alert 2.0 used pages made to look like the Play Store; Cerberus was pushed through sites prompting the user to install Adobe Flash Player |
| Fake service and banking sites | Android | NGate was distributed through fake sites mimicking banks and a lottery site |
| Messaging apps and social media | Android | ViceLeaker through Telegram and WhatsApp; Bouncing Golf advertised GolfSpy on social media |
| Third-party app stores and websites | Android | Agent Smith through the 9apps store, HenBox through third-party stores, ViperRAT through third-party websites; Dark Caracal and Windshift through their own or watering hole sites |
| Email attachment | Android | Android/Chuli.A as an attachment to a spearphishing message; Anubis through an email link |
| Enterprise or personal signing certificates | iOS | YiSpecter was signed with Apple-issued enterprise certificates to install on non-jailbroken devices; ZergHelper abused enterprise and personal certificates |
| Device profile from a phishing site | iOS | XLoader for iOS used SMS links to a site hosting a device profile; eSurv could install apps through malicious iOS provisioning profiles |
The pattern is clear: Android cases centre on direct APK installs, and iOS cases centre on persuading the user to trust a certificate or profile, because iOS only runs code signed through Apple's programmes. Apple's platform security guide states that apps from the Apple Developer Enterprise Program need a provisioning profile, apps installed by MDM are implicitly trusted, and other in-house apps need the user to approve the developer in Settings, an approval organisations can block.
Prevention settings by platform
Android and iOS are listed alphabetically. Each platform section names the management setting, its documented default, and what it stops.
Android
Since Android 8.0, the single "Allow unknown sources" setting has been replaced for apps targeting 8.0 by a per-app "Install unknown apps" permission, and administrators block installs with the DISALLOW_INSTALL_UNKNOWN_SOURCES user restriction rather than the old setting. Android's documentation states that managed profiles created on Android 8.0 have that restriction enabled automatically. In the Android Management API the same intent is expressed through advancedSecurityOverrides:
| Setting | Values | Documented default | Use |
|---|---|---|---|
| untrustedAppsPolicy | DISALLOW_INSTALL, ALLOW_INSTALL_IN_PERSONAL_PROFILE_ONLY, ALLOW_INSTALL_DEVICE_WIDE | DISALLOW_INSTALL | Keep DISALLOW_INSTALL on fully managed devices; personal-profile-only is the usual setting for work profile devices |
| googlePlayProtectVerifyApps | VERIFY_APPS_ENFORCED, VERIFY_APPS_USER_CHOICE | VERIFY_APPS_ENFORCED | Keep enforced so Play Protect checks every install |
| installUnknownSourcesAllowed, ensureVerifyAppsEnabled | Deprecated fields | Not applicable | Replace in older policies with the two fields above |
Google states that Play Protect checks apps whatever their source and scans devices daily, which gives some protection even on personal profiles where untrusted installs are allowed. Distribute in-house Android apps through managed Google Play so that no exception to the untrusted apps policy is needed. See the Android Enterprise Security Guide.
iOS and iPadOS
Apple's Restrictions payload (com.apple.applicationaccess) in its official device management schema includes these keys, all of which default to true (allowed):
| Key | Introduced | Supervision | Effect when set to false |
|---|---|---|---|
| allowEnterpriseAppTrust | iOS 9.0 | Not required | Removes the Trust Enterprise Developer button in Settings, so users cannot trust apps signed by enterprise or free developer accounts that MDM did not install; trust granted earlier is not revoked |
| allowUIConfigurationProfileInstallation | iOS 6.0 | Required | Stops users installing configuration profiles and certificates interactively |
| allowMarketplaceAppInstallation | iOS 17.4 | Required | Prevents installing alternative marketplace apps from the web and stops installed marketplaces installing apps |
| allowWebDistributionAppInstallation | iOS 17.5 | Required | Prevents installing apps directly from the web |
Because allowEnterpriseAppTrust does not revoke existing trust, set it before devices reach users or audit trusted developers after applying it. Deliver your own in-house apps through MDM so they are trusted without user approval. Note that Apple's schema says disabling the App Store with allowUIAppInstallation still lets users install through alternative marketplace apps, which is why the marketplace key exists. See the iOS and iPadOS Enterprise Security Guide.
Choosing the right stance
- Corporate-owned, fully managed or supervised: block all off-store installs and profile installs, deliver every business app through managed distribution, and handle exceptions by adding the app to the managed catalogue, not by relaxing the policy.
- Personally owned with a work profile or user enrolment: you cannot block personal installs, and should not try. Keep work data in the managed container, require Play Protect or OS version compliance, and rely on mobile threat defence and conditional access to cut off a device that reports a harmful app.
- High-risk users: add Apple Lockdown Mode or Android Advanced Protection, and give clear guidance never to install apps from links.
- Small organisations: a basic management service that keeps the Android Management API defaults and a supervised iOS baseline covers most of this technique without custom engineering.
Detection and response
Because ATT&CK attaches no detection strategy to T1476, build detection from the evidence each route leaves:
- Install source: MDM and EMM app inventories show every installed package; alert on apps not in the managed catalogue on corporate devices, and on any new enterprise developer trust or configuration profile on iOS.
- Policy drift: alert when a policy changes untrustedAppsPolicy away from DISALLOW_INSTALL, sets VERIFY_APPS_USER_CHOICE, or flips an Apple restriction to true.
- Lure telemetry: SMS and email reports, secure web gateway hits on APK downloads or .mobileconfig files, and DNS lookups to newly registered domains imitating stores, banks or parcel services.
- Device signals: mobile threat defence or Play Integrity results showing a known harmful app, and Play Protect being turned off.
When an off-store app is found: isolate the device from corporate resources through conditional access, preserve the app package and inventory record, remove the app and any profile or trusted certificate it relied on, revoke and reissue tokens and passwords used on the device, and check contacts for onward SMS spreading, as Gustuff and Riltok did. The Mobile Spyware Infection Response Playbook covers deeper triage.
Measures that show progress: percentage of managed Android devices on DISALLOW_INSTALL; percentage of supervised iOS devices with allowEnterpriseAppTrust and allowUIConfigurationProfileInstallation set to false; number of open untrusted app exceptions; count of non-catalogue apps found per month; and time from a smishing report to blocking its domain.
Where identity fits
Off-store malware such as banking trojans is usually after credentials and one-time codes, and on a work device it can reach OAuth refresh tokens and SSO sessions. Treat a confirmed off-store install as a credential exposure: revoke the device's tokens and sessions, require reauthentication, and check for new MFA methods. On the enterprise side, the enterprise developer certificates and provisioning profiles that sign your in-house iOS apps are themselves machine credentials; YiSpecter shows what an abused enterprise certificate enables, so store them in a managed secrets platform with restricted access. See the Mobile Access Credentials guide.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK for Mobile | M1011 User Guidance, M1012 Enterprise Policy | Mobile mitigations that match the controls above; ATT&CK v20 does not map them to T1476 directly |
| NIST SP 800-53 Rev. 5 | CM-7.5, CM-11 | Allow-by-exception software and control of user-installed software |
| NIST SP 800-53 Rev. 5 | AC-19, SI-3 | Mobile device access control and malicious code protection |
| NIST CSF 2.0 | ID.AM-02, PR.PS-02, DE.CM-09 | Software inventory, software maintained and removed with risk, monitoring of devices |
Common failure patterns
- A blanket exception for one in-house APK: setting ALLOW_INSTALL_DEVICE_WIDE to ship one app opens the device to every app; publish it as a private managed app instead.
- Restrictions applied after enrolment on iOS: enterprise developer trust granted before allowEnterpriseAppTrust was set stays in place.
- Relying on App Store blocking alone: Apple's schema notes alternative marketplace apps can still install when the App Store is disabled.
- Ignoring the personal side of BYOD: a banking trojan in the personal profile can still read SMS one-time codes used for work sign-in.
- No reporting path for smishing: without user reports, the first sign of the campaign is a compromised account. See the Vishing and Smishing Guide and the QR Code Phishing (Quishing) Guide.
Practitioner checklist
- Confirm untrustedAppsPolicy is DISALLOW_INSTALL on fully managed Android devices and personal-profile-only on work profiles.
- Confirm googlePlayProtectVerifyApps is VERIFY_APPS_ENFORCED and remove deprecated fields from old policies.
- Set allowEnterpriseAppTrust to false on iOS before devices reach users, and audit existing trusted developers.
- On supervised iOS devices set allowUIConfigurationProfileInstallation, allowMarketplaceAppInstallation and allowWebDistributionAppInstallation to false where business rules allow.
- Deliver every in-house app through managed Google Play or MDM.
- Alert on policy drift and on non-catalogue apps, profiles or certificates.
- Block APK and .mobileconfig downloads at the web gateway for managed traffic, with an exception process.
- Run user guidance on install prompts and give users a one-tap smishing report route.
- Treat any off-store install on a work device as a credential exposure and revoke sessions.
Standards and references
- MITRE ATT&CK: Deliver Malicious Application via Other Means (Mobile T1476)
- Google: Android Management API, enterprises.policies reference
- Android Developers: Android 8.0 behaviour changes
- Apple: Device management schema, Restrictions payload
- Apple: App code signing process in iOS and iPadOS
- Google: Google Play Protect
- MITRE ATT&CK: Phishing (Mobile T1660)
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · APK sideloading · Mobile Malware Guide · Android Banking Trojans Guide · Mobile Device Management Security Guide