Knowing a lookalike exists is useful. Knowing that one of your own people resolved it this morning is an incident. This page defines the term, separates it from the five things it gets confused with, and explains which half of the problem is actually visible on your network.
MITRE ATT&CK techniques covered: T1566.002 Phishing: Spearphishing Link · T1583.001 Acquire Infrastructure: Domains · T1584 Compromise Infrastructure · T1105 Ingress Tool Transfer
Brand impersonation is somebody presenting themselves as your company in order to deceive the people who trust it - your customers, your staff or your suppliers. In practice that is almost always a domain name, a website or a mobile application built to be mistaken for yours.
The term gets used for five different problems that have different owners and different fixes, which is why searching for it returns such a mixture. They are worth separating before deciding what to buy:
A domain that imitates your name is, on its own, a filing. It sits there. Brand-monitoring services will tell you it exists, and that is worth knowing, but it is not yet an event and nothing has touched your organisation.
It becomes an incident at a specific moment: when somebody inside your network looks it up or opens it. That is the step where a registration turns into an attempt on a credential, and it is the step a registry watchlist cannot see, because it does not happen at the registry. It happens on your network.
This is the distinction that decides what any product in this space can honestly claim. Monitoring the world's registrations is a feed. Observing your own traffic is evidence, with a host and a timestamp on it. Most of the market sells the first and implies the second.
The same contact is caught two separate ways, and either one alone raises the finding:
Nearly every lookalike obtains a TLS certificate, because a site without one throws a browser warning and defeats its own purpose. Certificates are logged publicly and permanently in certificate transparency, so the registration usually announces itself days before anybody is targeted.
Those names are scored against your confirmed brand terms, and only the candidates that score into the action band are surfaced. The point is not to hand you every string sharing three letters with your company; it is to keep the list short enough that somebody actually reads it.
Your brand team can also pin a name directly - one a customer reported, or one already under a takedown request - and it is watched on the network from that moment, without waiting for the next scoring cycle.
A phishing page takes one password, once. An application installed on the phone sees every login afterwards, sees the one-time code that arrives next to it, and survives the password change made when somebody realises. That is why a serious campaign wants an app on the device, and why it has to arrive from outside the official store - Google and Apple review what is in theirs.
Both routes are visible as traffic. On Android it is an application package pulled over an unencrypted connection, where nothing verifies what actually arrived, so the installed bytes are whatever the network supplied. On iOS the stronger move is a configuration profile, which can install a root certificate, a proxy or a device-management enrolment and so takes control of the handset without an app at all - and because Apple requires those to be delivered over HTTPS, delivery in the clear is itself the finding.
Contact with an app mirror or a re-signing service is counted separately and carries no attack technique. Those are not the attacker. They show the device was already configured to install from outside the store, which is the condition that made the rest possible.
Once, at setup: the brand terms you want watched, and the domains that are genuinely yours.
Be deliberate about that second list. It is a suppression list and it covers everything beneath a name, so anything on it is never reported again - which is correct for your own estate and wrong for anything you are not sure of. If you are uncertain whether a domain is yours, leave it off. A finding you dismiss costs a minute; a silently suppressed one costs you the detection.
The mobile side needs no configuration at all.
We do not take the domain down. That is a registrar and legal process, and we give you the evidence pack for it rather than pretending to be it.
Certificate transparency finds names that obtained a certificate. A lookalike that never gets one is invisible to that half - which is exactly why the network half exists, and why contact is detected whether or not the name was ever discovered in advance.
This is not app-store monitoring. It detects an app reaching a device from outside the store, on your network. That is a different thing and worth being precise about.
And it says nothing about counterfeit goods, trademark misuse or a fake social-media profile. Those are real problems and they are not network problems, so no network sensor should claim them.
Somebody presenting themselves as your company to deceive the people who trust it. In practice that is usually a domain, a website or a mobile app built to be mistaken for yours, used to collect credentials, payments or personal data.
Typosquatting is one technique for achieving it - registering a misspelling of your domain. Brand impersonation is the broader goal, and it can also be done with a different top-level domain, a hyphenated variant, a lookalike character or a mobile app that never involves a domain resembling yours at all.
Domain spoofing forges your domain in the FROM field of an email. Nothing is registered and nothing is hosted; it is fixed with SPF, DKIM and DMARC by your email team. Brand impersonation involves a real address somebody can visit, which is why it shows up as traffic on a network rather than as a header in a mail gateway.
No, and the difference decides who handles it. A cybersquatter registers a name hoping to sell it to you. There may be no attack and no victim, and the remedy is a legal one. It becomes a security matter only when the name is used against your people.
That is the question this detects. The lookalike name is matched against your own network traffic in two independent places - the DNS lookup and the TLS server name in the handshake - so a hit names the internal host and the time.
It overlaps at one end and not the other. A monitoring service tells you a lookalike was registered. This also tells you whether anybody inside your organisation has contacted it, which is what turns a watchlist entry into an incident you can act on.
No. Takedown is a registrar and legal process. What you get here is the evidence pack that makes the request credible: the name, the hosts that reached it, when, and in which protocol it was seen.
Candidates are scored against your confirmed brand terms and only those in the action band are raised. The practical test is the one we would apply to any detection: if the list is too long to read, it is not working, and the threshold is the thing to adjust.
Yes, when it reaches a device on a network you have mirrored. An Android package or an iOS configuration profile fetched over an unencrypted connection is detected directly, and contact with a third-party app source is reported separately as the condition that allowed it.
The network half needs no setup and reports from the first mirrored traffic. The certificate-transparency half begins once your brand terms are confirmed, and sees new registrations on its next polling cycle.
Tell us whether you suspect something is already inside, or whether you want to measure what your current tools would catch. Either way you get a concrete next step.
Contact us