DET0652: Detection of Application Versioning
This detection strategy is about catching risk introduced through mobile application updates: an app that was originally benign can later receive a version...
Analyst context for executives and security teams
This detection strategy is about catching risk introduced through mobile application updates: an app that was originally benign can later receive a version update that adds malicious code. For leaders, the significance is that trust decisions made at initial install time may become stale after updates, especially when users have already granted permissions.
Executive priority
Prioritize this as a mobile application governance and monitoring concern. Security leaders should ask whether the organization can prove which mobile app versions are installed, when they changed, what permissions changed, and whether post-update behavior is reviewed. This matters for incident response scoping, compliance evidence around mobile device controls, and reducing business exposure from trusted apps that become risky later.
Technical view
DET0652 is linked to ATT&CK mobile technique T1661, Application Versioning, affecting Android and iOS. SOC, mobile security, and IR teams should validate whether they can detect version changes for installed mobile apps and correlate those changes with permission changes, app reputation changes, new network behavior, or mobile threat detections. Because the official detection text is not provided, teams should treat this as a validation objective rather than a predefined analytic.
Likely telemetry
- MDM/UEM mobile application inventory, including app name, package or bundle identifier, installed version, and update time
- Mobile device install and update events where available
- Application permission state before and after version updates
- Mobile app vetting or mobile threat defense findings tied to app version
- App store or enterprise app catalog metadata, including publisher and version history
Detection direction
- Validate that app version changes are recorded for managed Android and iOS devices, not just current installed state.
- Tune detections to look for suspicious deltas after an update, such as new sensitive permissions, new risky behavior, or new security verdicts for a previously accepted app.
- Correlate mobile app inventory with app vetting results so analysts can distinguish routine updates from updates that materially change risk.
- Account for false positives from normal app release cycles; version change alone is usually not enough without supporting risk signals.
- Check blind spots for unmanaged devices, personal devices, apps outside enterprise inventory, and telemetry that overwrites historical version data.
Mitigation priorities
- Maintain authoritative mobile app inventory and version history for managed devices.
- Use app approval, allowlisting, or enterprise catalog processes where appropriate to control which mobile apps and versions are acceptable.
- Review permission changes and app security assessments during mobile app update cycles.
- Ensure incident response procedures can scope affected users and devices by app identifier and version.
- Retain mobile management and app security evidence long enough to support investigations and compliance reviews.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy with no official description, detection text, tactics, or platforms listed on the strategy itself. The practical guidance here is derived from its relationship to T1661 Application Versioning, whose related platforms are Android and iOS and whose behavior concerns malicious code introduced through an update to a previously benign app.
This take does not assert active exploitation, attribution, or guaranteed detection. Coverage depends on local mobile management, app inventory retention, app vetting, and device telemetry. Organizations without historical app version and permission data may only be able to assess current exposure, not when risk was introduced.
Detection of Application Versioning
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1661 | Application Versioning | This object detects Application Versioning. |
All related ATT&CK context
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 | 5ed9c7ef66ea… |
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]
mitre-attack DET0652Open 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.