Lookalike Domain Takedown Playbook

A lookalike domain hosting a fake login page or sending invoices in your name can harvest credentials and money within hours, but takedowns stall when nobody knows who reports to the registrar, what evidence the host needs or how to protect staff and customers while the request is pending. This template gives [Organisation] a repeatable playbook for brand impersonation and lookalike domain incidents: confirming the threat, capturing evidence that providers will act on, blocking it internally, requesting removal from the registrar, host and browser blocklists, and escalating to dispute procedures when abuse reporting is not enough. It is written for security operations, threat intelligence, brand protection, legal and communications teams. Replace every [bracketed] placeholder before adoption. For background on how lookalikes are built and found, see the Typosquatting and Lookalike Domains Guide.

How to use this template

Use it for active impersonation: a domain, site, social account or app that imitates [Organisation] and is being used, or is ready to be used, for phishing, fraud, malware delivery or reputation damage. Proactive registration of defensive domains belongs in the Domain Portfolio and Lookalike Domain Management Guide.
Run it alongside related playbooks: if employees entered credentials, run the Phishing Incident Response Playbook; if payments were redirected, the Business Email Compromise Response Playbook; if your own domain or DNS was taken over, the Domain Registrar Compromise Playbook.
Keep evidence first: providers act on evidence, and sites disappear or change. Capture before you report.
Adapt timings: the targets below are starting points for [Organisation] to set; they are not provider commitments.

1. Scope and triggers

1.1 This playbook applies to domains, subdomains, websites, email sending infrastructure, social media accounts, mobile apps and paid search adverts that impersonate [Organisation], its brands, executives or suppliers.

1.2 Triggers include: staff or customer reports of a suspicious site or email; a DMARC aggregate or forensic report showing a lookalike sending domain; certificate transparency or new-domain monitoring alerts; brand protection service alerts; a fraud loss traced to an impersonating domain; threat intelligence reporting.

Severity	Criteria	Response target
Critical	Live credential harvesting, payment fraud or malware delivery targeting staff or customers, or confirmed victims	Triage within [1 hour]; all reports submitted within [4 hours]
High	Live site imitating [Organisation] login, support or payment pages with no confirmed victims yet	Triage within [4 hours]; reports within [1 business day]
Medium	Registered lookalike with mail (MX) records or a parked page, no content yet	Monitor; block internally; reassess on change
Low	Registered lookalike, no DNS or mail activity	Add to watchlist; consider defensive acquisition or dispute later

2. Roles and contacts

Role	Responsibility	Named owner
Incident lead	Severity, decisions, coordination, closure	[Name, deputy]
SOC analyst	Evidence capture, internal blocking, victim identification	[Team]
Threat intelligence	Infrastructure pivoting, related domains, campaign tracking	[Team]
Brand protection or takedown provider	Submits and chases abuse reports where contracted	[Provider, contract reference]
Legal counsel	Trademark position, UDRP or URS filings, cease and desist, law enforcement liaison	[Name]
Communications	Customer and staff warnings, media holding lines	[Name]
Fraud and customer service	Customer contact, loss handling, scripts	[Team]

2.1 Maintain a contact sheet with: [Organisation]'s own registrar account contacts; abuse contacts and web forms for registrars and hosts seen in past incidents; browser and security vendor reporting forms; national CERT or cyber agency reporting routes; the takedown provider's escalation path. Review it every [6 months]. See the Incident Response Contact and Call Tree Template.

3. Detection and triage

Confirm impersonation safely: analyse the site from an isolated analysis browser or sandbox, never from a corporate workstation. Do not enter real credentials.
Capture evidence: full URL(s); screenshots with visible timestamps; page source and any phishing kit files exposed; HTTP response headers; DNS records (A, AAAA, MX, NS, TXT); TLS certificate details and certificate transparency entries; registration data from RDAP (registrar, creation date, status); hosting IP and network owner; sample emails with full headers. Hash files and record who captured what, when. See the Evidence Handling and Chain of Custody Guide.
Identify the providers: registrar (from RDAP), DNS provider (from NS records), hosting provider (from IP ownership), email sending service, CDN or reverse proxy in front of the origin, certificate authority, and any URL shortener or file-sharing service in the chain.
Pivot: search for related domains on the same IP, name servers, registrant details where visible, certificate and kit fingerprints; campaigns rarely use one domain.
Assess impact: search email, proxy and DNS logs for internal users who received the lure, visited the site or submitted data; ask fraud and customer service for customer reports.
Set severity using section 1 and record the decision.

4. Containment

Containment protects people while removal is pending. It is fully within [Organisation]'s control and should never wait for a provider.

Email: block the sending domain and observed senders at the email gateway; purge delivered messages; confirm [Organisation]'s own domains publish DMARC at p=reject so exact-domain spoofing is not also in play. See the DMARC, SPF and DKIM Guide.
Web and DNS: block the domain and related domains on the secure web gateway, DNS resolver policy (protective DNS or RPZ) and EDR web protection.
Identity: for any user who submitted credentials, reset the password, revoke sessions and refresh tokens, review MFA methods and check for new inbox rules or OAuth grants.
Browser blocklists: report the URL to browser and security vendor blocklists (for example Google Safe Browsing and Microsoft's unsafe site reporting form) and to anti-phishing sharing groups such as the APWG, which accepts reports at [email protected], preferably forwarded as an attachment. Blocklisting often takes effect before removal does.
Customers and staff: if the lure targets them, issue a short warning through known channels (section 7).

5. Eradication

Eradication means getting the content or domain removed. Report to every provider in the chain in parallel, starting with the one most likely to act fastest.

Target	Route	Evidence that helps	Typical outcome
Hosting provider	Abuse contact from IP ownership records or the provider's abuse form	URLs, screenshots, kit files, victim impact	Content or account removed
Registrar	Registrar abuse contact listed in RDAP	Evidence of phishing or malware, not just trademark similarity	Domain suspended or placed on hold
CDN or reverse proxy	Provider abuse form	URLs and evidence; ask for origin host details to be forwarded	Abuse report passed to origin host; service terminated in some cases
Email sending service	Provider abuse contact	Full message headers	Sending account suspended
Registry or ccTLD operator	Registry abuse contact, used when the registrar does not act	Prior registrar report reference, evidence	Varies by registry policy
Social platform or app store	Platform impersonation or intellectual property form	Trademark registration, official account links	Account or listing removed
National CERT or cyber agency	Agency reporting service, for example the UK NCSC "Report a scam website" form	URL	Agency may work with hosts to remove; outcome usually not reported back

5.1 Registrar obligations: under ICANN's Registrar Accreditation Agreement section 3.18, accredited registrars of generic top-level domains must maintain an abuse contact and take reasonable and prompt steps to investigate and respond appropriately to abuse reports, with a dedicated contact for law enforcement and similar authorities. ICANN amended its registrar and registry agreements in 2024 to strengthen obligations to mitigate DNS abuse, including phishing, when given actionable evidence; check the current contract text on icann.org before citing it in a report. Country-code domains follow their registry's own policies.

5.2 Write reports that providers can act on: state the abuse type (phishing, malware, fraud) in the subject; include the exact URL and evidence; explain the impersonation briefly; note confirmed victims; give a contact for follow-up. Trademark-only complaints without abuse are often redirected to dispute processes.

5.3 Escalate to dispute procedures when abuse reporting fails or the domain is held for later use: the Uniform Domain-Name Dispute-Resolution Policy (UDRP) requires the complainant to prove that the domain is identical or confusingly similar to its mark, that the holder has no rights or legitimate interests, and that it was registered and is being used in bad faith; remedies are cancellation or transfer. The Uniform Rapid Suspension System (URS) is ICANN's faster, lower-cost route for the most clear-cut cases and requires clear and convincing evidence. Legal counsel owns both.

5.4 Chase unanswered reports after [24 hours] for critical cases and [3 business days] otherwise, citing the original ticket reference.

6. Recovery

Verify removal: confirm the site no longer resolves or serves content from several networks, and that browser warnings appear where removal is incomplete.
Watch for reappearance: keep monitoring the domain, related infrastructure and new registrations with similar names for [90 days]; campaigns often move to a new domain the same day.
Decide on the domain: where a domain is suspended rather than transferred, decide with legal counsel whether to pursue transfer, monitor for expiry or acquire it.
Restore customer trust: close customer cases, reimburse where policy allows and update help pages.
Lift temporary measures carefully: keep internal blocks for removed domains; remove only blocks that caused business impact and were confirmed safe.

7. Communication and notification

7.1 Staff: short alert naming the lure, what to look for and how to report, sent through a channel the attacker is not imitating.

7.2 Customers: where customers are targeted, publish a notice on the official site and in official app or account channels: what the fake looks like, that [Organisation] will never ask for [credentials, payment details], and how to report. Do not include clickable links to the fake site.

7.3 Regulators and law enforcement: if personal data was captured from customers or staff, assess data protection notification duties with the data protection officer; report fraud losses to the relevant police or fraud reporting service. See the Incident Communication Plan Template.

7.4 Partners: share indicators with sector sharing groups under the appropriate TLP marking.

8. Post-incident review

Timeline: first detection, first report, blocklisting, removal per provider, reappearances.
Which providers acted, how fast and on which evidence; update the contact sheet.
Whether monitoring (certificate transparency, new registrations, DMARC reports) detected it, and how early.
Victims, losses and whether customer communications reduced them.
Defensive actions: domains to register, monitoring terms to add, awareness content to refresh.

Implementation guidance

Prepare the evidence kit: an isolated analysis browser or sandbox, capture tooling, report templates for registrar, host and blocklist submissions, and an evidence store with access control.
Turn on early warning: certificate transparency monitoring for brand terms, new domain registration feeds, DMARC aggregate reporting and a staff and customer reporting address. See the Certificate Transparency Guide.
Decide in-house versus provider: a small organisation can run this playbook with the SOC and legal counsel; a large consumer brand with frequent impersonation usually contracts a takedown provider and keeps this playbook for oversight, internal containment and escalation.
Test it: run a tabletop with a mock lookalike, including evidence capture and a dry-run report, at least [annually].
Measure: track median time from detection to blocklisting, median time to removal by provider type, percentage of reports actioned, reappearance rate within 30 days and number of victims per incident.

This playbook supports NIST CSF 2.0 outcomes RS.AN-03 (analysis of what happened), RS.MI-01 (incidents are contained) and RS.CO-03 (information shared with designated stakeholders), NIST SP 800-53 Rev. 5 IR-4 Incident Handling and IR-6 Incident Reporting, and NIST SP 800-61 Rev. 3. Attacker behaviours it responds to include MITRE ATT&CK T1583.001 Acquire Infrastructure: Domains, T1608.005 Link Target, T1566.002 Spearphishing Link and T1598.003 Spearphishing Link for credential phishing reconnaissance.

Brand Impersonation and Lookalike Domain Takedown Playbook: Evidence, Blocking and Removal Steps