Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1668: Analytic 1668

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.

MobileAN1668AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

AN1668 is a mobile ATT&CK detection analytic for identifying suspicious iOS network activity where domain names look algorithmically generated or operationally unusual. The business value is not the domain-scoring math itself; it is whether the organization can recognize command-and-control-style DNS patterns before they become an incident-response blind spot. This matters for mobile fleet visibility because iOS devices often sit outside traditional endpoint logging, and DNS or network-layer evidence may be one of the few practical ways to spot suspicious communications.

Executive priority

Treat this as a visibility and resilience question: can security teams prove they collect and retain enough mobile DNS or proxy telemetry to investigate suspicious domain behavior from iOS devices? Leaders should prioritize this where mobile devices access sensitive business systems, regulated data, or executive communications. The analytic also highlights a budget and governance issue: domain reputation alone is not enough, because the description calls out recently registered, rarely visited, dormant-then-active, and pseudo-random domains as relevant signals, while warning that CDN domains can create false positives.

Technical view

For SOC, detection engineering, and IR teams, validate whether iOS network activity can be inspected at the DNS, secure web gateway, proxy, or network-monitoring layer. The analytic suggests scoring domain names using features such as entropy, Markov-chain or frequency-based characteristics, dictionary-word proportion, vowel ratios, recent registration, low historical visitation, and spikes after dormancy. Because official detection logic is not provided, teams should treat this as a detection design pattern rather than a ready rule. Tuning should explicitly account for CDN-style domains that may resemble generated strings.

Likely telemetry

  • DNS query logs associated with iOS devices where available
  • Proxy or secure web gateway logs showing requested domains from iOS traffic
  • Network flow or firewall metadata that can link mobile device traffic to domains or destinations
  • Domain registration or age enrichment data
  • Historical domain popularity, rarity, dormancy, or traffic-spike context

Detection direction

  • Confirm that iOS traffic is visible enough to associate suspicious domains with a device, user, or managed mobile profile.
  • Build or validate domain-feature analytics for pseudo-randomness, including entropy, character distribution, dictionary-word proportion, vowel ratios, and related lexical features.
  • Enrich detections with domain age, registration recency, rarity of visits, and sudden activity after dormancy, as described by the analytic.
  • Tune carefully for CDN domains and other legitimate services that use high-entropy or machine-generated-looking hostnames.
  • Measure alert quality with local baselines, because ATT&CK provides no official detection query, thresholds, or expected event schema for this analytic.

Mitigation priorities

  • Prioritize mobile network visibility for managed iOS devices before relying on this analytic operationally.
  • Use DNS, proxy, or gateway controls to support investigation and policy enforcement for suspicious or newly observed domains.
  • Maintain enrichment sources for domain age, registration status, historical activity, and rarity where feasible.
  • Document false-positive handling for CDN domains so analysts do not either over-escalate benign traffic or suppress the analytic too broadly.
  • Tie detections to incident-response playbooks that can identify the device, user, app context, and business system exposure.
Analyst notes and limits

This object is a detection analytic, not a technique or procedure. Its practical value is strongest where an organization has mobile DNS/proxy visibility and domain-enrichment capability. The supplied ATT&CK fields specify iOS as the platform and provide analytic intent, but no tactic, detection code, data component mapping, or relationships.

No official detection implementation, thresholds, tactic mapping, or relationship context was supplied. Conclusions are limited to the provided ATT&CK description and references. Local telemetry architecture, mobile device management posture, DNS privacy settings, and network routing will determine whether this analytic is feasible.

Official MITRE ATT&CK definition

Analytic 1668

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.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
7a852cdb33ee7a52...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 7a852cdb33ee…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [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. [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. [3]
    mitre-attack AN1668
    Open source URL
Source and licensing

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.