AN1667: Analytic 1667
Monitor for pseudo-randomly generated domain names based on frequency analysis, Markov chains, entropy, proportion of dictionary words, ratio of vowels to other characters, and more.[1] Additionally, check if the suspicious domain has been recently registered, if it has been rarely visited, or if the domain had a spike in activity after being dormant.[2] Content delivery network (CDN) domains may trigger these detections due to the format of their domain names.
Analyst context for executives and security teams
Analytic 1667 is a mobile ATT&CK detection analytic for Android environments focused on suspicious domain names that look pseudo-random or abnormal, such as possible domain-generation behavior. Its business value is in validating whether mobile DNS and network monitoring can surface unusual command-and-control-style naming patterns before they become an incident investigation blind spot. The ATT&CK text also warns that CDN domains can resemble these patterns, so this is a signal that needs tuning, not a standalone verdict.
Executive priority
Prioritize this where Android devices are material to operations, regulated access, executive mobility, field work, or bring-your-own-device risk. Leaders should ask whether mobile DNS activity is visible to the SOC, whether suspicious or newly active domains can be investigated quickly, and whether the organization can distinguish high-risk domain anomalies from normal CDN traffic. This analytic supports resilience and compliance evidence by showing that mobile network activity is monitored for abnormal external destinations, but it requires local telemetry and tuning to be defensible.
Technical view
For SOC and detection engineering teams, validate collection and analysis of Android-related DNS or proxy traffic for domain features such as entropy, character distribution, dictionary-word proportion, vowel ratios, rarity, recent registration, dormant-domain reactivation, and sudden activity spikes. Because no ATT&CK tactic or formal detection logic is supplied, treat this as a detection strategy pattern rather than a complete rule. IR teams should ensure alerts preserve enough context to pivot from the domain to device, user, app, timestamp, resolver, and observed traffic volume.
Likely telemetry
- Android device DNS queries or resolver logs
- Mobile proxy, secure web gateway, VPN, or network egress logs where Android traffic is routed
- Domain reputation, registration age, and passive DNS or visit-frequency context
- Historical DNS trend data showing rare visits, dormant domains, or activity spikes
- Alert enrichment showing device, user, application, timestamp, queried domain, and response details
Detection direction
- Validate that Android DNS activity is actually observable; mobile devices using external networks, private DNS, VPN split tunneling, or unmanaged connectivity may bypass enterprise collection.
- Use feature-based domain analytics as a triage signal, including entropy, Markov-like structure, dictionary-word proportion, and vowel/consonant ratios, rather than as a standalone maliciousness decision.
- Enrich suspicious domains with recency, rarity, historical activity, and dormant-to-active behavior, as described in the ATT&CK analytic references.
- Tune for known benign CDN and cloud-hosted domains because ATT&CK explicitly notes CDN naming formats may trigger these detections.
- Measure false positives and analyst workload before promoting the analytic to high-severity alerting.
Mitigation priorities
- First, confirm mobile DNS and egress telemetry coverage for Android devices that access business resources.
- Next, standardize enrichment for domain age, reputation, rarity, and historical traffic trends so alerts are actionable.
- Then, define investigation playbooks for suspicious mobile domain activity, including device/user identification and app-level context where available.
- Maintain allowlists or suppression logic for validated CDN patterns while avoiding broad exclusions that remove visibility into rare or newly active domains.
- Use findings to inform mobile security policy, managed detection scope, and incident response readiness rather than treating the analytic as a preventive control by itself.
Analyst notes and limits
This object is a detection analytic, not a technique, and no relationship context was supplied. The practical value is in coverage validation: whether Android DNS/network telemetry and domain-enrichment data exist, are retained, and can be correlated during investigation. The strongest tuning consideration from the official text is CDN-related false positives.
The official object provides a description but no formal detection logic, tactic mapping, relationships, or ATT&CK mitigations. It supports Android only. Local network architecture, mobile management model, DNS routing, enrichment sources, and baseline traffic patterns are required to assess feasibility and expected alert quality.
Analytic 1667
Monitor for pseudo-randomly generated domain names based on frequency analysis, Markov chains, entropy, proportion of dictionary words, ratio of vowels to other characters, and more.[1] Additionally, check if the suspicious domain has been recently registered, if it has been rarely visited, or if the domain had a spike in activity after being dormant.[2] Content delivery network (CDN) domains may trigger these detections due to the format of their domain names.
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 | 02b6a077579b… |
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]
Data Driven Security DGA
Jacobs, J. (2014, October 2). Building a DGA Classifier: Part 2, Feature Engineering. Retrieved February 18, 2019.
Open source URL -
[2]
unit42_strat_aged_domain_det
Chen, Z. et al. (2021, December 29). Strategically Aged Domain Detection: Capture APT Attacks With DNS Traffic Trends. Retrieved July 31, 2023.
Open source URL -
[3]
mitre-attack AN1667Open 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.