AN1644: Analytic 1644

Correlates (1) an application obtaining or maintaining elevated control mechanisms capable of resisting removal (device administrator, accessibility control, managed-owner posture), (2) user navigation into uninstall or application-management flows, and (3) immediate UI redirection, back-navigation injection, modal dismissal, or failed uninstall completion followed by continued app presence. Defender observes a causal chain where a removal attempt is actively disrupted and the target application remains installed.

MobileAN1644AnalyticObject v1.1 Modified May 12, 2026, 16:30 UTC (UTC+00:00)

This mobile detection analytic is about spotting Android apps that appear to interfere with a user’s attempt to remove them. The practical issue is not just persistence; it is whether an app can maintain elevated control, redirect the user away from uninstall or app-management screens, and remain installed after a removal attempt. For security leaders, this matters because it can undermine incident containment, employee self-remediation, mobile fleet hygiene, and evidence that endpoint controls can remove unwanted applications.

Executive priority

Prioritize this analytic where Android devices are part of managed operations, regulated workflows, executive mobility, or cyber-physical environments. Leadership should ask whether mobile device management, SOC monitoring, and incident response procedures can prove that a suspect app was actually removed, not merely that removal was attempted. The key decision value is validating resilience of mobile containment and deprovisioning processes when an app has elevated control mechanisms such as device administrator, accessibility control, or managed-owner posture.

Technical view

For Android, validate whether telemetry can correlate three events in sequence: an app holding or maintaining elevated control mechanisms; user navigation into uninstall or application-management flows; and immediate disruption such as UI redirection, back-navigation injection, modal dismissal, failed uninstall completion, or continued app presence. Because no ATT&CK tactic, relationship context, or official detection logic is supplied, teams should treat AN1644 as a behavioral correlation requirement rather than a ready-made rule. IR teams should confirm final application state after any removal attempt and preserve evidence of both the attempted uninstall flow and the app’s continued presence.

Likely telemetry

Android application inventory and install/uninstall state changes
Device administrator, accessibility control, and managed-owner posture status
User navigation or UI event telemetry for uninstall and application-management screens, where available
Mobile device management or enterprise mobility management logs showing app status and policy posture
Application lifecycle events indicating failed uninstall completion or continued app presence

Detection direction

Validate causal ordering rather than isolated indicators: elevated control, uninstall/app-management navigation, disruption of that flow, then continued app presence.
Tune for false positives from legitimate enterprise management controls, accessibility tools, parental-control software, kiosk configurations, or policy-driven app protection that may intentionally restrict removal.
Confirm whether available Android and MDM telemetry captures UI redirection, back navigation, modal dismissal, or only the final app inventory state; many environments may lack the full UI-level sequence.
Use this analytic to test SOC and IR playbooks: an alert should drive verification of the app’s current state and the control mechanism that may be preventing removal.
Because no relationships are supplied, do not infer associated malware, campaigns, or ATT&CK techniques without local evidence.

Mitigation priorities

Establish policy and inventory visibility for apps with device administrator, accessibility, or managed-owner capabilities.
Require review and approval for applications granted elevated mobile control mechanisms, especially on managed Android devices.
Ensure mobile incident response procedures verify completed removal and do not rely solely on user reports or attempted uninstall actions.
Maintain MDM or enterprise mobility controls capable of identifying apps that remain present after a removal attempt.
Document removal validation evidence for audit, compliance readiness, and post-incident reporting where Android devices support sensitive business processes.

Analyst notes and limits

AN1644 is a detection analytic in the mobile ATT&CK domain for Android. Its value is in correlation: it describes a chain of behavior indicating that an app may be resisting removal during an uninstall or application-management flow. The supplied object does not include tactics, relationships, labels, aliases, or official detection code, so local telemetry design and environment-specific baselining are required.

This take is limited to the supplied STIX fields, external reference, and absence of relationship context. It does not assert active exploitation, attribution, business impact, or existing detection coverage. The object provides no official detection implementation, so any operational rule must be engineered and validated against local Android, MDM, and SOC telemetry.

Official MITRE ATT&CK definition

Analytic 1644

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: Oct 21, 2025, 15:10 UTC (UTC+00:00)
Modified: May 12, 2026, 16:30 UTC (UTC+00:00)
Raw hash: 0af8e789a78b5b6c...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.1	May 12, 2026, 16:30 UTC (UTC+00:00)	Current bundle	`0af8e789a78b…`

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]
mitre-attack AN1644
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