T1577: Compromise Application Executable
Adversaries may modify applications installed on a device to establish persistent access to a victim. These malicious modifications can be used to make legitimate applications carry out adversary tasks when these applications are in use.
There are multiple ways an adversary can inject malicious code into applications. One method is by taking advantages of device vulnerabilities, the most well-known being Janus, an Android vulnerability that allows adversaries to add extra bytes to APK (application) and DEX (executable) files without affecting the file's signature. By being able to add arbitrary bytes to valid applications, attackers can seamlessly inject code into genuine executables without the user's knowledge.[1]
Adversaries may also rebuild applications to include malicious modifications. This can be achieved by decompiling the genuine application, merging it with the malicious code, and recompiling it.[2]
Adversaries may also take action to conceal modifications to application executables and bypass user consent. These actions include altering modifications to appear as an update or exploiting vulnerabilities that allow activities of the malicious application to run inside a system application.[2]
Analyst context for executives and security teams
Compromise Application Executable is a mobile technique where an adversary modifies an installed Android application so a trusted app can perform malicious tasks when used. The business issue is trust in the mobile app estate: if enterprise access depends on unmanaged or outdated Android devices, a user may appear to be using a legitimate application while the executable has been altered.
Executive priority
Prioritize this as a mobile resilience and access-control risk, especially where Android devices can reach enterprise data. Leadership should ask whether mobile access decisions consider OS version, Android security patch level, and device supportability. The ATT&CK mitigations emphasize security updates, recent OS versions, decommissioning unsupported devices, and limiting enterprise access from devices that have not installed recent updates.
Technical view
SOC, IR, and mobile security teams should validate whether they can identify changes to installed application executables, suspicious app replacement or update behavior, and devices with vulnerable or unsupported Android builds. ATT&CK provides no official detection text for T1577, but it does link a detection strategy, DET0649. Relationship context also maps this technique to Agent Smith, YiSpecter, and BOULDSPY, so detection engineering should use those relationships as context for testing mobile telemetry without assuming local exposure.
Likely telemetry
- Android OS version and security patch level from MDM/EMM or equivalent device inventory
- Installed application inventory, package name, version, signer/certificate, and hash where available
- Application install, update, replacement, or sideload events
- Mobile threat defense or device integrity alerts related to tampered applications
- Enterprise access logs that show mobile device compliance state at authentication or resource access time
Detection direction
- Confirm whether mobile monitoring can detect a legitimate application whose executable, APK, DEX content, signer, hash, or version lineage has changed unexpectedly.
- Tune for suspicious app replacement or update-like behavior while accounting for legitimate application updates to reduce false positives.
- Prioritize visibility gaps on unmanaged Android devices, unsupported devices, and devices without recent security patch levels.
- Use the ATT&CK relationship to DET0649 as the primary detection-strategy anchor, but validate details against local telemetry because the technique object itself does not include official detection guidance.
Mitigation priorities
- Enforce timely mobile security updates and track Android security patch level for devices accessing enterprise resources.
- Require recent supported mobile OS versions where feasible, since ATT&CK notes newer versions include patches and security architecture improvements.
- Limit or block enterprise access from devices that have not installed recent security updates.
- Decommission devices that no longer receive vendor or carrier security updates.
- Align procurement and BYOD policy with vendor and carrier commitments to provide prompt security updates for a defined period.
Analyst notes and limits
The supplied ATT&CK object is Android-focused and describes modification of installed application executables through vulnerabilities such as Janus or by rebuilding applications with malicious code. The relationship set identifies Security Updates and Use Recent OS Version as mitigations, and maps the technique to several malware/software entries. For Glexia service planning, this is most useful as a validation point for mobile device compliance, mobile telemetry maturity, and incident response readiness around tampered applications.
Official ATT&CK detection text is not provided, tactics are not specified, and the DET0649 relationship does not include detailed detection logic in the supplied fields. Local conclusions require customer-specific evidence from mobile management, device inventory, app inventory, and access-control logs. This summary does not assert active exploitation or customer exposure.
Compromise Application Executable
Adversaries may modify applications installed on a device to establish persistent access to a victim. These malicious modifications can be used to make legitimate applications carry out adversary tasks when these applications are in use.
There are multiple ways an adversary can inject malicious code into applications. One method is by taking advantages of device vulnerabilities, the most well-known being Janus, an Android vulnerability that allows adversaries to add extra bytes to APK (application) and DEX (executable) files without affecting the file's signature. By being able to add arbitrary bytes to valid applications, attackers can seamlessly inject code into genuine executables without the user's knowledge.[1]
Adversaries may also rebuild applications to include malicious modifications. This can be achieved by decompiling the genuine application, merging it with the malicious code, and recompiling it.[2]
Adversaries may also take action to conceal modifications to application executables and bypass user consent. These actions include altering modifications to appear as an update or exploiting vulnerabilities that allow activities of the malicious application to run inside a system application.[2]
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
S0311: YiSpecter
S1079: BOULDSPY
S0440: Agent Smith
Agent Smith is mobile malware that generates financial gain by replacing legitimate applications on devices with malicious versions that include fraudulent ads. As of July 2019 Agent Smith had infected around 25 million devices, primarily targeting India though effects had been observed in other Asian countries as well as Saudi Arabia, the United Kingdom, and the United States.[1]
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 | 49c0fbb48416… |
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]
Guardsquare Janus
Guarsquare. (2017, November 13). New Android vulnerability allows attackers to modify apps without affecting their signatures. Retrieved May 7, 2020.
Open source URL -
[2]
CheckPoint Agent Smith
A. Hazum, F. He, I. Marom, B. Melnykov, A. Polkovnichenko. (2019, July 10). Agent Smith: A New Species of Mobile Malware. Retrieved May 7, 2020.
Open source URL -
[3]
mitre-attack T1577Open 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.