DET0649: Detection of Compromise Application Executable
DET0649 is a mobile ATT&CK detection strategy for identifying compromise of an application executable, linked to Android technique T1577. The business sign...
Analyst context for executives and security teams
DET0649 is a mobile ATT&CK detection strategy for identifying compromise of an application executable, linked to Android technique T1577. The business significance is persistence risk: if a legitimate mobile app is modified, users and support teams may continue to trust and use it while it performs adversary-directed activity. For leaders, the key question is whether the organization can prove the integrity of mobile applications on managed or high-risk Android devices, not merely whether the app name appears approved.
Executive priority
Prioritize this where Android devices support sensitive workflows, privileged access, regulated data, field operations, or operational continuity. The decision value is in validating mobile application integrity controls, incident response readiness for tampered apps, and evidence that approved applications remain trustworthy after installation. Because the ATT&CK object provides no official detection text or platform list of its own, executives should treat this as a coverage validation topic rather than an assurance that existing SOC tooling detects it.
Technical view
SOC, mobile security, and IR teams should validate coverage against the related Android technique T1577: adversaries may modify installed applications to establish persistent access and cause legitimate applications to perform adversary tasks. Practical validation should focus on whether teams can detect changes to application packages, executable contents, signatures, versions, installation source, and post-install integrity state on Android devices. Since DET0649 has no official ATT&CK detection procedure or tactics listed, detection engineering should document local assumptions, telemetry sources, managed-device scope, and what events would trigger triage for suspected application tampering.
Likely telemetry
- Mobile device management or enterprise mobility management inventory for installed Android applications
- Application package metadata such as package name, version, installer/source, signing certificate, and update history
- Mobile threat defense or endpoint security alerts related to application integrity or suspicious app modification
- Device vulnerability and patch posture relevant to application tampering risk
- File or package integrity evidence where available from managed Android devices
Detection direction
- Confirm whether Android app inventory includes enough metadata to distinguish a trusted application from a modified executable using the same name or package identity.
- Tune detections around unexpected signing certificate changes, unauthorized installation sources, anomalous app updates, or integrity mismatches, while accounting for legitimate enterprise app updates and approved sideloading processes.
- Correlate suspected app modification with device vulnerability posture and management status, because unmanaged or poorly instrumented devices may create major blind spots.
- Define triage criteria for when a modified application should be treated as persistence rather than a routine software hygiene issue.
- Use the relationship to T1577 as the technical anchor; the DET0649 object itself does not provide official detection logic.
Mitigation priorities
- Establish an authoritative inventory of approved Android applications and expected signing or integrity properties.
- Restrict or govern unapproved installation sources and sideloading where business requirements allow.
- Maintain Android device patch and vulnerability management processes, especially for issues that could enable application modification.
- Require mobile security monitoring or MDM/EMM controls on devices that access sensitive business systems.
- Prepare IR playbooks for suspected mobile application tampering, including containment, device review, credential risk assessment, and evidence preservation.
Analyst notes and limits
This take is based on the ATT&CK detection strategy DET0649 and its relationship to T1577, Compromise Application Executable, in the mobile domain. The most actionable defensive value comes from the related technique description and Android platform context, not from the detection strategy body, because no official description or detection text was supplied for DET0649.
Platforms and tactics are not specified on the DET0649 object itself, and the object provides no official detection guidance. Android is referenced only through the related T1577 technique. Local device management scope, telemetry availability, application distribution model, and mobile IR procedures must be reviewed before making coverage claims.
Detection of Compromise Application Executable
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 | T1577 | Compromise Application Executable | This object detects Compromise Application Executable. |
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 | 3ede8168c2c6… |
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 DET0649Open 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.