DET0699: Detection of User Evasion
DET0699 is a mobile ATT&CK detection strategy tied to Android User Evasion, where malicious behavior may be hidden from the device user so it can remain in...
Analyst context for executives and security teams
DET0699 is a mobile ATT&CK detection strategy tied to Android User Evasion, where malicious behavior may be hidden from the device user so it can remain installed and continue operating longer. The business issue is not a single alert type; it is whether mobile security monitoring can notice apps that change behavior based on user presence or device sensor context, such as motion sensor signals.
Executive priority
Treat this as a mobile resilience and visibility question. Leaders should ask whether Android devices in scope for business operations have enough MDM, mobile threat defense, or EDR telemetry to identify suspicious app behavior, unusual sensor use, and persistence despite low user-visible symptoms. This matters for incident triage and audit evidence because user-facing complaints may be absent even when a device remains affected.
Technical view
The supplied ATT&CK object has no official description or detection logic, so SOC and detection teams should anchor validation to the related technique T1628.002, User Evasion, on Android. Validate whether monitoring can correlate application behavior with sensor access, foreground/background execution, app lifecycle events, permission use, and signs that an app suppresses visible behavior when the user may notice. Detection engineering should focus on behavior patterns rather than assuming a single signature.
Likely telemetry
- Android application inventory and package metadata
- Application permission requests and use, especially access to device sensors where available
- Mobile EDR, MTD, or MDM behavioral events
- Android app lifecycle, foreground/background activity, and service execution telemetry where collected
- User reports and help desk signals correlated with device/app telemetry, recognizing that user-visible symptoms may be intentionally minimized
Detection direction
- Confirm whether Android mobile telemetry includes sensor-related app behavior; many environments collect inventory but not runtime sensor access.
- Look for suspicious combinations: sensor access plus background execution, evasive timing, reduced visible UI activity, or inconsistent behavior during user interaction.
- Tune carefully for legitimate apps that use accelerometer or gyroscope data, such as fitness, navigation, accessibility, or device-management applications.
- Use relationship context to prioritize detections around T1628.002 rather than treating DET0699 as a complete analytic, because no official detection text is supplied.
- Validate incident response playbooks for cases where the device user reports little or nothing abnormal.
Mitigation priorities
- Establish authoritative Android device and application inventory for managed devices.
- Restrict or review high-risk mobile app permissions through MDM or mobile security policy where feasible.
- Prioritize mobile security tooling that provides behavioral telemetry, not only static app presence.
- Define triage procedures for suspicious apps that may remain quiet when the user is active or watching.
- Document mobile telemetry coverage and gaps as compliance and incident-readiness evidence.
Analyst notes and limits
This take is based on DET0699 and its relationship to T1628.002 User Evasion. The official detection strategy fields supplied here do not include a description, detection logic, tactics, or platforms; the Android platform and behavior context come from the related ATT&CK technique.
Coverage and detection feasibility depend heavily on the organization’s Android management model, enrolled device population, mobile telemetry depth, privacy constraints, and local baseline of legitimate sensor-using applications. No active exploitation, attribution, or guaranteed detection coverage is implied by the supplied ATT&CK fields.
Detection of User Evasion
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1628.002 | User Evasion Sub-technique | This object detects User Evasion. |
All related ATT&CK context
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.0 | Current bundle | 0a48b6f2f360… |
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 DET0699Open 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.