Skip to content
Who is pretending to be us?

Brand Protection

Someone is using your name. Get it taken down.

Lookalike domains, cloned login pages, counterfeit apps and fake support accounts. We find them across the six channels attackers actually use, capture the evidence before the page disappears, and file and chase the takedown on your behalf.

Impersonation watchlistnorthgate-bank.exampleIllustrative — fictional brand
An illustrative watchlist showing five lookalike assets detected for a fictional brand, with detection technique, severity, the signal that set the severity, and current takedown status.
AssetTechniqueSeveritySignalStatus
login.northgate-bank.examp1eTLD swapCriticalLogin clone serving, credential form activeTakedown filed
nоrthgate-bank.exampleHomoglyph (IDN)CriticalCertificate issued, page not yet liveEvidence captured
northgatebank-secure.exampleCombosquatHighMX records configured — mail-capableAnalyst review
@northgatebank.officialSocial accountHighReplying to public customer complaintsReported to platform
northgate-bank.exampieTLD swapMediumRegistered, parked, no contentWatching
Detection
New registrations, certificate logs, app stores
Response
Managed takedown, tracked end to end
Evidence
Screenshots, WHOIS and hosting captured on sight

The impersonation surface

Six channels, one brand, the same trick

Impersonation is cheap because the attacker only needs your name. A domain costs about ten dollars, a phishing kit is free, and a fake support account costs nothing at all. Each channel needs different collection, so we run all six rather than watching domains and calling it brand protection.

  • Lookalike domains

    Registration feeds · certificate transparency · passive DNS

    • New registrations matching your brand and its known mutations
    • Certificates issued for names you do not own
    • A lookalike resolving to an address for the first time
    • MX records appearing — usually the step before mail fraud
  • Phishing and clone pages

    Crawling · phishing-kit fingerprints · asset hotlink referrers

    • Copies of your login, payment and password-reset screens
    • Pages pulling your real logo, CSS or favicon from your own site
    • Credential forms posting to a third-party collection endpoint
    • Kits reused across hosts, so one detection maps a whole cluster
  • Mobile apps

    Public app stores · third-party APK mirrors

    • Store listings using your name, icon or screenshots
    • Repackaged builds of your app hosted outside the stores
    • Apps requesting permissions your real app never asks for
    • Listings that point payment or support flows somewhere else
  • Social and messaging accounts

    Platform search · handle mutations · executive name variants

    • Profiles using your name, your mark or a named employee's identity
    • Fake support handles that message customers who complain publicly
    • Groups selling fake refunds, giveaways or account access
    • Accounts recycling your real posts to look established
  • Paid ads and search

    Brand-term ad monitoring from several regions

    • Ads bidding on your brand terms that land on domains you do not own
    • Sponsored results above your own listing for login-intent queries
    • Landing pages that cloak — one page for the reviewer, another for the click
    • Affiliate abuse dressed up as an official offer
  • Email spoofing

    DMARC aggregate reports · lookalike sending domains

    • Senders using your domain with no SPF or DKIM alignment
    • Display-name spoofing aimed at finance and executive inboxes
    • Lookalike domains that have started sending, not just resolving
    • Reply-to addresses redirected to free mail providers

Domain detection explained

Almost every lookalike is one of five shapes

Attackers do not invent a new trick for each brand. They run your name through a generator, buy whatever is cheap and available, and wait. Knowing the five shapes is what makes the difference between a keyword alert and coverage.

Legitimate

northgate-bank.example

Owned by you

Fictional example brand — not a real organisation

  • Typosquat

    Two adjacent characters transposed

    northgate-bnak.example

    Same generator
    nortgate-bank.example · northgatte-bank.example · northgate-bank.exampl

    Insertions, deletions, doubled letters and swapped neighbours. The whole mutation space is generated from your name and monitored, so a registration is matched the day it appears rather than found later by hand.

  • Homoglyph / IDN

    Latin 'o' replaced with a Cyrillic character

    nоrthgate-bank.example

    Substituted
    U+043E CYRILLIC SMALL LETTER O
    IDNA form
    xn--nrthgate-bank-i7k.example

    In most fonts this is indistinguishable from the real name, which is the entire point. Detection works on the Punycode the registry stores — where the substitution cannot hide — not on the rendered string a human sees.

  • Combosquat

    Brand left intact, a keyword appended

    northgate-bank-login.example

    Same family
    -secure · -verify · -support · -payments · -app · -helpdesk

    Your brand string is untouched, so it passes a squint test, and the added word is the one the customer was already looking for. These are the registrations that most often end up with a working login clone on them.

  • TLD swap

    Same name, different suffix

    northgate-bank.exampl

    Watched
    legacy gTLDs, new gTLDs, and the ccTLD of every market you operate in

    One keystroke short of the real address, so it harvests mistyped mail as well as clicks. A cheap suffix registered days after a product launch is rarely a coincidence.

  • Subdomain spoofing

    Your full domain pushed into a label of someone else's

    northgate-bank.example.account-verify.example

    Registered domain
    account-verify.example — nothing to do with you

    On a phone the address bar shows the left-hand side and truncates the rest, so everything visible is your domain. The part that decides where the request actually goes sits off the right edge. No lookalike is registered at all, which is why generator-only monitoring misses it.

Every candidate lands in one of three states

  • Owned

    You confirm it is yours — a campaign microsite, a regional registration, a partner. It leaves your queue and stays tracked for changes.

  • Watching

    Registered but inert: no content, no certificate, no mail. Weak grounds for a complaint, so we hold and alert the moment that changes.

  • Actioned

    It resolves, serves a page, gains a certificate or turns on mail. Evidence is captured and the takedown pipeline starts.

Detection to takedown

Finding it is the easy half

Plenty of tools will send you a list of lookalike domains. The difference is what happens next — whether somebody captures the evidence before the page vanishes, picks the party who can actually act, and keeps the case moving when it goes quiet. That is the work, and we do it rather than handing you a form.

  1. Step 01Detect
  2. Step 02Evidence
  3. Step 03Assess
  4. Step 04File
  5. Step 05Chase
  6. Step 06Verify
  7. Step 07Watch
Platform
Runs continuously. No human in the loop.
0DaySecure analyst
A named analyst on our side does the work.
Analyst + you
Needs one decision from you, then it is ours again.
  1. Step 01

    Detect

    Platform

    Registration feeds, certificate transparency, passive DNS, app store listings and platform handles are matched against your brand and its whole mutation space. A candidate is raised when it is created, which is usually days before anyone tries to use it.

    • Matched on the Punycode form, so a homoglyph cannot slip past on looks
    • De-duplicated against your confirmed assets, so your own launches do not page you
    • Clustered by infrastructure, so one operator's twelve domains arrive as one case

    ProducesCandidate record with a first-seen timestamp

  2. Step 02

    Capture evidence

    Platform

    Before anyone assesses anything, the target is recorded as it exists at that moment. Operators pull pages down the moment they notice attention, and a complaint filed without evidence tends to be closed as unverified.

    • Full-page render, served HTML, response headers and the form action
    • WHOIS, name servers, hosting, network owner and the certificate chain
    • Content hashes, so a later change is provable rather than remembered

    ProducesTimestamped evidence pack — see the next section

  3. Step 03

    Assess and prioritise

    Analyst + you

    An analyst decides what the thing actually is: a live credential harvester, a dormant registration, a legitimate partner, or an asset of yours nobody told us about. Severity comes from behaviour, not from how closely the string resembles your name.

    • Does it resolve, serve a login form, hold a certificate, accept mail
    • Is it loading your real assets or referencing your real customers
    • Anything you confirm as owned or approved is allowlisted once and stays quiet

    ProducesSeverity, a recommended action, and the party to file with

  4. Step 04

    File with the party who can act

    0DaySecure analyst

    The complaint goes to whoever can actually remove it — the registrar, the hosting provider, the CDN, the certificate authority, the app store or the platform's brand team. We file on your behalf under a one-time authorisation signed at onboarding, so nothing waits on your legal team case by case.

    • Grounds chosen to fit: abuse and phishing policy, trademark, or platform impersonation rules
    • Filed with several parties in parallel when that beats filing in sequence
    • Indicators submitted to browser and mail blocklists at the same time, so the page gets flagged while the case runs

    ProducesProvider case reference, recorded against your case

  5. Step 05

    Chase, escalate, re-file

    0DaySecure analyst

    Most cases stall rather than get refused. The work is keeping them moving: answering requests for more detail, escalating upstream when the first party goes quiet, and re-filing on different grounds when the first set is rejected.

    • Escalation path from reseller to registrar to registry, or from host to upstream transit
    • A rejection comes back with the reason and the next route, not just a closed ticket
    • Status changes push into your ticketing or chat tool, so nobody has to chase us

    ProducesA case history with every exchange logged and attributable

  6. Step 06

    Verify removal

    Platform

    The target is re-checked on a schedule until it is genuinely gone. Gone means gone — not a registrar holding page, not the same content on a new address, not a live certificate with the page hidden behind a geofence.

    • Re-checked from more than one network, because plenty of kits filter by region
    • Content compared against the captured hash to catch a partial takedown
    • Closes with a removal timestamp you can hand to an auditor or a regulator

    ProducesClosure record with a verified removal time

  7. Step 07

    Watch for the return

    Platform

    A removed domain does not stay removed on its own. The string stays on watch, and so does the operator's infrastructure. If the same kit reappears under a new name, or the domain is re-registered after it drops, the original case reopens instead of a fresh one being raised.

    • Re-registration monitoring that continues past the drop date
    • Kit and infrastructure fingerprints matched against every new detection
    • History stays attached, so a repeat operator shows up as a pattern

    ProducesReopened case, linked to the original

Evidence pack

A takedown succeeds or fails on the evidence

Providers do not remove things because you asked. They remove things because someone handed them a record that clearly breaches their own policy, in the format their abuse team reads. So we capture the target the moment we find it, before the operator notices attention and pulls it down.

Evidence packcase BP-4182Illustrative — fictional brand, invented values

Contents

  • Full-page render1440 × 4820 · timestamped at capture
  • Served HTML + headers84 KB · captured with the render
  • WHOIS recordqueried at capture
  • Hosting and networkresolved from 3 vantage points
  • TLS certificate chainleaf + 1 intermediate
  • Change historyre-checked on a schedule since first seen

Findings

Target
login.northgate-bank.examp1e
Registered
2026-09-02 04:11 UTC
First seen by us
minutes after registration appeared in the feed
Name servers
ns1.dns.example · ns2.dns.example
Hosting
bulk VPS provider, dedicated address
TLS issuer
free 90-day domain-validated CA
Certificate SANs
northgate-bank.examp1e · login.northgate-bank.examp1e · secure.northgate-bank.examp1e
Login form
present — username, password, one-time code
Form action
POST /api/collect.php (same host)
Borrowed assets
4 of 11 loaded from northgate-bank.example
Mail
MX configured · no SPF record
Body hash
sha256:9f2c4a…c41b

Nothing above is a real case. It shows the shape of a pack, assembled against the fictional brand used throughout this page.

What each artefact is doing there

  • Full-page screenshot

    Rendered at the size a victim would see, with the address bar contents recorded next to it. Abuse reviewers act on what they can look at — a written description of a page is not evidence of one.

  • DOM and response capture

    The served HTML, the response headers and the form action. This is what turns “looks like a copy of your site” into “posts credentials to this endpoint”, which is the sentence an abuse desk can act on.

  • WHOIS and registration record

    Registrar of record, creation date, name servers and the published abuse contact. It tells us where to file — and a creation date measured in days is itself part of the argument.

  • Hosting and network

    Address, network owner, reverse DNS and whatever sits in front. Gives us a second party to file with when the registrar is slow, and links the page to its siblings on the same infrastructure.

  • TLS certificate

    Issuer, issuance time and the subject alternative names. Certificate transparency frequently surfaces a name before any page exists, and the SAN list hands over the operator's other domains.

  • First-seen and change history

    When we first saw it, and every change since. It separates a parked registration from one that went live at two on a Saturday morning, and it proves the state of the page at the moment we filed.

Executive and VIP protection

The cheapest way in is to be someone your staff trust

Impersonating a company takes a domain. Impersonating a named executive takes a profile photo and ten minutes, and it works because the request comes from a person rather than a brand. You nominate who is covered; we watch the names, the handles and the domains built out of them.

  • Fake profiles of named people

    A profile carrying your CFO's name, title and career history, then connecting to your staff, your suppliers and your customers. Everything it needs is already public. We match on name variants, handle mutations and reused profile text, across the platforms your people actually use.

  • Wire-fraud pretexting

    A lookalike personal domain, a display name that matches exactly, a short note about an urgent payment while the real person is known to be travelling. We watch for registrations pairing an executive's surname with your brand, and for display-name spoofing showing up in your DMARC reports.

  • Fake assistants and recruiters

    Accounts claiming to work for you, approaching candidates, journalists or investors on your behalf. They never touch your infrastructure, so nothing in your security stack sees them — the first you hear is usually a confused email from the person they contacted.

Protected rosterIllustrative
  • Chief Executive

    • Name variants
    • Handles
    • Lookalike personal domains
    • Photo reuse
  • Chief Financial Officer

    • Name variants
    • Display-name spoofing
    • Payment-themed lookalikes
    • Handles
  • Head of Payments

    • Name variants
    • Support-handle impersonation
    • Handles

Roles, not people. You choose who is on the list and can change it whenever the org chart does.

What we do not do

We look for impersonation of a name and a role you nominate. We do not connect to an executive's private accounts, read their messages, or track their personal activity, and we hold only the details needed to tell a fake apart from the real person. If a nominated individual's own credentials or contact details turn up in breach data, that surfaces through dark web monitoring instead.

Setting expectations

We will not promise you a takedown time

Removal speed is decided almost entirely by whoever has to press the button. A registrar with a staffed abuse desk behaves nothing like a registry that wants a notarised trademark filing, and a large platform's brand team works to its own queue. An average across all of them would tell you nothing useful about your next case — so we report the case instead, in detail, including when it is going badly.

  • In our hands

    • How quickly a registration or a live page is detected
    • How complete the evidence pack is at the moment we file
    • Which party we file with, and on what grounds
    • How often the case is chased, and how far it is escalated
    • Whether the indicators reach browser and mail blocklists in the meantime
    • Whether removal is verified rather than assumed
  • Not in our hands

    • The provider's queue depth and staffing on the day
    • Their evidence bar, which differs between registrars, registries and platforms
    • Jurisdiction, local process and the public-holiday calendar
    • Whether the operator moves hosting before the case lands
    • Whether a registry insists on a registered trademark
    • Whether a platform decides its own policy has not been breached

Every case sits at one of these, with a timestamp on each change

  • Detected
  • Evidence captured
  • Under review
  • Filed
  • Awaiting provider
  • More info requested
  • Removed (verified)
  • Not actionable
  • Watching

No case sits in a generic “in progress”. You can see which party it is with, what they last asked for, what we last sent, and how long it has been there — which is also what you need when someone senior asks why a fake login page is still online.

What happens while a case is open

  • Get it flagged while it is still up

    Indicators go to browser and mail blocklists wherever a submission route exists, so a victim who clicks may see a warning before the page is gone.

  • Push it into your own controls

    The same indicators export to your mail gateway, proxy, DNS filtering and EDR, so your staff and your network are covered independently of the takedown.

  • Say so when it cannot be removed

    Some registries and jurisdictions will not act. We close the case as not actionable, hand you the evidence for legal or law-enforcement use, and keep watching in case a change gives new grounds.

Questions

Brand protection, answered plainly

The five things security and legal teams ask before they hand a takedown process to somebody else.

It helps, and a few registries insist on it. Plenty of cases succeed on abuse grounds instead — a page harvesting credentials breaches almost every provider's terms whether or not a mark is registered. We tell you which route we are using for each case, and what, if anything, we need from your legal team.

Find out who is already using your name.

We run detection against your real brands, domains and nominated executives, then walk you through whatever comes back — including the things you cannot act on.

  • Scoped to your brands and executives
  • Evidence pack on every finding
  • Findings are yours to keep