Brand Protection: Spotting Lookalike Sites by Their Technology
String similarity finds candidates; technology separates the dangerous ones from the noise. A lookalike domain that runs a different stack from your real site, was registered yesterday and hides behind a proxy reads very differently from a parked name. This is how to triage.
The problem with name matching alone
Monitoring newly registered domains for your brand produces more candidates than any team can review. Fuzzy matching on a short brand name flags innocent businesses, fan pages and unrelated companies sharing a word. The earlier guide on typosquatting and lookalike domains covers how variants are generated and how to monitor. This guide covers the next step: after you have a candidate, what does its technology say?
The reason technology helps is economic. Attackers copy a site's look cheaply, but they cannot cheaply copy how it is built, hosted and operated. The real brand's site has a history of choices, such as a particular CMS, a tag manager, a CDN and a certain hosting setup. A phishing clone is built in hours, with different tools, on different infrastructure.
Step 1: compare the candidate's stack with yours
Write down your real site's technology profile: CMS or framework, CDN, tag manager and analytics, font and widget providers, and the way pages are served. Then examine the candidate using the same checks, as set out in how to tell what a site uses. Differences are informative but not conclusive:
- Your site runs a JavaScript framework behind a CDN with a tag manager; the candidate is a static page with inline styles. A copy built by saving your page and editing it will often keep your asset paths and references to your analytics ID; a rebuilt page will not.
- The candidate loads images, scripts or fonts directly from your real domain. That is the signature of a quick clone, since it hot-links your files. It also gives you server logs: your own web server sees requests with the referring page of the clone.
- The candidate contains your tracking IDs because the attacker copied your HTML. Be careful in how you describe this to others, because such IDs in a page do not prove you own the page.
Step 2: read the infrastructure signals
| Signal | Concerning pattern | Benign pattern |
|---|---|---|
| Registration age | Created in the last days or weeks | Created before your brand existed |
| Name servers and host | Free or bulk services, shared with many sibling lookalikes | A normal business registrar and host |
| Proxy or CDN | Proxy used to hide the origin, combined with young age | CDN on an old, established site |
| Certificate | Issued within hours of registration for a brand-related name | Long-running certificate for a distinct business |
| Mail records | MX configured but no real website, or mail authentication absent | No MX, or a business mail provider |
| Page content | Login form, brand logo, urgency language | Content unrelated to your sector |
| Purpose category | Login or payment page with no contact page | Parked page or a blog |
A proxy by itself means little: millions of legitimate sites use one. Combined with a young domain and a brand-keyword name, it matters. The mechanics of proxy detection are in Cloudflare and CDN detection.
Step 3: classify the purpose of the page
Most lookalikes are not phishing. They fall into a handful of purposes, and the right response differs for each:
- Parked or for sale. The name is held for resale. The reaction is monitoring, possibly a purchase, rarely a takedown. See detecting parked domains.
- Unrelated legitimate business. No action.
- Affiliate, reseller or fan site. A policy question for legal or partnerships.
- Credential phishing. A form that asks for login or payment details on a page imitating your brand. Escalate immediately.
- Counterfeit shop. A hosted store using your product images. Report to the platform and registrar; hosted builders have abuse processes.
- Redirector. A name that forwards to a scam, found by following redirects.
Browser-based tools can accelerate the page-level read. TLDlive Lens shows the detected technologies, a purpose guess and the domain's age and status in one popup when you open a suspicious site in a hardened browser profile. Treat the guess as a triage hint. The classification of login forms and carts is a yes or no signal, not a verdict.
Step 4: use the platform as an abuse route
Technology tells you whom to contact. A clone on a hosted builder can be reported to that builder; a store on a major commerce platform has an abuse form; a site behind a CDN can be reported to the CDN, which forwards complaints to the origin host but does not remove content itself. Learn the stack, then choose the fastest report path. The routes and their trade-offs are tabulated in the guide on typosquatting; here the new point is that detection decides which route applies.
Step 5: build a repeatable queue
- Match new registrations against your watch terms and variants, using zone-file data as described in newly registered domains.
- For each match, collect the registration date, name servers and any web response.
- Fetch the page in an isolated environment, and record its technologies and purpose.
- Score: age, brand keyword, login form, proxy, mail records, stack mismatch.
- Route by score: ignore, watch weekly, report, or escalate.
- Keep dated evidence for anything you report, including screenshots and the detected stack.
Limits and false positives
Technology evidence is circumstantial. A real company might use free DNS, or a site builder the real brand also uses. Phishing kits may use the same platform as your real site precisely to look alike. Never publish an accusation based on stack alone. Use it to prioritise human review, and rely on content, registration facts and mail behaviour to decide.
Also be careful with the tools you use to inspect suspect pages. Open them in a separate browser profile, do not log in, and do not enter data into a suspect form. Extensions that work locally, such as Lens, read signals but do not interact with the page.
Sources
- ICANN, Uniform Domain-Name Dispute-Resolution Policy and rules: icann.org
- Anti-Phishing Working Group, Phishing Activity Trends reports: apwg.org
- Google Safe Browsing, report phishing: safebrowsing.google.com
Frequently asked questions
Can technology prove a site is phishing?
No. It is circumstantial evidence for prioritising review. A confirmed phishing page is one that imitates your brand and asks for credentials or payments, which you establish by looking at the content.
Why would a lookalike load images from my real website?
Quick clones copy your HTML and keep references to your assets. This hot-linking shows up in your server logs as requests with the clone as referrer, which is useful evidence and a way to discover clones.
How soon after registration do phishing sites go live?
It varies from within hours to weeks, and some are registered long before use. Monitoring mail records and certificates in addition to web content catches preparation.
Is a Cloudflare-proxied lookalike more suspicious?
Only in combination with other signals. Many legitimate sites use Cloudflare. Young age plus a brand keyword plus a login form matters more than the proxy.