Adversaries may gather information about a victim's DNS to use during targeting. MITRE lists this under Reconnaissance with platform PRE. DNS information includes registered name servers and records that show addressing for subdomains, mail servers, and other hosts.
MITRE adds that MX, TXT, and SPF records can reveal third party cloud and SaaS providers, such as Office 365, G Suite, Salesforce, or Zendesk. That is useful to anyone planning a phishing campaign or looking for the weakest vendor.
How attackers use it
Adversaries may collect this by querying DNS or passive DNS, or from other accessible data sets such as open technical databases. MITRE also describes DNS zone transfer, query type AXFR, as a way to collect all records from a misconfigured DNS server.
A zone transfer is meant for replication between trusted name servers. If a server answers it for anyone, the full list of records goes to whoever asks.
What the adversary learns can feed more reconnaissance, such as scanning or database searches, the acquisition or compromise of infrastructure, and initial access through external remote services.
Two details in MITRE's text deserve attention. The first is the mention of third party providers. A TXT record that proves ownership to a SaaS vendor, or an SPF entry that authorizes a mail service, tells a reader which vendors you use. For a phishing author that is a gift, because they can imitate a message from a real provider.
The second is zone transfer. DNS was built so that secondary servers can copy a zone from the primary. If the primary is set to answer any requester, the entire set of records, internal looking host names included, can be pulled in one request. It is a configuration slip, not a software flaw, which is why MITRE's mitigation is a configuration policy.
The wider point is that DNS is a published map. You cannot remove it, but you can decide what goes on it.
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 zone transfers you do have a direct signal. Your own DNS servers log transfer requests, and a request from an address that is not one of your secondary servers is worth an alert. Check the logging options of your DNS software.
For ordinary lookups there is little to see. Public records are meant to be public, and passive DNS queries go to third parties.
Two other habits help. Keep an inventory of your own records so you can tell stale or forgotten entries, and review which of them point to services you no longer use.
Review DNS server logs for a second class of signal: unusual query volume from one source, especially a run of queries for many different host names under your domain. That can indicate guessing of subdomain names. Log volume on a public name server can be large, so start with a count of queries by source address over a day.
Also review changes to your own records. An unexpected new record, especially one that points a host name at an address you do not recognize, deserves a call to whoever owns DNS changes. Reconnaissance information is most dangerous when it meets a forgotten record that can be taken over.
How to reduce the risk
- MITRE's mitigation for this sub-technique is a software configuration one. It suggests implementing policies for DNS servers, such as zone transfer policies, that enforce a list of validated servers permitted for zone transfers.
- Restrict zone transfers to the named secondary servers and nothing else.
- Remove records for retired hosts and services, so there is less to find and less to take over.
- Keep internal names out of public DNS where you can. Split horizon setups help here.
- Review TXT and SPF records and remove entries for vendors you no longer use.
- Accept that the basics remain public. 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.
A good routine is to export your zone every quarter and read it line by line. For each record, name the owner and the purpose. Anything with neither is a candidate for removal.
Keep DNS account access narrow and protected with strong authentication, and require review for changes. The information in the zone is only one part of the risk; the ability to change it is the other.
Check your own environment
A read-only test of your own zone transfer policy using dig on Linux or macOS. Only run it against name servers you operate.
dig NS yourdomain.com +short
dig AXFR yourdomain.com @ns1.yourdomain.com
A properly configured server should refuse the transfer. If it returns records, restrict transfers right away.
Then check the public view of your mail and vendor records:
dig +short MX yourdomain.com
dig +short TXT yourdomain.com
Questions to ask while you read the output:
- Which vendors can an outsider infer from our TXT and SPF records?
- Are there records for hosts we retired?
- Do any internal host names appear in public DNS?
- Who owns the DNS change process, and is it reviewed?
Quick check
What does MITRE suggest as the mitigation for DNS reconnaissance?
DNS server policies such as zone transfer policies that allow transfers only to a list of validated servers.
What can MX, TXT, and SPF records reveal?
The use of third party cloud and SaaS providers, such as Office 365, G Suite, Salesforce, or Zendesk.
What is AXFR?
The DNS query type for a zone transfer, which MITRE says can be used to collect all records from a misconfigured DNS server.
Sources
- MITRE ATT&CK, DNS (T1590.002): https://attack.mitre.org/techniques/T1590/002
