AN1815: Analytic 1815
Correlates (1) continuous or repeated use of motion or interaction-inference signals that do not require overt user-facing privilege prompts, (2) suppression of higher-risk behavior while user presence or active handling is inferred, and (3) resumption of background execution, sensor use, local data handling, or network activity only when device interaction falls below a threshold. The defender observes a causal chain where an application senses user/device interaction state and intentionally gates malicious behavior to user-inactive periods.
Analyst context for executives and security teams
This analytic matters because it describes Android apps that appear to watch whether a user is actively handling the device and then delay higher-risk behavior until the device seems inactive. For leaders, the practical issue is not just sensor use; it is evasion of normal user observation and some prompt-driven review processes. If an organization relies on mobile devices for business workflows, this behavior can weaken confidence in mobile monitoring, incident triage, and compliance evidence unless teams can correlate user-interaction state with later background activity.
Executive priority
Prioritize this as a mobile security and SOC readiness question: can the organization prove when an Android app is using interaction or motion-related signals, suppressing activity during user presence, and resuming background execution, sensor use, local data handling, or network activity afterward? The business value is in validating whether mobile telemetry and incident response processes can identify delayed or user-inactive behavior rather than only obvious foreground activity.
Technical view
For SOC, detection engineering, and IR teams, the key validation is correlation. The supplied analytic describes a causal chain: repeated use of motion or interaction-inference signals that do not require overt user-facing privilege prompts, followed by reduced higher-risk behavior while active handling is inferred, followed by resumed background execution, sensor use, local data handling, or network activity when interaction drops below a threshold. Because no official detection logic is provided, teams should test whether Android telemetry can show timing relationships between interaction-state inference and later background activity by the same application.
Likely telemetry
- Android application execution state and background execution events
- Sensor or motion/interaction-inference signal usage where observable
- User/device interaction or active-handling indicators where available
- Application network activity timing and volume
- Local data access or handling events by application
Detection direction
- Validate correlation across time, not single events: the material pattern is sensing interaction state, suppressing activity during apparent user presence, then resuming activity during inactivity.
- Tune for repeated or continuous interaction-inference signal use followed by delayed background execution, sensor use, data handling, or network activity by the same Android application.
- Account for false positives from legitimate apps that adjust behavior based on user activity, power state, or background scheduling; require the full causal chain before escalating severity.
- Identify blind spots where telemetry captures network activity but not sensor/interaction inference, or captures app permissions but not runtime behavior.
- Because tactics and relationships are not specified, avoid mapping this analytic to broader intrusion stages without local evidence.
Mitigation priorities
- First, confirm whether managed Android devices provide sufficient telemetry for application identity, background execution, sensor-related behavior, local data handling, and network activity timing.
- Second, review mobile application governance for apps that do not need interaction or motion-derived behavior for business purposes, especially where background activity is also observed.
- Third, strengthen incident response playbooks so mobile investigations include delayed/background behavior and not only foreground user-visible activity.
- Fourth, use mobile security, MDM, and compliance evidence to document which devices and app classes have coverage for this behavior and where compensating controls are required.
Analyst notes and limits
This is a detection analytic object for the mobile ATT&CK domain, platform Android, external ID AN1815. The official description is specific about correlation of interaction inference with gated behavior, but the object does not provide formal detection logic, tactics, aliases, labels, or relationship context. Treat this as a hypothesis and coverage-validation guide rather than a ready-to-deploy rule.
Assessment is limited to the supplied STIX fields, official description, external reference, and absence of relationship context. No active exploitation, attribution, affected customers, guaranteed detection, or non-Android platform coverage is implied. Local Android telemetry availability will determine whether this analytic is actionable.
Analytic 1815
Correlates (1) continuous or repeated use of motion or interaction-inference signals that do not require overt user-facing privilege prompts, (2) suppression of higher-risk behavior while user presence or active handling is inferred, and (3) resumption of background execution, sensor use, local data handling, or network activity only when device interaction falls below a threshold. The defender observes a causal chain where an application senses user/device interaction state and intentionally gates malicious behavior to user-inactive periods.
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 | 95b788ce94c6… |
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 AN1815Open 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.