AN1823: Analytic 1823
A legitimate-seeming application or update is installed through an expected or previously trusted path, but shortly after first run or update the application exhibits new runtime behavior, sensor use, file staging, or network communications inconsistent with its historical baseline, documented role, or prior version. The defender specifically looks for behaviors commonly introduced by compromised third-party libraries or manipulated build tooling, such as unexpected background service activation, first-seen framework use, new permissions exercised, novel network destinations, or dropped local artifacts not aligned to the app's expected function.
Analyst context for executives and security teams
This analytic matters because it focuses on a high-trust mobile risk: an Android app or update arrives through a normal-looking path, but then behaves differently after install or first run. For leaders, the practical issue is not only malware detection; it is whether the organization can notice when a trusted mobile application, update process, third-party library, or build pipeline introduces unexpected permissions, services, files, sensors, or network activity.
Executive priority
Prioritize this where Android devices support business operations, privileged access, regulated data handling, or field workflows. The decision value is to confirm whether mobile security, SOC monitoring, and incident response can compare app behavior against a known baseline after updates. This supports operational resilience, audit evidence for mobile control effectiveness, and faster decisions about quarantining devices, blocking apps, or escalating suspected supply-chain compromise.
Technical view
For SOC, detection engineering, and IR teams, validate whether Android app behavior can be baselined by app identity and version, then compared after install or update. The supplied analytic emphasizes deviations such as unexpected background service activation, first-seen framework use, newly exercised permissions, novel network destinations, and dropped local artifacts inconsistent with the app’s documented role. Because no official detection logic is provided, teams should treat this as a detection strategy requiring local telemetry design, baselining, and tuning rather than a ready rule.
Likely telemetry
- Android application inventory, package name, version, install source, and update timing
- Runtime permission requests and permission use after first run or update
- Background service activation and scheduled/background execution indicators
- Sensor access telemetry where available, such as camera, microphone, location, or other device sensors
- Network connection metadata from mobile device, MDM/UEM, mobile threat defense, DNS, proxy, or firewall sources
Detection direction
- Baseline expected behavior per Android app and version before relying on anomaly alerts.
- Tune for post-install or post-update behavior changes, especially first-seen permissions, services, frameworks, files, sensors, or destinations.
- Correlate behavior changes with update timing and install path to reduce noise from legitimate feature releases.
- Review false positives from normal app upgrades, A/B feature rollouts, regional endpoints, SDK changes, and OS-level behavior changes.
- Identify blind spots where MDM/UEM provides inventory but not runtime behavior, sensor use, local artifacts, or destination-level network visibility.
Mitigation priorities
- Maintain accurate Android app inventory, version tracking, and approved install/update sources.
- Define expected app roles and behavior baselines for business-critical or high-privilege mobile applications.
- Require mobile security controls that can observe or restrict risky runtime behaviors, permissions, and network activity where appropriate.
- Strengthen mobile app vetting and update review for applications that handle sensitive data or operational workflows.
- Prepare IR playbooks for suspicious mobile app updates, including device isolation, app removal, evidence preservation, and user/business impact assessment.
Analyst notes and limits
This is a mobile ATT&CK detection analytic for Android. Its value is in turning trusted-app/update assumptions into measurable runtime validation. It is especially relevant to managed detection, mobile security operations, incident response readiness, and security governance where Android devices have access to enterprise data or workflows.
The supplied ATT&CK object has no tactics, no official detection logic, no relationships, and no external references beyond the MITRE ATT&CK URL. This take is therefore limited to the official description and platform field. Local device management, mobile telemetry, application inventory, and business context are required to determine actual coverage and priority.
Analytic 1823
A legitimate-seeming application or update is installed through an expected or previously trusted path, but shortly after first run or update the application exhibits new runtime behavior, sensor use, file staging, or network communications inconsistent with its historical baseline, documented role, or prior version. The defender specifically looks for behaviors commonly introduced by compromised third-party libraries or manipulated build tooling, such as unexpected background service activation, first-seen framework use, new permissions exercised, novel network destinations, or dropped local artifacts not aligned to the app's expected function.
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 | b4c170bec63c… |
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 AN1823Open 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.