AN1848: Analytic 1848
The defender correlates an application establishing outbound retrieval to a non-baselined external source with immediate local creation of a new executable, module, staged payload, overlay asset, or secondary file in app-controlled or shared storage, followed by optional load, invocation, handoff, or repeat retrieval behavior. The analytic prioritizes Android-observable effects: network download activity, DownloadManager or direct HTTP retrieval, file creation in package-specific or external paths, and execution context inconsistent with recent user interaction or the app’s declared role.
Analyst context for executives and security teams
This analytic matters because it looks for an Android app that retrieves content from an unusual external source and then immediately creates a new local file that could be used as an executable, module, staged payload, overlay asset, or secondary component. For leaders, the practical value is validating whether mobile monitoring can connect network download behavior to on-device file creation and follow-on use, rather than treating those events as isolated signals.
Executive priority
Prioritize this where Android devices or Android applications are material to operations, regulated data access, workforce mobility, or customer-facing services. The business question is whether the organization can produce evidence that suspicious mobile app download-and-stage behavior would be observed, triaged, and escalated quickly. This supports incident readiness, mobile security governance, and audit discussions around monitoring of unmanaged or app-controlled storage behaviors.
Technical view
For SOC, detection engineering, and IR teams, validate correlation across Android-observable effects: outbound retrieval to a non-baselined external source, DownloadManager or direct HTTP activity, immediate creation of a new file in package-specific or shared/external storage, and any subsequent load, invocation, handoff, repeat retrieval, or execution context inconsistent with recent user interaction or the app’s declared role. Because no official detection logic is provided, teams should treat AN1848 as a behavior pattern to engineer and test against local Android telemetry rather than as a ready-to-run rule.
Likely telemetry
- Android network connection or HTTP retrieval telemetry, including destination/source reputation or baseline context
- DownloadManager activity where available
- Application-level direct HTTP retrieval evidence where available
- File creation events in package-specific app storage
- File creation events in shared or external storage paths
Detection direction
- Build correlation around sequence and timing: unusual outbound retrieval followed by immediate local file creation, then optional load, invocation, handoff, or repeat retrieval.
- Baseline expected external sources per application so that 'non-baselined external source' is meaningful in the local environment.
- Tune for legitimate app update, content sync, media download, and enterprise app workflows to reduce false positives.
- Validate visibility into both DownloadManager-based retrieval and direct HTTP retrieval, since either path is in scope.
- Check whether mobile telemetry distinguishes package-specific storage from shared or external storage, because storage location is central to the analytic.
Mitigation priorities
- Establish a mobile application inventory and expected-network-destination baseline for Android apps in scope.
- Ensure managed Android monitoring can collect or expose network retrieval, file creation, and app execution context needed for this analytic.
- Restrict or govern applications that can access sensitive enterprise data when their download and storage behavior cannot be validated.
- Use mobile security policy, app vetting, and configuration controls to reduce exposure from apps with unnecessary external storage or dynamic content retrieval patterns.
- Prepare IR playbooks for suspicious Android app download-and-stage activity, including device isolation, app review, evidence preservation, and credential/session risk assessment where applicable.
Analyst notes and limits
AN1848 is a detection analytic in the ATT&CK mobile domain for Android. It is relationship-sparse in the supplied data: no tactics, techniques, groups, software, campaigns, or mitigations were provided. The strongest decision value is therefore in coverage validation: can defenders correlate network retrieval, local file creation, and possible follow-on use on Android devices?
The official detection field is not provided, and no relationship context is supplied. This take does not assert active exploitation, attribution, impact, or existing detection coverage. Local Android management architecture, app telemetry, privacy constraints, and logging depth will determine whether the analytic can be implemented reliably.
Analytic 1848
The defender correlates an application establishing outbound retrieval to a non-baselined external source with immediate local creation of a new executable, module, staged payload, overlay asset, or secondary file in app-controlled or shared storage, followed by optional load, invocation, handoff, or repeat retrieval behavior. The analytic prioritizes Android-observable effects: network download activity, DownloadManager or direct HTTP retrieval, file creation in package-specific or external paths, and execution context inconsistent with recent user interaction or the app’s declared role.
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 | a612d7a3c936… |
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 AN1848Open 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.