AN1699: Analytic 1699
Network traffic analysis may reveal processes communicating with malicious domains.
Analyst context for executives and security teams
This analytic matters because Android devices can create business risk when apps or processes communicate with known malicious domains. For leaders, the decision value is not that network monitoring is useful in theory, but whether mobile device traffic is visible enough to support timely investigation, containment, and compliance evidence when a suspicious domain contact occurs.
Executive priority
Prioritize validation of mobile network visibility for Android environments, especially where mobile devices access business identity, cloud applications, email, or sensitive data. The key executive question is whether the organization can identify which Android device or process contacted a malicious domain, determine business exposure, and support an incident response decision without relying on incomplete logs.
Technical view
SOC and IR teams should validate whether Android network traffic can be analyzed and correlated to device, user, application, and destination domain. Because the ATT&CK object provides no specific detection logic or tactic mapping, this should be treated as a coverage validation analytic rather than a complete rule. Detection engineering should focus on domain reputation matches, suspicious DNS or web connections, and correlation back to mobile device inventory and process or app context where available.
Likely telemetry
- Android device network connection logs
- DNS query logs involving Android devices
- Proxy, secure web gateway, or firewall logs for mobile traffic
- Mobile device management or mobile security telemetry that maps device, user, app, and process context
- Threat intelligence or malicious domain reputation feeds used for enrichment
Detection direction
- Confirm that Android-originated network traffic is actually captured when devices are on corporate, remote, or mobile networks.
- Validate that domain-based detections can be correlated to a specific device, user, and app or process where telemetry supports it.
- Tune alerts to account for domain reputation quality, parked domains, shared infrastructure, and stale threat intelligence to reduce false positives.
- Test whether encrypted traffic, private DNS, VPN use, split tunneling, or off-network mobile usage creates visibility gaps.
- Because no official detection logic is supplied, define local thresholds, enrichment requirements, and triage steps before treating this as operational coverage.
Mitigation priorities
- Establish reliable mobile network telemetry collection for Android devices that access enterprise resources.
- Maintain current malicious domain intelligence and document how it is applied to DNS, proxy, firewall, or mobile security controls.
- Ensure incident response playbooks include mobile-device triage, user notification, containment, and evidence preservation steps.
- Use identity and access controls to limit business impact if a mobile device is suspected of communicating with malicious infrastructure.
- Periodically review coverage as mobile network paths, device management posture, and remote access patterns change.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Android in the mobile domain. Its only behavioral statement is that network traffic analysis may reveal processes communicating with malicious domains. There are no supplied tactics, relationships, aliases, or official detection details, so this take emphasizes defensive validation and operational readiness rather than a specific adversary behavior or rule.
This assessment is limited to the official STIX fields, the MITRE external reference, and the absence of relationship context. It does not establish active exploitation, attribution, severity, or guaranteed detection. Local telemetry, device management coverage, network architecture, and threat intelligence quality are required to determine practical effectiveness.
Analytic 1699
Network traffic analysis may reveal processes communicating with malicious domains.
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.0 | Current bundle | 958956bc3f11… |
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 AN1699Open 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.