AN1653: Analytic 1653
The defender observes a newly enrolled or recently activated device presenting abnormal integrity, hardware-backed attestation, or firmware/build relationships at the management plane, followed by privileged or system-context access to protected resources or framework paths, and then outbound communication inconsistent with setup state, lock state, or recent user interaction. The causal sequence is strongest when the device has not yet reached a normal trusted posture but still exhibits system-level capability use or network activity.
Analyst context for executives and security teams
AN1653 describes an Android mobile detection analytic focused on a risky enrollment or activation pattern: a device that has not yet established a normal trusted posture shows abnormal integrity, attestation, firmware, or build signals, then uses privileged or system-context capabilities and communicates outbound in ways that do not fit its setup, lock, or user-interaction state. For leaders, the value is in validating whether mobile device management and security monitoring can distinguish a legitimately newly enrolled device from one that is already behaving like a compromised or untrusted endpoint.
Executive priority
Prioritize this analytic where Android devices access protected business resources, sensitive apps, or managed enterprise services. It supports decisions about mobile trust, conditional access, incident triage, and audit evidence for device posture enforcement. The key business question is whether newly enrolled or recently activated Android devices can be held to a trusted baseline before they receive meaningful access, and whether exceptions are visible enough for SOC or incident response teams to act quickly.
Technical view
SOC, mobile security, IAM, and IR teams should validate the full causal sequence described by the analytic: recent enrollment or activation; abnormal integrity, hardware-backed attestation, firmware, or build relationships at the management plane; privileged or system-context access to protected resources or framework paths; and outbound communication inconsistent with setup state, lock state, or recent user interaction. Because ATT&CK does not provide a formal detection implementation for this analytic, teams should map the concept to available Android management-plane logs, device posture signals, access-control events, system or framework access telemetry, and network activity associated with the device lifecycle.
Likely telemetry
- Android device enrollment and activation events from the management plane
- Device integrity and hardware-backed attestation results
- Firmware, build, and device posture attributes
- Privileged or system-context access events to protected resources or framework paths
- Conditional access or protected-resource access logs tied to device identity
Detection direction
- Correlate enrollment or recent activation with posture anomalies before treating later privileged activity as high-confidence suspicious behavior.
- Validate that device integrity, attestation, firmware, and build-state data are collected consistently for Android devices and are available to detection workflows.
- Tune for sequence and context rather than single events: newly activated device plus abnormal posture plus privileged/system-context access plus unexpected outbound communication is stronger than any one signal alone.
- Review false positives from legitimate provisioning, OS updates, device repair/replacement, enterprise staging, and delayed management-plane synchronization.
- Identify blind spots where device setup state, lock state, user interaction, or outbound communication is not logged or cannot be joined to the managed device identity.
Mitigation priorities
- Enforce trusted device posture requirements before granting access to protected resources where business process allows.
- Require reliable Android management-plane enrollment, attestation, and integrity checks for devices that access sensitive services.
- Limit privileged or system-context access paths from devices that have not reached a normal trusted posture.
- Define response playbooks for recently enrolled devices with abnormal posture signals, including containment, access review, and re-enrollment or device validation.
- Use compliance reporting to show whether Android device posture controls are enforced and whether exceptions are reviewed.
Analyst notes and limits
This is a mobile ATT&CK detection analytic for Android, not a technique description. No tactics, relationships, aliases, or official detection logic were supplied. The practical value comes from correlating management-plane trust signals with privileged access and network behavior during the device enrollment or activation window.
The supplied ATT&CK object does not include an official detection query, data source list, tactic mapping, related techniques, mitigations, or relationship context. Local MDM, IAM, endpoint, and network telemetry determine whether this analytic is implementable and how reliable it will be.
Analytic 1653
The defender observes a newly enrolled or recently activated device presenting abnormal integrity, hardware-backed attestation, or firmware/build relationships at the management plane, followed by privileged or system-context access to protected resources or framework paths, and then outbound communication inconsistent with setup state, lock state, or recent user interaction. The causal sequence is strongest when the device has not yet reached a normal trusted posture but still exhibits system-level capability use or network activity.
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 | ca5afafe7cf6… |
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 AN1653Open 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.