Adversaries may gather information about the network domains a victim owns. MITRE lists this under Reconnaissance with platform PRE. The details include which domains the victim owns, administrative data such as name and registrar, and directly useful data such as contacts, business addresses, and name servers.
How attackers use it
MITRE says this can happen through direct collection, such as active scanning or phishing for information, or through accessible data sets such as WHOIS.
It adds an example for cloud services. Where third party cloud providers are in use, domain information may be exposed through public API endpoints, with GetUserRealm and autodiscover in Office 365 given as examples.
The results can lead to searching open technical databases and websites, to acquiring or compromising infrastructure, and to phishing.
Registration data tends to age badly. Contacts leave, domains pile up, and name servers point at services that were retired years ago. Each of those details can help an attacker learn how you work, or find a domain that can be taken over.
The cloud endpoint example is a reminder that some of this information comes from the vendor and not from you. You can limit what you publish, but you cannot always control what a provider's public interface says about your tenant.
How to detect it
MITRE notes that this activity may have a very high occurrence and false positive rate, and may take place outside your visibility, which makes detection difficult. Its advice is to focus on related stages of the adversary lifecycle, such as initial access.
For the cloud endpoint case, look at web and identity logs for high volumes of requests to discovery endpoints from one source. For registrar data there is nothing to log, because the queries go to a third party.
Keep an eye on your own domain list. Registrar notifications for transfers, contact changes, and expiries are a form of detection, so make sure they go to a monitored mailbox.
How to reduce the risk
- MITRE says this technique cannot be easily mitigated with preventive controls, because it is based on behaviors performed outside the scope of enterprise defenses and controls. Its guidance is to minimize the amount and sensitivity of data available to external parties.
- Check the registration data for each domain you own. Prefer role based contact addresses over named individuals.
- Use the registrar's privacy options where they are available and fit your policy.
- Keep a register of every domain you own, including old ones, and renew or retire them deliberately.
- Review which cloud services answer public discovery requests for your tenants.
- Protect registrar accounts with strong authentication, since this data is part of controlling the domain.
Lock domains against transfer where the registrar offers it, and keep payment details current so nothing expires by accident. A lapsed domain can be registered by someone else.
Check your own environment
A read-only lookup of what the world can see, using whois on Linux or macOS for a domain you own:
whois yourdomain.com
dig +short NS yourdomain.com
Review the output as an outsider would.
- Do contact fields name a person who has since left?
- Are all name servers ones we still run or pay for?
- Do we know every domain registered to the company?
Quick check
What kind of data counts as domain properties?
Domains owned, registrar and administrative data, contacts, business addresses, and name servers.
Which cloud endpoints does MITRE mention?
GetUserRealm and autodiscover in Office 365 environments.
Sources
- MITRE ATT&CK, Domain Properties (T1590.001): https://attack.mitre.org/techniques/T1590/001
