Compromise Infrastructure: DNS Server (T1584.002) is a resource development technique tagged PRE. The adversary compromises a DNS server that belongs to someone else, instead of running their own.
DNS control is quiet power. Whoever answers the question decides where the traffic goes.
How attackers use it
MITRE notes that adversaries use DNS traffic for tasks after compromise, including command and control through application layer protocols. Instead of setting up their own DNS servers, they may compromise third-party ones.
Once they control a DNS server, they can alter records. MITRE says this can redirect an organization's traffic, enabling collection and credential access. Combined with digital certificates, redirected traffic can lead to infrastructure the adversary controls while looking like normal trusted network communication.
The page lists two more consequences. The adversary may prove ownership of a domain to a SaaS service in order to assert control of that service or create a new administrative cloud account. They may also silently create subdomains pointed at malicious servers without tipping off the real owner of the DNS server.
How to detect it
MITRE suggests monitoring DNS registry data that may indicate compromise of third-party DNS servers, and notes that most of the activity is outside your visibility. Effort should go to related stages such as command and control.
For defenders who run or depend on DNS:
- Baseline your authoritative records and alert on additions or changes you did not make.
- Review certificates issued for your names, since MITRE links redirection to certificate use.
- Watch for SaaS tenants being verified against your domains by someone you do not know. A new administrative account in a SaaS service is a sign worth checking.
- If a provider hosts your DNS, ask what change logging and alerting they offer.
How to reduce the risk
MITRE lists Pre-compromise as the mitigation, with no easy preventive control. General practice for the owner side:
- Limit who can edit DNS at your provider and require strong authentication for those accounts.
- Turn on change notifications and send them to a monitored shared mailbox.
- Keep the list of SaaS domain verifications current and remove those you no longer use.
- Review third-party DNS providers as you would any critical supplier.
A final suggestion is to rehearse the recovery. If your DNS were altered tonight, who could restore the records, and from what copy? Keep an exported, dated copy of your zone data somewhere other than the DNS provider, and test that you can import it. The time to find a gap in that process is before you need it.
Check your own environment
- Export your zone data and keep a dated copy for diffing.
- Linux or macOS, read-only:
dig +short NS example.comlists the name servers for a zone. Replace the name with yours. - Find out who has edit access at each DNS provider and whether each account has strong authentication.
- Search your SaaS admin lists for domain verification entries and confirm each is yours.
Quick check
What could a compromised DNS server let an adversary do to your traffic?
Alter records so traffic is redirected, enabling collection and credential access.
How might DNS control help in taking over a SaaS service?
The adversary may prove ownership of the domain to the SaaS provider and then assert control or create a new administrative cloud account.
