AN1853: Analytic 1853
The defender correlates the arrival, installation, or update of a trusted or expected application with a subsequent deviation in package trust characteristics, permission posture, protected-resource use, framework behavior, or network communication that is inconsistent with the known-good role of that app. The strongest Android evidence is a managed or trusted package whose first-run or post-update behavior introduces unexpected special access, sensitive sensor use, unusual background execution, privileged framework interaction, or outbound communication to destinations outside the app's baseline shortly after installation or update.
Analyst context for executives and security teams
This Android detection analytic is about spotting when a trusted or expected mobile app starts behaving unlike itself shortly after installation or update. For leaders, the value is not just malware detection; it is assurance that managed apps, approved app updates, and mobile access to business data are being monitored for trust drift before abnormal permissions, sensor access, background activity, or network communication becomes an incident blind spot.
Executive priority
Prioritize this where Android devices access corporate identity, messaging, regulated data, operational workflows, or executive communications. The key business question is whether the organization can prove that trusted mobile apps remain trustworthy after install or update, and whether SOC or mobile security teams can escalate deviations quickly enough to support incident decisions, compliance evidence, and mobile risk management.
Technical view
For SOC, detection engineering, and IR teams, validate coverage around Android package installation and update events, then correlate those events with near-term changes in package trust characteristics, permission posture, protected-resource use, framework behavior, background execution, and outbound network destinations. Because ATT&CK provides no separate detection logic and no relationship context for this analytic, local baselines are essential: teams need to know what each managed or trusted app normally does before they can judge a post-update deviation as suspicious.
Likely telemetry
- Android package arrival, installation, and update events
- Managed or trusted application inventory and package identity metadata
- Permission and special-access state changes after install or update
- Sensitive sensor or protected-resource access events
- Background execution and privileged framework interaction indicators
Detection direction
- Correlate install or update timing with behavior changes observed shortly afterward.
- Baseline known-good behavior for managed or expected apps before treating deviations as high confidence.
- Tune for changes that are inconsistent with the app’s expected role, such as new special access, sensitive sensor use, unusual background execution, privileged framework interaction, or new outbound destinations.
- Expect false positives from legitimate major app updates, new feature rollouts, permission model changes, or enterprise configuration changes.
- Identify blind spots where mobile telemetry does not capture protected-resource use, framework behavior, or network destination detail.
Mitigation priorities
- Maintain an authoritative inventory of managed and trusted Android apps, versions, signers, and expected roles.
- Review and govern app permissions and special access, especially after app updates.
- Require change awareness for approved mobile apps so SOC teams can distinguish expected feature changes from suspicious deviations.
- Ensure mobile network and endpoint telemetry is retained long enough to compare pre-update and post-update behavior.
- Prepare IR playbooks for suspicious trusted-app deviation, including device containment, app removal or rollback decisions, and evidence preservation.
Analyst notes and limits
This is a detection analytic in the mobile ATT&CK domain for Android. The official object describes correlation logic but does not provide a formal detection query, tactic mapping, aliases, labels, or relationship context. The strongest use is as a validation checklist for mobile detection coverage and trusted-app behavior baselining.
Assessment depends heavily on local Android management, mobile telemetry depth, and established app baselines. The supplied ATT&CK fields do not support claims about active exploitation, specific adversaries, impact, or guaranteed detection effectiveness.
Analytic 1853
The defender correlates the arrival, installation, or update of a trusted or expected application with a subsequent deviation in package trust characteristics, permission posture, protected-resource use, framework behavior, or network communication that is inconsistent with the known-good role of that app. The strongest Android evidence is a managed or trusted package whose first-run or post-update behavior introduces unexpected special access, sensitive sensor use, unusual background execution, privileged framework interaction, or outbound communication to destinations outside the app's baseline shortly after installation or update.
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 | bb6055cb5df6… |
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 AN1853Open 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.