Blocking an attacker's domain inside your own network protects only your users; getting the domain suspended at the registrar or registry stops it working for everyone, including customers and partners you cannot reach. MITRE D3FEND names this countermeasure Domain Registration Takedown (D3-DRT) and defines it as "The process of performing a takedown of the attacker's domain registration infrastructure." It sits under the Evict tactic as a child of Object Eviction (D3-OE). This card explains the takedown routes that exist for generic top-level domains, what the registrar and registry are obliged to do under ICANN's contracts, how to build a report they can act on, how to confirm a domain is actually out of service, and why takedown is slow and partial. It is written for incident responders, threat intelligence analysts and brand protection teams dealing with phishing, lookalike and command and control domains.
Key takeaways
- Evidence decides the outcome. D3FEND's considerations and ICANN's compliance advisory say the same thing: a report must show clearly, with evidence, that the domain is used for abuse or breaches the provider's terms.
- gTLD registrars have contractual duties. Since the 5 April 2024 amendments, a registrar with actionable evidence of DNS Abuse (malware, botnets, phishing, pharming, and spam that delivers them) must promptly take mitigation action reasonably necessary to stop or disrupt it.
- Escalate in a fixed order. Hosting or DNS provider, then registrar, then the TLD registry, with government and industry channels in parallel. D3FEND names the registry as the escalation path when a registrar does not act.
- Trademark cases use a different route. Lookalike domains with no live abuse often need a dispute process such as the UDRP, which can cancel, suspend or transfer a domain after a decision.
- Verify with registration data and DNS. A takedown is done when RDAP shows a hold status such as clientHold or serverHold and the name no longer resolves, not when the registrar replies.
D3-DRT at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DRT (d3f:DomainRegistrationTakedown) |
| Tactic | Evict |
| Parent technique | Object Eviction (D3-OE) |
| Digital artefact | Domain Registration (the D3FEND ontology states the technique deletes Domain Registration; the website's artefact diagram for the technique is empty) |
| Abuse examples named by D3FEND | Typosquatting or URL hijacking used in phishing; domains used in command and control beacons |
| D3FEND reference | Hao et al., "Understanding the Domain Registration Behavior of Spammers" |
| Effort | Low to prepare a report; elapsed time ranges from hours to weeks and is outside your control |
| Main limitation | Depends on third parties; attackers register replacement domains quickly |
How it works
D3FEND describes the process plainly. Most nameserver hosts and registrars provide service under terms that protect against abuse and trademark infringement. A registration data lookup on the attacker's domain identifies the abuse contact, and a formal takedown request asks the provider to suspend or disable the domain. Its considerations add four points: notifications should demonstrate with evidence that the terms have been breached; takedown is "notoriously slow and sometimes unsuccessful"; government organisations may run their own takedown processes and use the information to help others; and TLD registries offer an escalation path when the registrar or host does not respond in time.
D3FEND's reference explains why takedown is never the whole answer. Hao and colleagues studied .com zone changes and found that spammers register domains in bulk, often reuse previously registered domains and concentrate on a small set of registrars. A takedown removes one domain; the next is usually ready.
Registration data: RDAP replaces WHOIS
D3FEND's text refers to WHOIS, and its Domain Registration artefact notes that registration data is retrieved by the Registration Data Access Protocol (RDAP) or its predecessor, WHOIS. ICANN states that from 28 January 2025 gTLD registries and registrars are no longer required to provide WHOIS services, except for .com, .name and .post. Use RDAP, for example through ICANN's lookup tool, to find the sponsoring registrar, its abuse contact and the domain's current status codes.
ICANN obligations that make takedown work
For generic top-level domains, the registrar and registry are bound by ICANN contracts. The obligations below come from the 2013 Registrar Accreditation Agreement (RAA) and ICANN's February 2024 compliance advisory on the 5 April 2024 DNS Abuse amendments. Country-code TLDs set their own policies, so check the ccTLD registry's own abuse page.
| Party | Obligation | Source |
|---|---|---|
| Registrar | Maintain an abuse contact, publish an abuse reporting email address on its home page, and take reasonable and prompt steps to investigate and respond appropriately to reports of abuse | RAA section 3.18.1 |
| Registrar | Keep a dedicated abuse contact monitored around the clock for law enforcement and similar authorities; review well-founded reports of Illegal Activity from them within 24 hours | RAA section 3.18.2 |
| Registrar | Publish abuse handling procedures and keep records of responses | RAA section 3.18.3 |
| Registrar | On actionable evidence of DNS Abuse, promptly take the appropriate mitigation actions reasonably necessary to stop or otherwise disrupt it; confirm receipt of each report to the reporter | 2024 amendments, as described in ICANN's compliance advisory |
| Registry operator | Publish abuse contacts; on actionable evidence, promptly take appropriate mitigation, at minimum referring the domain and evidence to the sponsoring registrar or acting directly where appropriate; confirm receipt | 2024 amendments, as described in ICANN's compliance advisory |
ICANN's advisory does not set a fixed deadline for mitigation; promptness depends on the circumstances. One of its examples describes a registrar suspending a phishing domain with no legitimate content (clientHold) within two business days, and another describes a compromised legitimate domain where suspension would cause too much collateral damage, so the registrar instead told the registrant to remove the abusive content by a deadline.
ATT&CK context
Relationship type: none in D3FEND. D3FEND 1.6.0 shows no ATT&CK relations for D3-DRT (checked November 2026). The table below is NHI Mgmt Group's view of where a takedown applies, built from the abuse examples D3FEND names. It is not a D3FEND mapping. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Takedown fit (our view) |
|---|---|---|
| T1583.001 | Acquire Infrastructure: Domains | Primary case: a domain the attacker registered, suspended at registrar or registry |
| T1584.001 | Compromise Infrastructure: Domains | A hijacked legitimate domain; the owner, not suspension, is usually the right fix |
| T1566.002 | Phishing: Spearphishing Link | Suspending the link domain stops further victims after the emails are delivered |
| T1071.001 | Application Layer Protocol: Web Protocols | Suspending a C2 domain cuts beaconing for implants that rely on it |
| T1568 | Dynamic Resolution | A limit: domain generation and fast flux make single-domain takedown ineffective |
Choosing the takedown route
| Situation | Route | Typical result |
|---|---|---|
| Live phishing, malware or C2 on an attacker-registered gTLD domain | Abuse report to the registrar, escalating to the registry | Suspension, often by hold status |
| Abusive content on a compromised legitimate site | Report to the hosting provider and the site owner | Content removed; domain stays up |
| Lookalike domain with no active abuse yet | Monitor; trademark dispute such as the UDRP through an approved provider | After a decision, cancellation, suspension or transfer |
| Registrar does not respond | Registry abuse contact, then an ICANN Contractual Compliance complaint for gTLDs | Registry referral or direct action |
| Serious crime or national-level campaign | Law enforcement or national CERT, which have their own channels | Priority handling; intelligence shared with other victims |
The operational detail for lookalike and brand cases is in the Brand Impersonation and Lookalike Domain Takedown Playbook; for lookalike monitoring and defensive registration see the Domain Portfolio and Lookalike Domain Management Guide.
Implementation steps
- Block internally first. Add the domain to resolver and proxy denylists so your own users are protected while the takedown runs. Takedown is for everyone else.
- Collect actionable evidence. Following ICANN's advisory, include the full URL where the abuse appears, screenshots showing what the page imitates, timestamps, and for malware or C2 the observed indicators. Preserve copies under evidence handling rules; see the Evidence Handling and Chain of Custody Guide.
- Look up registration data. Use RDAP to identify the sponsoring registrar, its abuse contact, the registry, the name servers and the current status codes. Record them.
- Report to the right parties in parallel. Send the report to the registrar abuse contact and to the hosting or DNS provider. Keep the receipt confirmation the registrar is required to send.
- Escalate on a timer. If nothing changes within your defined window, report to the registry operator, then file an ICANN compliance complaint for gTLDs. Share indicators with your sector information sharing community; see the ISACs and Information Sharing Communities Guide.
- Watch for the replacement. Hunt for newly registered domains with the same pattern, registrar or name servers, and feed them back into blocking and reporting.
How to verify it works
- Status codes: RDAP shows clientHold (set by the registrar) or serverHold (set by the registry). Both keep the domain out of DNS, according to ICANN's EPP status code reference.
- Resolution: queries for the name return NXDOMAIN from public resolvers once cached answers have expired.
- Traffic: internal telemetry shows no further resolution or connection attempts succeeding, and any implant beaconing to the domain fails.
- Persistence: check again after 30 days. A deleted domain passes through redemptionPeriod and pendingDelete and can then be registered again, possibly by the same actor.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Median time from report to suspension | Tracked per registrar and TLD | Shows which providers respond and where to escalate sooner |
| Reports resulting in suspension | Rising quarter on quarter | Measures evidence quality |
| Time from detection to internal block | Under one hour | Protects your users regardless of takedown speed |
| Replacement domains detected within 7 days of a takedown | Tracked per campaign | Shows whether the actor is still active |
Limits, bypasses and failure patterns
- Weak reports: a report that only says "this is phishing" without the URL and evidence gives the registrar nothing to verify, and is the most common reason for delay.
- Takedown instead of blocking: waiting for suspension while users can still reach the domain internally.
- Collateral damage: suspending a compromised legitimate domain harms its owner; registrars may rightly choose content removal instead.
- Infrastructure churn: bulk registration and dynamic resolution mean the next domain is ready. Takedown buys time; detection and blocking carry the load.
- Tipping off the actor: a takedown during an active investigation may prompt the actor to move infrastructure. Coordinate timing with the investigation lead.
- Your own domains: if the abused domain is yours, through a hijacked registrar account, the problem is account security, not takedown. Registrar accounts and their API keys are non-human access paths worth protecting; see the Authoritative DNS and Registrar Account Security Guide and the Domain Registrar Compromise Playbook.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IR-4 Incident Handling | Containment and eradication activities, including action through external parties |
| NIST SP 800-53 Rev 5 | IR-7 Incident Response Assistance | Using external support and reporting channels |
| NIST CSF 2.0 | RS.MI-01, RS.MI-02 | Incidents are contained; incidents are eradicated |
| MITRE D3FEND | D3-OE, D3-DRT | Parent and technique |
Related countermeasures
- DNS Cache Eviction (D3-DNSCE): removes cached answers for the domain inside your network. See D3-DNSCE DNS Cache Eviction.
- Domain Name Reputation Analysis (D3-DNRA) and Homoglyph Detection (D3-HD): find the domains to take down. See D3-DNRA Domain Name Reputation Analysis and D3-HD Homoglyph Detection.
- DNS Denylisting (D3-DNSDL): the internal block that runs while takedown is pending.
- Object Eviction (D3-OE) is the parent class; the wider model is in the MITRE D3FEND Guide.
Practitioner checklist
- Block the domain internally before or alongside any takedown request.
- Use RDAP, not WHOIS, to find the registrar, registry, abuse contact and status codes.
- Include the full URL, screenshots, timestamps and indicators in every report.
- Keep the registrar's receipt confirmation and record every contact.
- Escalate to the registry and then ICANN compliance on a defined timer.
- Coordinate takedown timing with any active investigation.
- Confirm suspension through hold status and NXDOMAIN, and recheck after 30 days.
- Hunt for replacement domains with the same registration pattern.
Standards and references
- MITRE D3FEND: Domain Registration Takedown (D3-DRT)
- ICANN: Advisory on Compliance With DNS Abuse Obligations in the RAA and the Registry Agreement
- ICANN: 2013 Registrar Accreditation Agreement
- ICANN: Registration Data Access Protocol (RDAP)
- ICANN: EPP Status Codes
- ICANN: Uniform Domain-Name Dispute-Resolution Policy
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Brand Impersonation and Lookalike Domain Takedown Playbook · Domain Portfolio and Lookalike Domain Management Guide · DNS Security Guide · MITRE D3FEND Guide