AN2024: Analytic 2024
Monitor logged domain name system (DNS) data for purchased domains that can be used during targeting. Reputation/category-based detection may be difficult until the categorization is updated. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Initial Access and Command and Control. Domain registration information is, by design, captured in public registration logs. Consider use of services that may aid in tracking of newly acquired domains, such as WHOIS databases and/or passive DNS. In some cases it may be possible to pivot on known pieces of domain registration information to uncover other infrastructure purchased by the adversary. Consider monitoring for domains created with a similar structure to your own, including under a different TLD. Though various tools and services exist to track, query, and monitor domain name registration information, tracking across multiple DNS infrastructures can require multiple tools/services or more advanced analytics.[1] Detection efforts may be focused on related stages of the adversary lifecycle, such as during Initial Access and Command and Control. Monitor queried domain name system (DNS) registry data for purchased domains that can be used during targeting. Reputation/category-based detection may be difficult until the categorization is updated. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Initial Access and Command and Control.
Analyst context for executives and security teams
This analytic is about spotting domains an adversary may buy before using them for targeting, phishing, initial access, or command and control. The business value is early warning: if security teams can identify lookalike or newly registered infrastructure before it is used, they may have more time to protect users, tune detections, brief leadership, and prepare incident response. The key caveat is that reputation and category tools often lag behind new registrations, so relying only on domain reputation can leave a blind spot.
Executive priority
Treat this as a pre-incident visibility and brand/identity protection question: do teams have a way to monitor newly purchased domains that resemble the organization or appear connected to suspicious infrastructure? Leaders should ask whether threat intelligence, SOC, and incident response workflows can turn early domain-registration findings into practical actions, such as user warnings, detection tuning, blocking decisions, and evidence for risk and compliance discussions. This is most useful as a prioritization aid for Initial Access and Command and Control readiness, not as proof that an attack is underway.
Technical view
The supplied ATT&CK analytic focuses on logged and queried DNS registry data, WHOIS, passive DNS, and other domain-registration sources to identify purchased domains that may be used during targeting. SOC and detection teams should validate whether they can monitor newly acquired domains, pivot on registration attributes when available, and identify domains with structures similar to the organization’s own domains, including alternate top-level domains. Because no ATT&CK detection logic is provided and tactics are not specified, implementation should be treated as a detection-engineering requirement rather than a ready-made rule.
Likely telemetry
- WHOIS and public domain registration records
- Passive DNS data
- DNS registry query results
- Newly registered domain feeds or services
- Logs or alerts from domain-monitoring and threat-intelligence platforms
Detection direction
- Validate whether monitoring covers newly registered and newly acquired domains, not only domains already categorized as malicious.
- Tune for domains structurally similar to the organization’s domains, including different top-level domains, while accounting for legitimate third-party, partner, marketing, and regional domains.
- Where registration details are available, test whether analysts can pivot on shared registration attributes to find related infrastructure; document source limitations because registration data quality varies.
- Correlate suspicious domain-registration findings with later Initial Access and Command and Control telemetry where available, rather than treating registration alone as confirmation of compromise.
- Account for reputation lag: newly created domains may not yet have useful category or reputation labels.
Mitigation priorities
- Inventory authoritative organizational domains, common brand variants, and high-risk naming patterns to define what should be monitored.
- Establish a process for reviewing newly registered or lookalike domains and escalating credible findings to SOC, incident response, legal/brand protection, or risk owners as appropriate.
- Use findings to inform defensive actions such as detection tuning, user awareness, domain watchlists, and blocking decisions, subject to local validation and change-control requirements.
- Integrate domain-registration monitoring with threat intelligence and incident response workflows so early infrastructure signals can be tracked through later lifecycle stages.
- Periodically test coverage against known benign lookalike scenarios and internally owned alternate domains to reduce false positives and avoid unnecessary disruption.
Analyst notes and limits
This object is a detection analytic, not a technique description. It provides guidance for monitoring purchased domains using DNS registration-related data, WHOIS, passive DNS, and similar services. The only cited source is ThreatConnect’s infrastructure research and hunting reference, plus the ATT&CK analytic URL. There are no supplied relationships, aliases, labels, tactics, or explicit detection logic, so the take emphasizes validation questions and telemetry requirements rather than specific detections.
The supplied ATT&CK fields do not identify a specific adversary, campaign, active exploitation, impact level, or guaranteed detection method. Platform is listed as PRE, and tactics are not specified. Local domain inventory, DNS/provider coverage, passive DNS access, registration-data quality, and organizational response authority are required to determine actual usefulness.
Analytic 2024
Monitor logged domain name system (DNS) data for purchased domains that can be used during targeting. Reputation/category-based detection may be difficult until the categorization is updated. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Initial Access and Command and Control. Domain registration information is, by design, captured in public registration logs. Consider use of services that may aid in tracking of newly acquired domains, such as WHOIS databases and/or passive DNS. In some cases it may be possible to pivot on known pieces of domain registration information to uncover other infrastructure purchased by the adversary. Consider monitoring for domains created with a similar structure to your own, including under a different TLD. Though various tools and services exist to track, query, and monitor domain name registration information, tracking across multiple DNS infrastructures can require multiple tools/services or more advanced analytics.[1] Detection efforts may be focused on related stages of the adversary lifecycle, such as during Initial Access and Command and Control. Monitor queried domain name system (DNS) registry data for purchased domains that can be used during targeting. Reputation/category-based detection may be difficult until the categorization is updated. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Initial Access and Command and Control.
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 | 612da5080488… |
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]
ThreatConnect Infrastructure Dec 2020
ThreatConnect. (2020, December 15). Infrastructure Research and Hunting: Boiling the Domain Ocean. Retrieved October 12, 2021.
Open source URL -
[2]
mitre-attack AN2024Open 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.