AN1675: Analytic 1675
The defender correlates an app-attributed request to a legitimate public web platform with a subsequent outbound connection to a newly derived or previously unseen destination within a short time window. The behavior is strengthened when the initial request retrieves structured or encoded content followed by a pivot to a different domain or IP that was not previously contacted by the app, especially when occurring without user interaction, in background state, or immediately after app initialization or scheduled execution. This sequence reflects resolver retrieval followed by dynamic C2 resolution.
Analyst context for executives and security teams
This Android detection analytic matters because it focuses on mobile apps that appear to use a legitimate public web platform as a resolver before connecting to a newly seen destination. For executives and security leaders, the business issue is not the first web request by itself; it is the chained behavior that may hide command-and-control destination discovery behind normal-looking public web traffic. This can create gaps in mobile monitoring, incident triage, and evidence collection if teams only inspect final network connections or only allowlist well-known web platforms without correlation.
Executive priority
Prioritize validation where Android devices or managed mobile apps are important to business operations, regulated workflows, executive communications, or field activity. Leaders should ask whether mobile network telemetry can connect app-attributed requests to subsequent outbound destinations within short time windows, and whether the SOC can distinguish normal app startup/background behavior from unusual pivots to previously unseen domains or IPs. This analytic is most useful as a resilience and investigation-control check: can the organization prove what app made the request, what it retrieved, and where it connected next?
Technical view
For SOC, detection engineering, and incident response teams, the core validation is correlation: an Android app makes a request to a legitimate public web platform, retrieves structured or encoded content, then quickly initiates an outbound connection to a different domain or IP that the app has not contacted before. The ATT&CK object does not provide a formal detection rule, so teams should build or test logic around app attribution, short time-window sequencing, destination novelty, background or no-user-interaction state, and timing after app initialization or scheduled execution. Tuning should account for benign apps that legitimately fetch configuration or content from public platforms and then connect to third-party services.
Likely telemetry
- Android app-attributed network connection logs
- DNS or domain resolution history by app or device
- HTTP/HTTPS request metadata to legitimate public web platforms
- Destination domain and IP reputation or first-seen history
- Mobile device state context such as foreground/background execution where available
Detection direction
- Validate that telemetry can link the initial public-platform request and the subsequent outbound connection to the same Android app, not just the same device.
- Use short time-window correlation rather than single-event alerting; the suspicious behavior is the sequence and pivot.
- Baseline previously contacted destinations per app so that newly derived or previously unseen domains/IPs can be identified.
- Tune for legitimate app behavior such as configuration retrieval, content delivery, analytics, or third-party service connections to reduce false positives.
- Prioritize cases occurring without user interaction, in background state, immediately after app initialization, or after scheduled execution when those fields are available.
Mitigation priorities
- Ensure mobile management, network, and logging controls can provide app-attributed Android network telemetry before relying on this analytic.
- Establish baselines of normal app destination patterns, especially for business-critical or managed apps.
- Apply mobile app governance and review processes for apps that execute background network activity or contact unusual/new destinations.
- Use network policy, mobile threat defense, or secure web controls where available to constrain or review unexpected outbound destinations from managed Android devices.
- Document telemetry retention and investigation procedures so incident responders can reconstruct the request-to-pivot sequence during a mobile investigation.
Analyst notes and limits
This is a detection analytic in the mobile ATT&CK domain for Android. The supplied ATT&CK description describes resolver retrieval followed by dynamic C2 resolution, but no ATT&CK tactics, relationships, aliases, labels, or official detection logic were supplied. The strongest defensive value comes from proving correlation quality across mobile app identity, timing, destination novelty, and execution/user-interaction context.
The object provides an analytic description but no official detection implementation, no relationship context, and no attributed threat or campaign information. Any assertion about maliciousness requires local evidence and tuning against normal Android app behavior. Coverage depends heavily on whether the organization can collect app-attributed mobile network telemetry and relevant device state context.
Analytic 1675
The defender correlates an app-attributed request to a legitimate public web platform with a subsequent outbound connection to a newly derived or previously unseen destination within a short time window. The behavior is strengthened when the initial request retrieves structured or encoded content followed by a pivot to a different domain or IP that was not previously contacted by the app, especially when occurring without user interaction, in background state, or immediately after app initialization or scheduled execution. This sequence reflects resolver retrieval followed by dynamic C2 resolution.
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 | 69a61b5ee2ed… |
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 AN1675Open 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.