Compromise Infrastructure: Domains (T1584.001) is a resource development technique, tagged PRE. It covers three related problems: registration hijacking, subdomain hijacking and domain shadowing.
All three give the adversary something valuable: a name that people and security tools already trust. Of the compromise infrastructure techniques, this is the one where ordinary DNS hygiene pays off most directly.
How attackers use it
MITRE describes the three variants.
Domain registration hijacking is changing the registration of a domain without the registrant's permission. According to MITRE, an adversary may gain access to the email account of the listed owner and claim to have forgotten the password, in order to change the registration. Other routes include social engineering a registration help desk, exploiting gaps in the renewal process, and compromising a cloud service that manages domains, such as AWS Route53.
Subdomain hijacking happens when DNS entries point to resources that no longer exist or have been deprovisioned. An adversary may take control of the subdomain and operate under the trust of the parent domain.
Domain shadowing is when an adversary who has compromised a domain creates malicious subdomains under their control while keeping the existing DNS records. Service is not disrupted, so the malicious subdomains may go unnoticed for long periods.
The weak point in each case is process, not technology: an email account, a help desk, a renewal date, a stale record.
How to detect it
MITRE suggests monitoring logged DNS registry data for signs of hijacked domains and subdomains. In some cases, abnormal subdomain IP addresses, such as addresses in a different country from the root domain, may indicate a malicious subdomain.
It also recommends monitoring for anomalous changes to domain registrant information or domain resolution information, with the caution that benign changes are common and that efforts may need to be tailored to domains of special interest.
MITRE adds that much of this happens outside your visibility and suggests focusing on related lifecycle stages such as command and control.
Turning that into routine checks:
- Keep a record of every DNS record in your zones and diff it on a schedule. New subdomains that nobody requested are the signature of domain shadowing.
- Compare subdomain addresses against the network ranges you actually use. An address that belongs to an unrelated provider in another country is worth a question.
- Watch registrar notices, such as contact changes, name server changes and transfer requests, and send them to a shared mailbox that several people read.
- Review the certificates issued for your names. An unexpected certificate for a subdomain suggests someone controls it.
How to reduce the risk
MITRE's mitigation is Pre-compromise, with the usual note that preventive controls cannot easily stop behavior outside enterprise defenses.
The weak points MITRE names give you a to-do list. These steps are general practice.
- Protect the email account on the registrant contact as if it were an admin account. MITRE says compromising it is one path to hijacking.
- Brief the people who talk to your registrar so that a help desk social engineering attempt fails.
- Track renewal dates and auto-renew where you can, because renewal gaps are another path MITRE lists.
- Secure cloud consoles that manage DNS, with strong authentication and limited roles.
- Delete DNS records the moment the resource behind them is retired. This is the direct fix for subdomain hijacking.
- Write down who owns each domain, and review the list every quarter.
A worked example shows why small gaps matter. Imagine a marketing team that launched a campaign site on a subdomain pointing at a third-party hosting service. The campaign ended, the hosting account was closed, and nobody removed the DNS record. The name still resolves through a CNAME to a resource that no longer exists. That is exactly the situation MITRE describes for subdomain hijacking. Anyone who can claim that resource name at the hosting provider can now serve content under your trusted name.
The fix is not clever. Tie DNS changes to the same ticket that closes the hosting account. Add a step to your offboarding checklist for every external service: remove the record first, then close the account. Run a periodic report that resolves every CNAME in your zones and flags those whose targets fail to resolve.
The same discipline guards against shadowing. If every legitimate record has an owner and a ticket, a record without either stands out. Then the weekly diff becomes a quick review and not an archaeology project.
Finally, keep an eye on who can edit DNS. The smaller that group, and the stronger its authentication, the fewer ways in an adversary has.
If you want a single metric, track the number of DNS records without a named owner. The goal is zero, and the number tells you how far you are.
Check your own environment
- Export your DNS zones and list every CNAME. For each target, confirm that the resource still exists and that you still own it.
- Linux or macOS, read-only:
dig +short CNAME shop.example.com, thendig +short Aon the target. Replace the names with yours. - Compare the name servers in
whois example.comwith the ones you configured. - Confirm that registrar accounts use strong authentication and that the contact email has it too.
- Check expiry dates for every domain, including old campaign domains that nobody remembers.
- List which cloud accounts and roles can edit DNS.
Quick check
What is domain shadowing?
Creating malicious subdomains under a compromised domain while leaving the existing records alone, so service continues and the extras may go unnoticed.
How can subdomain hijacking happen?
When DNS entries point to non-existent or deprovisioned resources, an adversary can claim the resource and control the subdomain.
What sign of a malicious subdomain does MITRE mention?
An abnormal IP address, such as one in a different country from the root domain.
