AN1797: Analytic 1797
Correlates (1) application-driven modification of device security posture or monitoring capability (e.g., accessibility abuse, disabling security app components, altering monitoring configuration), (2) immediate degradation or cessation of expected telemetry sources such as mobile EDR, sensor visibility, or system monitoring, and (3) subsequent application activity continuing with reduced observability. The defender observes a causal chain where defensive visibility or enforcement is altered first, followed by continued execution under reduced monitoring conditions.
Analyst context for executives and security teams
AN1797 is a mobile detection analytic for Android environments focused on a high-risk sequence: an application changes security or monitoring controls, expected device telemetry drops, and the application continues operating with reduced visibility. For leaders, the value is not simply detecting one setting change; it is validating whether mobile security operations can recognize when defenses are being weakened before subsequent activity becomes harder to observe.
Executive priority
Prioritize this analytic where Android devices support business operations, privileged access, regulated workflows, or incident response evidence collection. The business question is whether the organization can prove that mobile EDR, sensor, or system monitoring remained trustworthy during an incident. This supports operational resilience, audit evidence, and incident decision-making by highlighting attempts to reduce observability before continued execution.
Technical view
SOC and detection teams should validate correlation across three evidence points from the official analytic description: application-driven modification of device security posture or monitoring capability, immediate degradation or cessation of expected telemetry, and continued application activity afterward. Because no ATT&CK detection logic or tactic mapping is supplied, teams should treat this as a correlation design requirement rather than a ready-made rule. IR teams should preserve timelines showing the order of control modification, telemetry loss, and post-change app behavior.
Likely telemetry
- Android application activity and process/app execution records
- Events showing accessibility abuse or accessibility-related permission/state changes
- Mobile EDR, mobile threat defense, sensor, or agent health telemetry
- Security application component status, including disabling, stopping, or configuration changes
- System monitoring or device security posture configuration changes
Detection direction
- Validate causal ordering: security or monitoring change first, telemetry degradation immediately after, then continued application activity.
- Tune for legitimate administration, enrollment changes, security product updates, or user-approved configuration changes that can create similar telemetry gaps.
- Alert on loss of expected mobile sensor visibility when it is temporally linked to app-driven posture changes, not just isolated device offline events.
- Measure blind spots where telemetry loss prevents confirmation of the third stage; absence of data should be treated as an investigation condition, not proof of benign activity.
- Use Android-specific telemetry only, since Android is the only supplied platform.
Mitigation priorities
- Ensure Android mobile security tooling reports health, configuration, and heartbeat status independently enough to identify degradation or cessation of telemetry.
- Restrict and review application capabilities that can alter device security posture, monitoring configuration, accessibility behavior, or security app components where enterprise controls allow it.
- Define incident response playbooks for mobile telemetry loss that require timeline reconstruction and device/app validation before closing as a benign outage.
- Maintain baseline expectations for mobile EDR, sensor visibility, and system monitoring so deviations can be correlated quickly.
- Use this analytic to test managed detection and compliance evidence: confirm teams can show when monitoring was active, when it changed, and what activity followed.
Analyst notes and limits
The supplied object is a detection analytic, not a technique, and has no relationship context. Its main defensive value is correlation of control tampering or monitoring degradation with subsequent Android app activity. Implementation quality will depend on local mobile telemetry, agent health reporting, and the ability to distinguish administrative changes from suspicious app-driven changes.
Official detection content is not provided, tactics are not specified, and no relationships are supplied. This take does not assert active exploitation, attribution, impact, or guaranteed detection coverage. Local Android management, EDR, and logging capabilities are required to determine practical coverage.
Analytic 1797
Correlates (1) application-driven modification of device security posture or monitoring capability (e.g., accessibility abuse, disabling security app components, altering monitoring configuration), (2) immediate degradation or cessation of expected telemetry sources such as mobile EDR, sensor visibility, or system monitoring, and (3) subsequent application activity continuing with reduced observability. The defender observes a causal chain where defensive visibility or enforcement is altered first, followed by continued execution under reduced monitoring conditions.
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 | 352991afcf61… |
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 AN1797Open 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.