AN1734: Analytic 1734
Correlates (1) application activity that creates, modifies, or accesses local artifacts relevant to detection or device compromise state, (2) subsequent deletion, alteration, renaming, relocation, or visibility suppression of those artifacts, including files, application presence, media, or root-compromise indicators, and (3) continued application execution, reduced telemetry quality, or outbound activity after the artifact state changes. The defender observes a causal chain where host-side evidence is first manipulated and expected visibility or reporting degrades while the initiating application remains active.
Analyst context for executives and security teams
This Android detection analytic matters because it focuses on evidence tampering, not just the original suspicious activity. The practical signal is a sequence: an app interacts with local artifacts that may indicate compromise or detection state, those artifacts are then deleted, altered, renamed, moved, or hidden, and the app continues running or communicating while visibility degrades. For leaders, this is important because an incident can look cleaner than it is if device-side evidence is being suppressed.
Executive priority
Prioritize this as a mobile visibility and incident-readiness control question: can the organization prove that Android device telemetry remains trustworthy when local artifacts or reporting indicators change? This supports decisions around mobile device monitoring, IR evidence handling, and audit confidence. The business risk is not proven compromise from this analytic alone; it is the possibility that response teams may underestimate an event because the device evidence trail has been manipulated or weakened.
Technical view
For SOC, detection engineering, and IR teams, validate whether Android telemetry can correlate three stages: artifact creation/modification/access by an application, subsequent artifact deletion/alteration/renaming/relocation/visibility suppression, and continued application execution or outbound activity after the artifact state change. Because no ATT&CK tactic or official detection logic is supplied, treat this as a correlation design pattern rather than a complete rule. The key engineering question is whether host-side artifact state changes can be tied causally and temporally to the same initiating application and then compared against application runtime and network behavior.
Likely telemetry
- Android application activity and lifecycle events
- Local file or artifact creation, access, modification, deletion, rename, relocation, or visibility-change events
- Application presence or package-state telemetry where available
- Media or local artifact inventory changes relevant to device compromise assessment
- Root-compromise indicator state or integrity-related observations where collected
Detection direction
- Build or validate correlation across artifact interaction, artifact state change, and continued app execution or outbound activity.
- Tune time windows carefully: too broad may create false positives from normal app cleanup; too narrow may miss staged manipulation.
- Require context tying the artifact manipulation to the initiating application where telemetry supports it.
- Review blind spots where Android telemetry does not expose file-level changes, app visibility changes, or device reporting degradation.
- Treat reduced telemetry quality after artifact changes as an investigation trigger, not standalone proof of malicious activity.
Mitigation priorities
- Confirm Android mobile monitoring can preserve or report relevant host-side artifact state changes before relying on this analytic operationally.
- Strengthen device telemetry health monitoring so degraded reporting is visible to SOC and IR teams.
- Ensure incident response procedures account for possible local evidence suppression and include alternate evidence sources where available.
- Review mobile application governance and permissions to reduce unnecessary access to sensitive local artifacts where supported by policy and platform controls.
- Use this analytic to inform compliance evidence discussions around mobile logging completeness and tamper-aware monitoring, while documenting platform limitations.
Analyst notes and limits
AN1734 is a detection analytic for the mobile ATT&CK domain and the Android platform. Its value is in detecting a causal chain of local evidence manipulation plus continued application activity, which can indicate that visibility has been weakened while the app remains operational. The supplied object does not include a formal detection query, tactic mapping, or relationships, so implementation depends heavily on the organization’s Android telemetry sources and retention.
This take uses only the supplied ATT&CK fields and external reference. No official detection text, tactic, related technique, software, group, or mitigation relationships were provided. The analytic should not be interpreted as evidence of active exploitation, attribution, or guaranteed detection coverage without local telemetry and investigation findings.
Analytic 1734
Correlates (1) application activity that creates, modifies, or accesses local artifacts relevant to detection or device compromise state, (2) subsequent deletion, alteration, renaming, relocation, or visibility suppression of those artifacts, including files, application presence, media, or root-compromise indicators, and (3) continued application execution, reduced telemetry quality, or outbound activity after the artifact state changes. The defender observes a causal chain where host-side evidence is first manipulated and expected visibility or reporting degrades while the initiating application remains active.
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 | c89b6ba149fc… |
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 AN1734Open 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.