Mobile T1577 Compromise Application Executable: Finding and Removing Tampered Apps

When malware modifies an app that is already installed and trusted, the user keeps opening a familiar icon while adversary code runs every time. MITRE ATT&CK for Mobile records this as T1577 Compromise Application Executable, a Persistence technique. This guide explains how ATT&CK describes the technique, what its procedure examples show, which Android signing and update controls block it, how iOS differs, and how to detect and remove tampered apps on managed fleets. It is written for mobile security engineers, endpoint and MDM administrators and incident responders, and builds on the MITRE ATT&CK for Mobile Guide.

Key takeaways

• It is persistence through a trusted app. The adversary changes an installed application so legitimate use triggers malicious code, instead of relying on a separate malicious app the user might notice.
• Signing is the main barrier. Android only installs an update over an existing app when the certificates match, and APK Signature Scheme v2 and later cover the whole file, so most of the technique depends on old vulnerabilities, rebuilt apps or users accepting a different package.
• Patching is the listed mitigation. ATT&CK maps M1001 Security Updates and M1006 Use Recent OS Version; the best-known method, Janus, was fixed in the December 2017 Android security bulletin.
• ATT&CK lists Android only. One procedure example, YiSpecter, also targeted iOS, where Apple requires all executable code to be signed with an Apple-issued certificate.
• Detection is about unexpected replacement. Watch for app binaries written or replaced outside your MDM's authorised update path, and for installer or signer changes in package inventory.

What T1577 covers

ATT&CK describes three routes. First, exploiting device vulnerabilities, the best known being Janus, which allowed extra bytes to be added to APK and DEX files without affecting the file's signature. Second, rebuilding an app: decompiling the genuine application, merging in malicious code and recompiling it. Third, concealing the change and bypassing user consent, for example by making the modification appear as an update or by exploiting vulnerabilities that let malicious activity run inside a system application.

Procedure examples

ATT&CK lists three software entries for this technique, summarised as ATT&CK states them.

For the wider malware families and delivery routes, see the Mobile Malware Guide.

Android: the signing and update model

Android's secure update model is the core control against T1577. Android's documentation states that all APKs must be signed before they are installed or updated, that when the system installs an update it compares the certificates in the new version with those in the existing version, and that the update is allowed only if they match. An app signed with a different certificate must use a different package name and installs as a completely new app.

Janus is CVE-2017-13156, published in the December 2017 Android security bulletin as a high severity elevation of privilege issue affecting Android 5.1.1 through 8.0, fixed at security patch level 2017-12-01. A device at or above that patch level, or any app signed only with v2 or later on Android 7.0 or later, is outside the Janus route. That leaves rebuilt apps, which carry a different signature and therefore have to be installed as a new package or after the user removes the original, and vulnerability-driven routes, which patching closes. For developers, see APK Signing.

Signing keys are the identity behind the control. Because the signing certificate is what Android uses to decide whether an update is genuine, a stolen app signing key turns T1577 into an update that the platform accepts. Android's documentation recommends separate upload and app signing keys, describes Play App Signing, where Google holds the app signing key, and supports key upgrade through the Play Console if a key is compromised. Treat app signing keys as high-value non-human credentials: see the Code Signing Security Guide and the Compromised Code Signing Certificate Playbook.

iOS: how it differs

ATT&CK does not list iOS for T1577. Apple's platform security guide states that iOS requires all executable code to be signed using an Apple-issued certificate, that third-party apps must be validated and signed, and that the system validates the signatures of all dynamic libraries a process links against at launch. App Review Guideline 2.5.2 bars apps from downloading or executing code that changes the features of the app or of other apps. ATT&CK records that YiSpecter abused private iOS APIs, so on managed iOS devices, control which distribution channels are allowed and review any enterprise-signed app on the fleet; see the iOS and iPadOS Enterprise Security Guide.

Prevention on managed devices

• Patch level as an access condition: ATT&CK's M1001 recommends limiting or blocking enterprise access from devices without recent security updates, using security patch level on Android and iOS version on iOS. Set a minimum patch level in your MDM compliance policy and conditional access.
• Retire unsupported devices: M1001 also says to buy devices with a vendor or carrier update commitment and decommission devices that no longer receive updates. M1006 notes that new OS versions often include architecture improvements that block observed adversary techniques.
• Block untrusted installs: on Android Enterprise, keep advancedSecurityOverrides.untrustedAppsPolicy at DISALLOW_INSTALL (the documented default) or ALLOW_INSTALL_IN_PERSONAL_PROFILE_ONLY for work profiles, and googlePlayProtectVerifyApps at VERIFY_APPS_ENFORCED. Rebuilt apps need an install path, and these settings remove the common one. See APK sideloading.
• Disable developer settings: developerSettings at DEVELOPER_SETTINGS_DISABLED (the documented default) removes the ADB install route.
• Distribute apps through the managed channel: push work apps through managed Google Play or Apple's managed distribution so the MDM knows the expected version and source of every app.
• Play Protect: Google Play Protect checks apps at install and periodically, and can disable or remove harmful apps.

Detection

ATT&CK's DET0649 analytic says Android detection comes from management, network or vetting evidence, and that state queries are periodic observations rather than real-time events.

• Baseline the signer: record the signing certificate digest for every approved app; any managed device reporting a different signer for the same package name is a high-priority alert.
• Use MTD: mobile threat defence agents report harmful or repackaged apps and side-loaded packages; route verdicts to the SOC with the device and user identity attached. See the Mobile Threat Defense Buyer's Guide.
• Investigate targeted users properly: for suspected spyware on a specific device, preserve it and follow the Mobile Spyware Infection Response Playbook; MVT can check acquired data against published indicators.

Response and removal

1. Contain: block the device from corporate resources through compliance and conditional access before touching it, so tokens cached by the tampered app cannot be used further.
2. Preserve: for targeted or high-risk users, acquire the device before remediation; a wipe destroys the evidence.
3. Remove: uninstall the tampered app and reinstall from the managed channel; where the system image or a system app is suspected, factory reset or replace the device.
4. Revoke credentials: sign the user out of corporate apps, revoke refresh tokens and re-register MFA methods held on the device; see Mobile Access Credentials.
5. Check the fleet: query package inventory for the same package name with the bad signer or version across all devices.

Measuring it

• Patch compliance: percentage of managed Android devices at or above your minimum security patch level, and iOS devices at or above the minimum version.
• Unsupported devices: count of devices past their vendor update end date that still reach corporate data (target zero).
• Signer coverage: percentage of approved apps with a recorded signer baseline.
• Response time: median time from a tampered app alert to access block and to removal.

Common failure patterns

• Old devices left on the network: phones that stopped receiving updates years ago still sync email, keeping Janus-era routes open.
• Compliance without enforcement: patch level reported in the MDM but not used as a conditional access condition.
• No signer baseline: inventory checks package names and versions only, so a rebuilt app with the same name passes.
• Weak signing key custody: app signing keys stored on build agents or in shared folders, so a stolen key makes a malicious update look legitimate.
• Wiping before preserving: remediating a targeted user's phone before acquiring it, losing the evidence of what was modified.

Framework mapping

Practitioner checklist

• Set a minimum Android security patch level and iOS version as a conditional access condition.
• Decommission devices that no longer receive vendor security updates.
• Keep untrusted app installs blocked and Play Protect verification enforced on every Android Enterprise policy.
• Record the signing certificate digest for every approved app and alert on any mismatch.
• Deliver work apps only through managed Google Play or Apple's managed distribution.
• Protect your own app signing keys as high-value credentials, with separate upload and signing keys.
• Preserve high-risk users' devices before remediation, then revoke tokens and MFA registrations.

Standards and references

• MITRE ATT&CK: Compromise Application Executable, Mobile technique T1577
• Android Open Source Project: Android Security Bulletin, December 2017
• Android Open Source Project: Application signing
• Android Developers: Sign your app
• Apple Platform Security: App code signing process
• Google: Android Management API policy reference
• MITRE ATT&CK: YiSpecter, software S0311
• Google: Use Google Play Protect to help keep your apps safe

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Android Enterprise Security Guide · APK Signing · Mobile Device Management Security Guide