T1590.001: Domain Properties
Adversaries may gather information about the victim's network domain(s) that can be used during targeting. Information about domains and their properties may include a variety of details, including what domain(s) the victim owns as well as administrative data (ex: name, registrar, etc.) and more directly actionable information such as contacts (email addresses and phone numbers), business addresses, and name servers.
Adversaries may gather this information in various ways, such as direct collection actions via Active Scanning or Phishing for Information. Information about victim domains and their properties may also be exposed to adversaries via online or other accessible data sets (ex: WHOIS).[1][2][3] Where third-party cloud providers are in use, this information may also be exposed through publicly available API endpoints, such as GetUserRealm and autodiscover in Office 365 environments.[4][5] Gathering this information may reveal opportunities for other forms of reconnaissance (ex: Search Open Technical Databases, Search Open Websites/Domains, or Phishing for Information), establishing operational resources (ex: Acquire Infrastructure or Compromise Infrastructure), and/or initial access (ex: Phishing).
Analyst context for executives and security teams
Domain Properties is pre-compromise reconnaissance: an adversary collects public or accessible details about an organization’s domains, registrars, contacts, addresses, name servers, and cloud-domain indicators. This matters because the information can shape later targeting, phishing, infrastructure setup, or other reconnaissance before any internal alert fires.
Executive priority
Treat this as an attack-surface and exposure-management issue, not only a SOC detection problem. Leaders should ask whether public domain registration data, DNS records, business contact information, and cloud identity/domain discovery endpoints reveal more than the organization intends. The priority is to reduce unnecessary exposure, document what must remain public for business reasons, and ensure incident response and threat intelligence teams can recognize when domain-focused reconnaissance may precede phishing or initial access attempts.
Technical view
This ATT&CK sub-technique sits under Gather Victim Network Information and is mapped to the reconnaissance tactic on the PRE platform. MITRE does not provide official detection text, but a related detection strategy, DET0847 Detection of Domain Properties, is associated with the object. SOC and detection teams should validate whether they can observe external lookups or probing against domains, DNS infrastructure, WHOIS-style records, and cloud identity/domain availability or autodiscover-style endpoints where applicable. Because much of the activity can occur through third-party public datasets, detection will often depend on external monitoring, DNS/cloud logs, and threat intelligence context rather than endpoint telemetry alone.
Likely telemetry
- Public DNS and passive DNS observations for owned domains and name servers
- Registrar and WHOIS/RDAP records, including administrative contacts and registration metadata
- Cloud identity or SaaS domain discovery endpoint logs where available, including Office 365/Azure-related domain realm or autodiscover activity when used
- Web, DNS, and API access logs for externally exposed domain-related services
- Threat intelligence or external attack-surface monitoring reports showing domain enumeration or newly observed references to company domains
Detection direction
- Validate what DET0847 or equivalent monitoring actually covers, since MITRE provides no official detection procedure in the supplied object.
- Correlate unusual domain, DNS, registrar, and cloud-domain discovery interest with other reconnaissance patterns such as active scanning, searches of technical databases, searches of public websites/domains, or phishing-for-information activity referenced by ATT&CK.
- Expect limited visibility when adversaries use public WHOIS, DNS Dumpster-like services, passive DNS datasets, or other accessible repositories; compensate with external attack-surface monitoring and periodic exposure reviews.
- Tune carefully: domain lookups, DNS queries, and cloud autodiscover-style requests can be legitimate business, partner, administrator, or customer activity. Prioritize unusual volume, rare sources, sensitive domains, and activity that aligns with other suspicious pre-compromise signals.
- For cloud environments, confirm whether logs exist for publicly reachable domain or identity discovery endpoints before assuming the SOC can detect this behavior.
Mitigation priorities
- Apply pre-compromise controls: reduce unnecessary public exposure and make reconnaissance less useful to an adversary.
- Maintain an authoritative inventory of owned domains, name servers, registrar relationships, and cloud tenant/domain configurations.
- Review public registration, DNS, and business contact data for unnecessary personal details, outdated contacts, or information that could aid phishing or targeting.
- Harden and monitor externally accessible cloud identity/domain discovery surfaces where the organization uses third-party cloud providers.
- Use exposure-management findings to prioritize phishing readiness, domain governance, and incident-response playbooks for suspected reconnaissance-to-phishing chains.
Analyst notes and limits
The supplied relationships show this behavior is a sub-technique of T1590 Gather Victim Network Information, is mitigated by M1056 Pre-compromise, is detected by DET0847, and is used by Sandworm Team and AADInternals. Those relationships indicate relevance to pre-compromise reconnaissance and Azure AD/domain enumeration tooling, but they should not be interpreted as proof of current activity against any specific organization.
The ATT&CK object provides no official detection text, and much of the behavior may occur outside infrastructure controlled by the victim. Local conclusions require evidence from the organization’s DNS, registrar, cloud, SaaS, and external attack-surface monitoring sources. No active exploitation, customer exposure, or guaranteed detection coverage is implied by the supplied data.
Domain Properties
Adversaries may gather information about the victim's network domain(s) that can be used during targeting. Information about domains and their properties may include a variety of details, including what domain(s) the victim owns as well as administrative data (ex: name, registrar, etc.) and more directly actionable information such as contacts (email addresses and phone numbers), business addresses, and name servers.
Adversaries may gather this information in various ways, such as direct collection actions via Active Scanning or Phishing for Information. Information about victim domains and their properties may also be exposed to adversaries via online or other accessible data sets (ex: WHOIS).[1][2][3] Where third-party cloud providers are in use, this information may also be exposed through publicly available API endpoints, such as GetUserRealm and autodiscover in Office 365 environments.[4][5] Gathering this information may reveal opportunities for other forms of reconnaissance (ex: Search Open Technical Databases, Search Open Websites/Domains, or Phishing for Information), establishing operational resources (ex: Acquire Infrastructure or Compromise Infrastructure), and/or initial access (ex: Phishing).
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1590 | Gather Victim Network Information | This object subtechnique of Gather Victim Network Information. |
Groups, software, and campaigns
G0034: Sandworm Team
Sandworm Team is a destructive threat group that has been attributed to Russia's General Staff Main Intelligence Directorate (GRU) Main Center for Special Technologies (GTsST) military unit 74455.[1][2] This group has been active since at least 2009.[3][4][5][6]
In October 2020, the US indicted six GRU Unit 74455 officers associated with Sandworm Team for the following cyber operations: the 2015 and 2016 attacks against Ukrainian electrical companies and government organizations, the 2017 worldwide NotPetya attack, targeting of the 2017 French presidential campaign, the 2018 Olympic Destroyer attack against the Winter Olympic Games, the 2018 operation against the Organisation for the Prohibition of Chemical Weapons, and attacks against the country of Georgia in 2018 and 2019.[1][2] Some of these were conducted with the assistance of GRU Unit 26165, which is also referred to as APT28.[7]
S0677: AADInternals
AADInternals is a PowerShell-based framework for administering, enumerating, and exploiting Azure Active Directory. The tool is publicly available on GitHub.[1][2]
All related ATT&CK context
Mitigation direction
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 | 2092bb2eda1d… |
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]
WHOIS
NTT America. (n.d.). Whois Lookup. Retrieved November 17, 2024.
Open source URL -
[2]
DNS Dumpster
Hacker Target. (n.d.). DNS Dumpster. Retrieved October 20, 2020.
Open source URL -
[3]
Circl Passive DNS
CIRCL Computer Incident Response Center. (n.d.). Passive DNS. Retrieved October 20, 2020.
Open source URL -
[4]
Azure Active Directory Reconnaisance
Dr. Nestori Syynimaa. (2020, June 13). Just looking: Azure Active Directory reconnaissance as an outsider. Retrieved May 27, 2022.
Open source URL -
[5]
Office 265 Azure Domain Availability
Microsoft. (2017, January 23). (Cloud) Tip of the Day: Advanced way to check domain availability for Office 365 and Azure. Retrieved May 27, 2022.
Open source URL -
[6]
mitre-attack T1590.001Open 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.