Mobile T1661 Application Versioning: How It Reaches Android and iOS Devices and How to Block It

An app that passed store review and earned its users' trust can turn malicious in a single update, and most users install that update automatically. MITRE ATT&CK for Mobile tracks this as T1661 Application Versioning, listed for Android and iOS under two tactics, Initial Access and Defense Evasion. ATT&CK describes two routes: publishing a benign, functional app to a trusted store such as Google Play or the Apple App Store, building a user base that grants permissions, then pushing an update that adds malicious code; or compromising a legitimate developer's account to push the update to an existing user base. This page covers the public cases, what enterprise app management can do, MITRE's detection analytics and response. For the wider matrix see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Approval is a point in time. An app vetted at version 1.0 is a different app at version 1.3.8; app approval needs to follow updates, not just first install.
• Silent updates are the delivery mechanism. In the case ESET documented, users who updated automatically received the malicious code without any new permission prompt.
• Permissions granted earlier are the prize. The technique works because the app already holds microphone, storage or accessibility access from its benign period.
• Allowlisting is the main enterprise control. ATT&CK's Enterprise Policy mitigation (M1012) is application allowlisting through MDM; Use Recent OS Version (M1006) adds Android app hibernation, which resets permissions of unused apps.
• Developer accounts are non-human attack surface. The second route is a stolen publishing account or signing pipeline, so store console access needs the same protection as production deployment.

Cases

ATT&CK v20 lists no iOS procedure example for T1661, although the technique applies to both stores. Apple's App Store Review Guidelines require new features and product changes to be described specifically in the Notes for Review (2.3.1), forbid apps from downloading or executing code that introduces or changes features (2.5.2), and forbid hidden, dormant or undocumented features (2.5.19). These are store rules enforced by review, not technical guarantees. For banking malware families that use this pattern see the Android Banking Trojans Guide.

How it differs from related techniques

The developer-account route overlaps with Enterprise supply chain compromise; see the MITRE ATT&CK T1195 Supply Chain Compromise guide.

Platform controls on Android and iOS

Android

• Managed Google Play allowlist: on fully managed devices and work profiles, allow only approved apps and control update timing for sensitive apps through the device policy controller. See the Android Enterprise Security Guide.
• App hibernation (M1006): for apps targeting Android 11 or higher that are unused for a few months, the system resets runtime permissions; on Android 12 and higher it also stops background jobs, alerts and push notifications. Android 6.0 to 10 devices with Google Play services have had the permission reset since December 2021. Device policy controllers are never hibernated, and work profile apps are exempt, so this helps most on personal devices.
• Play Protect: scans installed apps daily whatever their source and can disable or remove harmful apps, which covers an app that turns malicious after an update once it is detected.

iOS and iPadOS

• MDM app allowlisting: use supervised devices and managed app distribution so that only approved apps are installed. See the iOS and iPadOS Enterprise Security Guide.
• Privacy permissions: apps must declare usage-description keys for protected resources; an update that adds a new key shows up in app vetting before users see the prompt.

Both platforms

• Permission review: periodically remove permissions apps do not need; see the Mobile App Permissions guide.
• App vetting on update: re-scan approved apps when a new version appears, comparing permissions, entitlements and network destinations with the previous version.

Detection and measurement

ATT&CK v20 detection strategy DET0652 gives one analytic per platform. Both start from an app version change in the MDM inventory and look, within a post-update window (default 24 hours, tightening to 1 hour), for new permissions outside the expected change list or network connections to domains outside the previous version's baseline.

The tunable lists are the work: an expected permission delta per planned update, drawn from the developer's change log and your review, and a per-app domain baseline anchored to the prior version.

Metrics:

• Percentage of managed devices restricted to an approved app list.
• Percentage of app updates re-vetted before or within 24 hours of rollout.
• Updates per month that added permissions or entitlements, and how many were approved.
• Apps removed or blocked after an update review.

Rolling out the controls

1. Inventory: export installed apps and versions from MDM for every managed device.
2. Allowlist: approve the apps the business needs; start in report mode for a few weeks to find what users rely on.
3. Tier apps: for apps with sensitive permissions (microphone, camera, location, accessibility, files), delay updates for a short review window where the MDM supports it.
4. Automate vetting: feed new versions to an app vetting service and alert on permission or destination changes.
5. Enforce: block unapproved apps, with an exceptions process that has an expiry.
6. Rollback: keep the ability to remove a managed app remotely and revert to the previous approved version where your distribution method allows it.

Responding to a malicious update

• Scope: query MDM inventory for the package or bundle ID and the affected versions.
• Remove: uninstall the managed app remotely and add it to the block list.
• Assess data exposure: use the app's granted permissions to decide what may have left the device: audio, files, contacts, location.
• Preserve: keep an acquisition from at least one affected device; see the Mobile Forensics Guide.
• Report: notify the store operator so the app is removed for everyone.

Where identity fits

The developer-account route is a non-human identity problem. Store publishing consoles, API keys used by release pipelines and app signing keys let one compromised credential push code to every user. Google's Play App Signing guidance tells developers to enforce 2-Step Verification for all Play Console users. Restrict console roles, store signing keys in managed key services, and alert on releases from unexpected accounts or pipelines. See the APK Signing guide.

Framework mapping

Common failure patterns

• Vetting only at first approval: the allowlist trusts the app name, not the version.
• Permission creep left unreviewed: permissions granted during the benign period are never revisited.
• Personal devices out of scope: work data reached from an unmanaged personal device inherits every app's update risk.
• Shared or weakly protected developer accounts: for in-house apps, one stolen console login can publish to every employee.

Practitioner checklist

• Restrict managed devices to an approved app list.
• Re-vet sensitive apps on every version change.
• Maintain a per-app expected permission and domain baseline for MITRE's DET0652 analytics.
• Review and remove unneeded app permissions on a schedule.
• Keep app hibernation in effect on personal Android devices.
• Enforce 2-Step Verification and least-privilege roles on your own store developer accounts.
• Keep a tested process to remove a managed app from all devices.

Standards and references

• MITRE ATT&CK: T1661 Application Versioning (Mobile)
• NIST: Mobile Threat Catalogue SPC-20
• Android Developers: App hibernation
• Apple: App Store Review Guidelines
• Google: Play Console Help, Use Play App Signing
• Google: Google Play Protect client protections
• ESET WeLiveSecurity: Android app breaking bad, from legitimate screen recording to file exfiltration

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide, Mobile Malware Guide, Mobile Device Management Security Guide, Mobile App Security Guide.