Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1697: Analytic 1697

An app or app update arrives through an expected delivery path or presents as a known legitimate package identity, but its post-install or post-update behavior materially changes in ways inconsistent with its historical role. The defender correlates package identity and install/update context, newly expanded capability state, changed runtime framework use, new sensor or storage behaviors, and new network destinations shortly after installation or update to identify likely supply-chain compromise rather than ordinary malicious sideloading or unrelated post-compromise activity.

MobileAN1697AnalyticObject v1.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic is about spotting a potentially compromised Android app supply chain: an app arrives through an expected path or keeps a legitimate package identity, but after install or update its behavior changes in ways that no longer match its historical role. The business value is distinguishing a trusted-app problem from ordinary sideloaded malware, because the response may require faster containment, vendor/package trust decisions, and evidence about what changed after the update.

Executive priority

Prioritize this where Android devices support business operations, privileged workflows, regulated data access, or executive/mobile workforce use. Leaders should ask whether mobile security, SOC, and incident response teams can prove when a legitimate-looking app changed permissions, runtime behavior, sensor or storage access, and network destinations after installation or update. The key decision value is preserving operational and compliance confidence in trusted mobile software distribution without assuming that a familiar package name remains safe.

Technical view

For Android, validate whether telemetry can correlate package identity, install or update context, expanded capability state, runtime framework use, sensor and storage behavior, and new network destinations shortly after installation or update. Since no official detection logic is provided, teams should treat this as a detection design objective rather than a ready rule. The analytic depends on baselining an app’s historical role and comparing post-install or post-update behavior against that baseline to separate likely supply-chain compromise from malicious sideloading or unrelated post-compromise activity.

Likely telemetry

  • Android package identity and version/update records
  • Install and update source/context metadata
  • Permission or capability state changes after install/update
  • Runtime framework usage indicators
  • Sensor access activity

Detection direction

  • Confirm that mobile telemetry preserves package identity and install/update context, not just app names.
  • Tune for material behavior changes shortly after install or update, especially new capabilities, runtime framework use, sensor or storage behaviors, and network destinations inconsistent with the app’s historical role.
  • Use historical baselines to reduce false positives from legitimate feature releases, major version changes, or approved changes in app functionality.
  • Investigate in context before escalation: the analytic is intended to distinguish expected-delivery-path compromise from sideloading or unrelated activity, but local app inventory and update policy are required to make that judgment.
  • Document blind spots where Android fleet telemetry does not capture permission changes, sensor/storage use, or network destinations at sufficient fidelity.

Mitigation priorities

  • Maintain an authoritative inventory of approved Android packages, versions, and expected delivery paths.
  • Establish baselines for normal app capabilities, sensor/storage behavior, runtime framework use, and network destinations for important mobile apps.
  • Require change review or heightened monitoring for app updates that materially expand capabilities or external communications.
  • Ensure incident response playbooks include mobile app update rollback, device containment, evidence preservation, and vendor/package trust assessment steps.
  • Use the analytic to support compliance evidence that trusted mobile software is monitored after deployment, not only at installation time.
Analyst notes and limits

This object is a mobile ATT&CK detection analytic for Android with no supplied tactic, no relationships, and no official detection query. Its value is in the correlation model: trusted package identity plus expected delivery path is not sufficient; defenders need post-install and post-update behavioral comparison.

The supplied ATT&CK fields do not provide concrete detection logic, data source mappings, related techniques, adversary use, or mitigation objects. Any operational rule, severity model, or vendor-specific implementation must be derived from local Android telemetry, mobile management controls, and historical app behavior.

Official MITRE ATT&CK definition

Analytic 1697

An app or app update arrives through an expected delivery path or presents as a known legitimate package identity, but its post-install or post-update behavior materially changes in ways inconsistent with its historical role. The defender correlates package identity and install/update context, newly expanded capability state, changed runtime framework use, new sensor or storage behaviors, and new network destinations shortly after installation or update to identify likely supply-chain compromise rather than ordinary malicious sideloading or unrelated post-compromise activity.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.1
Created
Modified
Raw hash
7069513fa00e3040...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle 7069513fa00e…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1697
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use