T1661: Application Versioning
An adversary may push an update to a previously benign application to add malicious code. This can be accomplished by pushing an initially benign, functional application to a trusted application store, such as the Google Play Store or the Apple App Store. This allows the adversary to establish a trusted userbase that may grant permissions to the application prior to the introduction of malicious code. Then, an application update could be pushed to introduce malicious code.[1]
This technique could also be accomplished by compromising a developer’s account. This would allow an adversary to take advantage of an existing userbase without having to establish the userbase themselves.
Analyst context for executives and security teams
Application Versioning is a mobile supply-chain risk: an app can appear benign long enough to gain user trust and permissions, then receive an update that adds malicious code. For leaders, the practical issue is not just malware detection; it is whether the organization can see which mobile apps changed, which permissions they already held, and whether mobile policy can contain risky updates on Android and iOS devices.
Executive priority
Prioritize this where mobile devices access corporate data, regulated information, banking or payment workflows, or executive communications. The business decision is whether mobile governance can prove control over app sources, update behavior, OS currency, and enterprise policy enforcement. Because MITRE provides no tactic or native detection text for T1661, leadership should ask for evidence of mobile inventory, app-version tracking, permission review, and incident response playbooks for a trusted app that becomes untrusted after an update.
Technical view
For SOC, detection engineering, and IR teams, validate coverage around Android and iOS application update events rather than only initial installation. ATT&CK relates this technique to DET0652, but the supplied object does not include detection logic, so teams should map local telemetry to changes in app version, provenance, permissions, and post-update behavior. Relationship context also links mitigation to recent OS versions and enterprise policy via EMM/MDM. SharkBot is listed as Android software using this technique, so Android monitoring should be specifically validated, while iOS remains in scope because the technique platform list includes iOS.
Likely telemetry
- Mobile app inventory with application name, package/bundle identifier, installed version, install source, and update timestamp
- EMM/MDM records for allowed apps, blocked apps, managed/unmanaged status, and policy compliance
- Permission state before and after application updates, especially permissions granted before malicious code is introduced
- Mobile OS version and patch level for Android and iOS devices
- App store or enterprise app distribution records where available
Detection direction
- Validate that detections evaluate application updates and version changes, not only first-time installs.
- Tune for material changes after an update, such as new or expanded permissions, changed application behavior, or unexpected policy violations.
- Correlate app-version changes with device risk, OS version, and EMM/MDM compliance state.
- Account for false positives from legitimate feature releases that require new permissions; require review context rather than blocking every update automatically.
- Use the DET0652 relationship as a prompt to implement or review an application-versioning detection strategy, but do not assume coverage because ATT&CK detection details are not supplied here.
Mitigation priorities
- Keep Android and iOS devices on recent OS versions where feasible, consistent with M1006, because newer mobile operating systems can add security architecture improvements and patches.
- Use enterprise policy through EMM/MDM, consistent with M1012, to manage allowed application sources, application approval, update behavior, and device compliance.
- Maintain mobile app inventories and review processes for applications with sensitive permissions or access to corporate data.
- Define an incident response path for removing, blocking, or containing an app that becomes risky after an update.
- For organization-controlled developer accounts, protect publishing access and monitor for unauthorized changes, since the ATT&CK description notes developer account compromise as one way this behavior can occur.
Analyst notes and limits
This object is a mobile ATT&CK technique for Android and iOS. ATT&CK does not specify tactics for the object and does not provide official detection text. The relationship set includes one detection strategy, two mitigations, and one Android software example, SharkBot. The external references frame this as a mobile supply-chain threat and include a public case description of an Android application changing behavior over time.
This take is limited to the supplied ATT&CK fields, external references, and relationships. It does not assert current exploitation, customer exposure, guaranteed detection, or attribution. Local device management architecture, app store controls, mobile telemetry retention, and whether devices are corporate-owned or BYOD will determine practical coverage.
Application Versioning
An adversary may push an update to a previously benign application to add malicious code. This can be accomplished by pushing an initially benign, functional application to a trusted application store, such as the Google Play Store or the Apple App Store. This allows the adversary to establish a trusted userbase that may grant permissions to the application prior to the introduction of malicious code. Then, an application update could be pushed to introduce malicious code.[1]
This technique could also be accomplished by compromising a developer’s account. This would allow an adversary to take advantage of an existing userbase without having to establish the userbase themselves.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Groups, software, and campaigns
S1055: SharkBot
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 5c562432b74f… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
android_app_breaking_bad
Stefanko, L. (2023, May 23). Android app breaking bad: From legitimate screen recording to file exfiltration within a year. Retrieved August 28, 2023.
Open source URL -
[2]
NIST Mobile Threat Catalogue SPC-20Open source URL
-
[3]
mitre-attack T1661Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.