Skip to main content

Lookalike Domains and Brand Abuse: An OSINT Workflow for Security Teams

Find lookalike domains with dnstwist and certificate transparency, link them into campaigns through registration dates, hosting, analytics IDs and favicon hashes, archive the evidence, and report copycat sites through the right channels.

· By UserSearch Team · 13 min read

Disclaimer: This article is for education and for lawful, authorised professional research. Use these methods only where you have a legitimate purpose and a lawful basis, and follow the laws and platform terms that apply to you, including data protection law such as the UK GDPR and EU GDPR. See our Terms of Service.

TL;DR

  • Lookalike domains are cheap to register and quick to deploy. Brand abuse domain research is a numbers game you win with permutation tools, certificate transparency logs and searches you re-run every week.
  • dnstwist generates thousands of candidate spellings and tells you which are registered, which have mail servers and which serve pages similar to yours.
  • Clustering is where the value is: registration dates, shared hosting, shared analytics IDs and favicon hashes turn fifty separate domains into one campaign and one report.
  • Archive the evidence before you report. Then use the right route: registrar and host abuse contacts, the NCSC's reporting services and Google Safe Browsing.
  • UserSearch runs Domain, IP, Cyber and Threat Intelligence from one account and keeps the work in a Case, with Forensic Capture for hashed, timestamped page captures.

Your Customers Cannot Tell the Difference, and That Is the Point

Brand abuse domain research is the work of finding lookalike domains that copy your brand, linking them into campaigns and reporting them with evidence a registrar or hosting company can act on. A customer gets a text saying their parcel is held, or an email saying their account needs checking. The link goes to a domain one letter away from yours, with your logo, your colours and a login form. By the time your support team hears about it, the site has been live for two days and the operator has registered twelve more.

Brand abuse through lookalike domains is not sophisticated. It works because registration is cheap, certificates are free, and page kits copy a brand in minutes. The defending side has to be more organised than the other side is clever. That means generating the likely domains before they are used, spotting new certificates as they are issued, linking related domains into campaigns, and reporting them with evidence that a registrar or hosting company can act on quickly.

This guide sets out that workflow for brand protection and security teams. For WHOIS records, DNS interrogation and certificate basics, our earlier article on domain OSINT from WHOIS to infrastructure covers the foundations. Here we focus on finding lookalikes at scale and building a case against them.

What Counts as a Lookalike Domain?

A lookalike domain is a registered name designed to be mistaken for a legitimate one. The broad practice is known as typosquatting, but it covers several distinct techniques:

  • Typos and omissions: a dropped, doubled or swapped letter.
  • Homoglyphs: characters that look alike, such as rn for m, 1 for l, or Cyrillic letters inside an internationalised domain name. The Unicode variant is often called an IDN homograph attack, and in the browser's address bar it may display normally while the underlying punycode starts with xn--.
  • Combosquatting: the brand plus a word such as -login, -support, -refund or secure-.
  • TLD swaps: the same name under .co, .shop, .online or a country code.
  • Subdomain tricks: the brand as a subdomain of an unrelated domain, such as example.com.account-check.example, which reads correctly from the left on a small screen.

Throughout this article, the legitimate brand domain is example.com, and lookalikes are written under the reserved .example top-level domain, for instance examp1e.example, so that no real registration is implied.

Why Does Brand Abuse Domain Research Matter Now?

The scale is industrial. In November 2025, Google filed a lawsuit against the operators of Lighthouse, a subscription kit for building copycat sites that was sold to text-message fraud groups. The Record reported Google's estimate that more than 200,000 fake websites were created with it in a 20-day period, with over 100 templates using Google's own branding on sign-in pages. Postal services, toll operators and banks were copied in the same way.

In the UK, the NCSC's Annual Review 2025 reports more than 10.9 million reports to its Suspicious Email Reporting Service in a year, and 1.2 million cyber-enabled commodity campaigns removed through its Takedown Service. That is the downstream end of the problem. Every one of those campaigns needed a domain, and many of those domains were lookalikes that could have been spotted when they were registered or first given a certificate.

For security and brand teams, the business case is simple: fewer customers deceived, fewer support calls, less reputational damage, and evidence ready when legal or the regulator asks. Our cyber security industry page describes how teams use UserSearch for this kind of infrastructure research.

The Manual Workflow: From Permutations to Clusters

Generate Candidates with dnstwist

dnstwist is the standard open-source permutation engine. It generates spelling variants of a domain using several fuzzing algorithms, resolves them, and reports which exist. Install it with the optional extras, which add fuzzy hashing, GeoIP and WHOIS support:

pip install "dnstwist[full]"
# or: sudo apt install dnstwist   |   brew install dnstwist   |   docker run -it elceef/dnstwist

The quotes around dnstwist[full] stop shells like zsh from treating the brackets as a pattern. Then run the basic registered-only scan:

dnstwist --registered --format csv example.com > lookalikes.csv
  • --registered shows only permutations that resolve or have DNS records. Without it you get every generated variant, often several thousand for a longer name.
  • --format csv writes results you can sort and diff. json is also available and pipes neatly into jq.

Useful additions:

dnstwist --registered --tld dictionaries/common_tlds.dict example.com
dnstwist --registered --dictionary dictionaries/english.dict example.com
dnstwist --registered --mxcheck --lsh --nameservers 1.1.1.1,8.8.8.8 example.com
  • --tld tries your name under every TLD in the file. The sample dictionaries ship with the Git repository; if you installed with pip, download them from the repo.
  • --dictionary adds combosquats using words from a file. Build your own list from your product names and the words copycat operators use against your sector: login, verify, refund, delivery.
  • --mxcheck tests whether a lookalike's mail server accepts mail, which flags domains set up to receive misdirected email from your customers and staff.
  • --lsh fetches each live site and compares a fuzzy hash of its HTML with yours, giving a similarity percentage. --phash does the same visually using screenshots, and needs Chromium plus a fair amount of memory.
  • --nameservers points queries at resolvers that can take the load. Thousands of lookups in a burst will overwhelm a small office router or a rate-limited corporate resolver, and you will get false negatives without realising it.

Run it weekly, save the CSV with the date in the file name, and diff against last week. New rows are what you review. If you want a quick look before installing anything, the project also runs a browser version at dnstwist.it.

Search Certificate Transparency with crt.sh

Permutation tools only find what their algorithms can imagine. Certificate transparency catches the rest. Every publicly trusted TLS certificate must be written to public append-only logs, as explained on the Certificate Transparency project site. Since almost every copycat site uses HTTPS, a new certificate is often the first public sign that a lookalike is about to go live.

crt.sh is the free search front end most analysts start with:

curl -s "https://crt.sh/?q=%25example%25&output=json" \
  | jq -r '.[] | [.entry_timestamp, .name_value, .issuer_name] | @tsv' | sort -u
  • %25 is a URL-encoded %, crt.sh's wildcard. %example% matches the brand anywhere in a certificate name, which catches combosquats and subdomain tricks that dnstwist misses.
  • output=json returns machine-readable results. name_value holds the names on the certificate, and entry_timestamp is when it was logged.

The friction: crt.sh is a free community service and broad wildcard queries often time out or return a 502. We hit exactly that while writing this guide. Narrow the query (%example-%, %examp1e%), retry off-peak, or query its public PostgreSQL interface for heavy use. A short brand name that is also a common word will drown you in unrelated matches, so pair the brand with sector words. Also note that certificates prove only that someone controlled the domain when the certificate was issued. Plenty are issued and never used.

Registration Dates and Registrars via RDAP

For each live candidate, pull the registration record. RDAP returns JSON:

curl -sL https://rdap.org/domain/examp1e.example \
  | jq '{ldhName, events: [.events[] | {eventAction, eventDate}], registrar: [.entities[] | select(.roles | index("registrar")) | .vcardArray[1][1][3]]}'

This prints the domain, its registration and expiry events, and the registrar name. The dates matter more than the registrant, which is almost always redacted. A domain registered the day before a campaign, alongside six others at the same registrar within the same hour, belongs to that campaign. A lookalike registered in 2009 and parked ever since is probably a speculator, and a different conversation. Registrant details are nearly always behind privacy services now, so do not plan a workflow that depends on them.

Hosting Overlaps

Resolve everything and group by where it lives:

for d in $(cut -d, -f2 lookalikes.csv | tail -n +2); do
  echo "$d,$(dig +short A $d | head -1),$(dig +short NS $d | head -1),$(dig +short MX $d | head -1)"
done | sort -t, -k2

The loop takes the domain column from dnstwist's CSV (check the header row first, as column order can change between versions), then prints the first A, NS and MX record for each. Sorting on the address brings domains on the same server together. Shared name servers at a small DNS provider, shared mail servers and shared addresses are all clustering signals. Shared addresses at a big CDN or a mass-market host are not, so check the ASN before you draw a line between two domains.

Shared Analytics IDs and Favicon Hashes

Operators reuse page kits, and kits carry fingerprints. Two of the most useful:

Analytics and tag IDs. Google Analytics measurement IDs (G-), older Universal Analytics IDs (UA-) and Tag Manager container IDs (GTM-) sit in page source. Universal Analytics stopped processing data in July 2023 (July 2024 for paid 360 properties), but old kits still carry the IDs, and they still link sites.

curl -sL https://examp1e.example/ | grep -oE '(G-[A-Z0-9]{6,12}|UA-[0-9]+-[0-9]+|GTM-[A-Z0-9]{4,9})' | sort -u

Source-code search engines such as PublicWWW let you search for an ID across the pages they have indexed. One ID on thirty domains is one operator, or at least one kit seller's customer base.

Favicon hashes. Kits often copy your favicon. Shodan indexes a MurmurHash3 of each site's favicon, and its search filter reference lists http.favicon.hash among the HTTP filters. Compute the hash of your own favicon and search for servers using it that are not yours:

pip install mmh3 requests
python3 -c "import mmh3,requests,codecs; r=requests.get('https://example.com/favicon.ico'); print(mmh3.hash(codecs.encode(r.content,'base64')))"

The base64 step matters: Shodan hashes the base64-encoded file with line breaks, which is what codecs.encode produces. Then search Shodan for http.favicon.hash:<result>. You need a Shodan account, and filters beyond the basics need a paid plan. Every result that is not one of your own servers or CDN edges deserves a look.

Archive Before You Report

Copycat sites vanish quickly, sometimes because your report worked and sometimes because the operator rotates. Capture first. The Internet Archive's Save Page Now gives you a public third-party copy, though some kits block the archive's crawler or show it a harmless page. For evidence you may need to rely on later, use a capture method that records a hash and a timestamp at the moment of capture, and keep the page source, the certificate details and the DNS records alongside the screenshot. Visit copycat pages from an isolated browser or a sandboxed service, never enter real details into their forms, and do not download files they offer.

Doing the Clustering in UserSearch

The manual workflow works, but it spreads across dnstwist output, crt.sh tabs, RDAP JSON, a Shodan account and a spreadsheet. The link between domain number 14 and domain number 38 lives in one analyst's head. When that analyst is on leave, the case stalls.

UserSearch 2.0 brings the research steps into one account (our beginner's guide to UserSearch covers a first search):

  • Domain Intelligence for ownership, history and favicon checks on each lookalike.
  • IP Intelligence for the hosting network behind each address.
  • Cyber Intelligence (Shodan Modules) for services, certificates and banners, without a separate Shodan subscription.
  • Threat Intelligence for what threat data sources already know about a domain or address.

OneScan runs one domain across several selected sources and merges the results with source attribution, and the Credit cost is shown before you run. Bulk search handles up to five inputs through one Module in a batch, which suits a new set of lookalikes from this week's dnstwist diff. In Forensic Mode, every search and bookmark lands in a Case, and teams share Cases and a common Credit pool. For captures, Forensic Capture, our free browser extension, records full pages with SHA-256 fingerprints, two independent timestamps and a hash-chained notebook, and produces a PDF report and an evidence bundle with an offline verifier. SargeBot can draft the campaign summary from your Case for you to check and edit. Results are leads to corroborate, and coverage depends on each third-party source.

Advanced Brand Abuse Patterns and Worked Cases

Scenario One: A Bank's Weekly Lookalike Review

Context. The security team at Example Bank plc, whose customer site is example.com, runs dnstwist and a crt.sh query every Monday.

Actions. This week's diff shows four new registered permutations. Three are parked pages at a domain marketplace. The fourth, examp1e.example, was registered on Saturday, has a certificate logged on Sunday, an MX record, and an LSH similarity of 71% with the real login page. The team captures the page, pulls RDAP, and finds the registrar's abuse email in the record. The certificate search turns up two more names on the same certificate that dnstwist had not generated: example-verify.example and secure-example.example.

Outcome. One report goes to the registrar covering all three domains, with captures, certificate IDs and DNS records attached, and a second goes to the hosting provider. The URLs go to Google Safe Browsing and the NCSC. The domains are added to the bank's mail filters. Because the lookalike was found within two days of registration, the customer-facing damage was limited to a handful of reports.

Scenario Two: Linking Copycat Shops to One Operator

Context. Example Outdoor Ltd, a retailer at example.org, receives complaints about "clearance sale" shops using its brand name and product photos.

Actions. The team starts with the eight domains customers reported. All share one GTM- container ID. A PublicWWW search for that ID returns 31 more domains, most using other brands. Resolving them shows three hosting addresses in one ASN, and Shodan returns the same favicon hash as the retailer's own site on nine of them. RDAP shows batches of registrations on the same days at two registrars.

Outcome. The team reports all 39 domains as one campaign with the shared ID as the linking evidence, and notifies the other affected brands through industry contacts. The trademark team files a complaint under the WIPO domain name dispute procedure for the two domains that include the retailer's registered mark and have survived abuse reports.

Prioritising a Long Permutation List

A popular brand can produce hundreds of registered permutations. Score them. Recently registered plus a recent certificate plus an MX record plus high page similarity goes to the top. Parked for years with no mail goes to the bottom, and into a quarterly review rather than this week's reports.

Registering the Obvious Variants Yourself

Some permutations are so close to your name that registering them defensively costs less than reporting them later. Use your dnstwist output to pick the most likely typos and TLDs, register them, and point them at your real site.

Where Do You Report Lookalike Domains, and What Are the Rules?

Getting a lookalike removed depends on sending the right evidence to the right place:

  • Registrar abuse contact. Accredited registrars must publish an abuse contact and act on reports, as ICANN sets out in its page on registrar abuse reports. The contact appears in the RDAP record. Include the domain, what the page does, why it is deceptive, captures and timestamps.
  • Hosting provider abuse contact. Found in the IP address's RDAP record. Hosts can often act faster than registrars.
  • NCSC. UK organisations and the public can forward suspicious emails to [email protected] and report suspicious websites through the NCSC's scam website reporting page.
  • Google Safe Browsing. The Safe Browsing report form gets a URL assessed for warnings in Chrome and other browsers that use the service.
  • Trademark routes. For names that include your mark, dispute procedures such as the UDRP can transfer the domain. They are slower but permanent.

Stay within the rules while you research. Keep your methods passive: DNS lookups, certificate logs, public page loads and archive services. Do not submit data into copycat forms, even fake data, and do not attempt to access their admin panels. Registrant details, where they are visible, are personal data under the UK GDPR, so record why you collected them. And keep your reports factual: say what the page does and how it copies your brand, not who you think is behind it. This is general information, not legal advice.

Frequently Asked Questions About Brand Abuse Domain Research

What is brand abuse domain research?

Brand abuse domain research is the work of finding lookalike domains that copy a brand, linking related domains into campaigns and reporting them with evidence. Security and brand teams generate likely spellings with permutation tools, search certificate transparency logs for new certificates, cluster domains by registration dates, hosting, analytics IDs and favicon hashes, then report to registrars and hosts.

What is a lookalike domain?

A lookalike domain is a registered name designed to be mistaken for a legitimate one. Common techniques include typos and omissions, homoglyphs such as rn for m or Cyrillic letters in an internationalised name, combosquatting with words like -login or -refund, TLD swaps to .shop or a country code, and subdomain tricks that read correctly on a small screen.

What tools are used for brand abuse domain research?

The core tools for brand abuse domain research are dnstwist for spelling permutations, crt.sh for certificate transparency searches, RDAP for registration dates and registrars, dig for hosting overlaps, PublicWWW for shared analytics IDs and Shodan for favicon hashes. The Internet Archive's Save Page Now and hashed, timestamped captures preserve pages before they disappear.

Lookalike domains are linked through shared fingerprints. Registrations on the same day at the same registrar, shared name servers, mail servers or hosting addresses outside big CDNs, a common Google Analytics or Tag Manager ID in page source, and a copied favicon hash in Shodan can turn fifty separate domains into one campaign and one report.

How do you report a lookalike domain in the UK?

A lookalike domain can be reported to the registrar abuse contact and the hosting provider abuse contact, both found in RDAP records. UK organisations can forward suspicious emails to [email protected] and report websites to the NCSC, and submit URLs to Google Safe Browsing. For names that include a registered mark, the UDRP can transfer the domain.

Lookalike domain research stays within the rules when methods are passive: DNS lookups, certificate logs, public page loads and archive services. Analysts should not submit data into copycat forms or try to access admin panels. Registrant details, where visible, are personal data under the UK GDPR, so teams should record why they collected them and keep reports factual.

Turning Lookalike Domains into Evidence-Backed Takedowns

The teams that handle brand abuse well are not the ones with the cleverest tools. They are the ones who run the same checks every week, cluster what they find, capture it properly and report it in a form a registrar can act on the same day. dnstwist and certificate transparency find the domains, registration data and hosting overlaps link them, analytics IDs and favicon hashes prove the connection, and good captures make the report stick.

Stop guessing. Start researching with UserSearch. Run Domain, IP, Cyber and Threat Intelligence from one UserSearch account with access to 100+ third-party data sources, combine them with OneScan, capture evidence with Forensic Capture, and keep the whole campaign in a shared Case your team can report from.

About the author

UserSearch Team
Updated on Oct 30, 2026