AN1730: Analytic 1730
The defender correlates anomalous application package replacement, update, or executable-content drift with subsequent execution under the trusted application's identity, especially when package metadata, signing lineage, install source, file integrity, or native/DEX component characteristics change without a corresponding trusted distribution path. The analytic prioritizes Android-observable control-plane effects: package install/update events, package hash or code-section drift, signer mismatch or lineage break, unexpected app process behavior after replacement, and optional near-term network or sensor activity inconsistent with the legitimate application's baseline.
Analyst context for executives and security teams
This analytic matters because it focuses on a high-risk mobile trust failure: an Android application that appears to be trusted may have been replaced or altered, then continues running under that trusted identity. For leaders, the practical issue is whether the organization can prove that mobile apps on managed Android devices are installed from trusted paths, remain signed and intact, and do not begin behaving differently after an update or replacement.
Executive priority
Prioritize this where Android devices support business operations, privileged access, regulated workflows, or field activity. The decision value is in validating mobile governance and incident readiness: can security teams distinguish legitimate app updates from package replacement, signing lineage breaks, executable drift, or unexpected post-update behavior? This supports control assurance, audit evidence for managed mobile environments, and faster incident decisions when a trusted app becomes suspicious.
Technical view
For SOC, mobile security, and IR teams, validate whether Android telemetry can correlate package install or update events with package metadata, hashes, signing lineage, install source, native or DEX component changes, subsequent process execution, and near-term network or sensor behavior. Because no ATT&CK tactic or relationship context is supplied, treat this as a detection analytic centered on post-update trust validation rather than a complete technique mapping. The highest-value engineering task is correlation across package control-plane events and runtime behavior under the same application identity.
Likely telemetry
- Android package install and update events
- Application package metadata and install source records
- Package hash, code-section, native library, and DEX component integrity data
- Application signing certificate, signer mismatch, and signing lineage evidence
- Application process execution and behavior after replacement or update
Detection direction
- Validate that legitimate update channels are modeled so trusted distribution paths are not treated the same as unknown or sideloaded sources.
- Correlate package replacement or executable-content drift with subsequent execution under the same trusted application identity.
- Prioritize signer mismatch, signing lineage breaks, unexpected hash drift, or native/DEX component changes without a corresponding trusted distribution path.
- Tune for legitimate app releases, staged rollouts, enterprise app deployments, and developer-signed internal applications to reduce false positives.
- Look for post-update runtime deviations, such as unexpected process behavior, network destinations, or sensor use compared with the legitimate application baseline.
Mitigation priorities
- Establish approved Android app sources and update paths for managed devices.
- Maintain inventory of expected package names, versions, signing certificates, and approved distribution sources for business-critical apps.
- Use mobile management controls to restrict untrusted installation paths where appropriate.
- Require integrity and signing validation for enterprise-distributed Android applications.
- Retain mobile telemetry long enough to correlate package changes with later execution and network or sensor behavior.
Analyst notes and limits
The supplied object is a mobile ATT&CK detection analytic for Android. Its value is strongest when paired with local mobile inventory, app distribution policy, signing expectations, and behavioral baselines. No relationship context was supplied, so this take does not infer associated techniques, campaigns, malware, or threat actors.
Official detection content is not provided, tactics are not specified, and no relationships are supplied. Coverage depends on whether the environment collects Android package, signing, integrity, install-source, process, network, and sensor telemetry. This assessment does not claim active exploitation, attribution, or guaranteed detection.
Analytic 1730
The defender correlates anomalous application package replacement, update, or executable-content drift with subsequent execution under the trusted application's identity, especially when package metadata, signing lineage, install source, file integrity, or native/DEX component characteristics change without a corresponding trusted distribution path. The analytic prioritizes Android-observable control-plane effects: package install/update events, package hash or code-section drift, signer mismatch or lineage break, unexpected app process behavior after replacement, and optional near-term network or sensor activity inconsistent with the legitimate application's baseline.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.1 | Current bundle | 7c6590c7abe6… |
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 AN1730Open 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.