Typosquatting turns a single mistyped character, a swapped letter or a visually identical Unicode glyph into a working phishing site, a mail server that catches misdirected email, or a malicious package installed by a build pipeline. The same idea runs through domain names, package registries such as npm and PyPI, browser extensions and even collaboration workspace names. This guide explains how lookalike names are built, where they appear, how to find them early through Certificate Transparency and permutation monitoring, and how to get them removed through registrars, the UDRP and the URS. It is written for security operations, brand protection, email and platform engineering teams who need a repeatable programme rather than one-off takedowns.
Key takeaways
- Lookalikes are cheap and predictable. Omitted, doubled, swapped and adjacent-key characters, hyphenation, alternative TLDs and homoglyphs cover most real cases, so the space can be enumerated and watched.
- DMARC does not stop cousin domains. RFC 7489 states that DMARC only addresses exact-domain spoofing, so lookalike domains need monitoring and takedown, not just email authentication.
- Certificate Transparency is the best early signal. Most phishing sites use HTTPS, and every publicly trusted certificate is logged, so CT monitoring often flags a lookalike before the first lure is sent.
- Takedown has three speeds. Registrar and host abuse reports can work in hours, the URS suits clear-cut gTLD cases, and the UDRP (about two months at WIPO) transfers or cancels the domain.
- Package typosquats target machines, not people. A CI job that installs a misspelled dependency runs attacker code with the pipeline's tokens, so registry controls and allowlists matter as much as domain monitoring.
How the attack works
An attacker registers a name that a person or a program will mistake for a trusted one, then puts something behind it: a cloned login page, a mail exchanger, a download, or a package with an install script. The registration itself maps to MITRE ATT&CK T1583.001 Acquire Infrastructure: Domains, or T1584.001 Compromise Infrastructure: Domains where an existing domain or subdomain is taken over. Naming a malicious artefact to match a legitimate one is T1036.005 Match Legitimate Resource Name or Location.
| Technique | Example of the trusted name examplebank.com | What catches it |
|---|---|---|
| Omission or repetition | exampebank.com, examplebannk.com | Permutation monitoring, CT search |
| Transposition or adjacent key | exmaplebank.com, exanplebank.com | Permutation monitoring |
| Hyphenation and combosquatting | example-bank.com, examplebank-login.com | Keyword match on CT and new registrations |
| TLD swap | examplebank.co, examplebank.support | Defensive registration, TLD list monitoring |
| Subdomain deception | examplebank.com.account-check.net | Registrable-domain parsing, URL rewriting in email gateway |
| IDN homograph | Cyrillic а in place of Latin a | Unicode skeleton comparison, browser punycode display |
| Bitsquatting and visual pairs | rn for m, l for I | Confusable mapping, similarity scoring |
Homographs and the Unicode skeleton
Internationalised domain names allow non-Latin characters, which are stored in DNS as punycode. Unicode Technical Standard #39 defines how to detect confusables: each string is reduced to a skeleton using the confusables.txt mappings, and two strings are confusable when their skeletons match. UTS #39 separates single-script, mixed-script (Latin mixed with Cyrillic) and whole-script confusables (every letter Cyrillic but visually Latin), and defines restriction levels from ASCII-Only to Unrestricted. Chromium applies these rules per label: it shows punycode for labels that mix Latin, Cyrillic and Greek, for whole-script confusables outside the matching TLD, and when the skeleton of the registrable part matches a top domain. A separate lookalike interstitial warns when a skeleton matches a site the user engages with or a top 500 domain. Browser protection helps, but it does not cover email clients, chat apps or printed links.
Where it shows up
- Credential phishing: a lookalike domain with a valid certificate hosts a cloned single sign-on page. See the Phishing Guide and the AiTM Phishing Guide for the session-theft variant.
- Business email compromise: a cousin domain sends invoices or payment-change requests that pass SPF, DKIM and DMARC because the attacker owns the domain. See the Email Identity and BEC Guide.
- Misdirected email capture: a typo domain with an MX record receives mail that staff or partners mistype. Permutation tools such as dnstwist explicitly check for rogue MX hosts for this reason.
- Malicious ads and fake downloads: lookalike domains sit behind search ads for popular software, and the FBI's December 2022 public service announcement described criminals buying search ads that use domains closely resembling real businesses. See the Secure Web Gateway and Web Filtering Guide.
- Package registries: npm, PyPI, crates.io, Go modules, container registries and IDE marketplaces all accept free, near-instant publication. In August 2017 the npm user
hacktaskpublished 40 packages with names close to popular ones, includingcrossenvimitatingcross-env, which stole environment variables on install. In March 2024 PyPI temporarily suspended new project creation and new user registration for about 10 hours while roughly 500 typosquatted packages imitating tools such as Requests and Colorama were removed. See the Malicious Package and Dependency Confusion Guide and, for names invented by AI coding tools, the Slopsquatting and Package Hallucination Guide. - Extensions, plugins and AI tooling: browser extensions, MCP servers and agent skills published under familiar brand names. See the Browser Extension Security Guide.
Impact
| Target | Typical outcome | Who pays |
|---|---|---|
| Employees | Stolen passwords, session cookies and MFA approvals | The organisation, through account takeover |
| Customers | Fake support, refund or investment sites using your brand | Customers first, then your fraud and support costs and reputation |
| Partners and suppliers | Payment redirection from a cousin domain in an existing thread | Whichever party's controls failed, often disputed |
| Build systems | Install-time code execution with CI secrets, cloud keys and publish tokens in reach | The organisation and everyone downstream of its software |
| Email confidentiality | Mistyped outbound mail silently delivered to an attacker MX | Data subjects and the organisation (possible personal data breach) |
Detection
Certificate Transparency monitoring
Certificate Transparency (RFC 6962, updated as version 2.0 by the Experimental RFC 9162) records publicly trusted TLS certificates in append-only Merkle tree logs. RFC 9162 notes that anyone can monitor the logs and that domain holders can watch for certificates they did not expect. Stream new log entries, normalise each name (lower case, punycode decoded, registrable domain extracted), and alert on brand keywords, permutations and skeleton matches. The same feed catches certificates misissued for your real domains.
Permutation and registration monitoring
- Generate the candidate set: open source tools such as dnstwist generate permutations (homoglyph, hyphenation and other fuzzers), resolve them, flag rogue MX hosts and compare web content with fuzzy hashes (ssdeep or TLSH) and screenshot perceptual hashes.
- Watch new registrations: newly registered domain feeds and zone files for gTLDs add names that never get a certificate, such as mail-only domains.
- Score, do not just list: rank by MX present, web content similar to yours, certificate issued, registration age under 30 days and brand terms in the subdomain. A parked typo with no records is low priority; a new domain with MX and a cloned login page is an incident.
- Use your own telemetry: email gateway logs (inbound From and Reply-To domains within a small edit distance of yours or your top suppliers'), DNS resolver logs, web proxy logs and DMARC aggregate reports for senders you do not recognise.
Package registry detection
- Compare every new direct or transitive dependency against an internal approved list and against popular package names using edit distance and punctuation-stripped comparison. npm itself blocks new names that differ from an existing package only in dots, dashes and underscores (since December 2017) and states that it detects typosquats at publish time, but registry checks are not complete.
- Alert on install scripts (
preinstall,postinstall,setup.pyexecution) in packages first seen in your estate, and on CI jobs making outbound connections to hosts outside the registry and artefact store.
Metrics that show the programme works
- Median time from certificate issuance or registration of a high-risk lookalike to triage.
- Median time from abuse report to the lookalike being offline (by route: registrar, host, URS, UDRP).
- Percentage of high-risk permutations of each primary brand domain that are defensively held.
- Number of new dependencies blocked or quarantined pending review per month, and the share later confirmed malicious.
- User-reported lookalikes per month, which should rise after awareness campaigns, not fall.
Prevention and hardening
Defensive registration and domain hygiene
- Register the high-risk set: primary brand in the major gTLDs and the ccTLDs where you trade, the most likely single-character errors and obvious combosquats (login, support, pay). Registering every permutation is impossible; prioritise by scoring and by what attackers have already used against you.
- Lock and park safely: enable registrar and registry lock on primary domains. For defensive and parked domains publish a null MX (RFC 7505), an SPF record of
v=spf1 -alland a DMARC record withp=rejectso they cannot be used to send mail in your name. See the DMARC, SPF and DKIM Guide. - Enforce DMARC on real domains: move from
p=nonetoquarantinetoreject, setspfor subdomains and collectruareports. This removes exact-domain spoofing so lookalikes become the attacker's only option, which is easier to monitor. - Remove dangling records: CNAMEs pointing at deleted cloud resources enable subdomain takeover (T1584.001). See the DNS Security Guide.
Takedown routes
| Route | Use when | Outcome and timing |
|---|---|---|
| Hosting provider, CDN and certificate authority abuse report | Active phishing or malware content | Content removed or certificate revoked; often hours when evidence is clear |
| Registrar abuse report | Domain used for phishing, malware or fraud | Suspension at the registrar's discretion. Under section 3.18 of ICANN's 2013 Registrar Accreditation Agreement registrars must publish an abuse contact and take reasonable and prompt steps to investigate; non-response can be escalated through ICANN Compliance |
| Browser and email blocklists (Safe Browsing, SmartScreen, protective DNS) | In parallel with every other route | Users warned or blocked while the domain still resolves |
| Uniform Rapid Suspension (URS) | Clear-cut trademark infringement in new gTLDs | Suspension, not transfer; clear and convincing evidence standard; lower cost and faster than the UDRP |
| UDRP (WIPO and other ICANN-approved providers) | You want the domain transferred or cancelled | Complainant proves the three elements of paragraph 4(a). At WIPO a 1-5 domain case with one panelist costs USD 1,500 and normally finishes within about two months; no damages |
| Court action or ccTLD dispute policy | ccTLDs that have not adopted the UDRP, or damages are sought | Varies by jurisdiction and registry |
The UDRP's three elements are: the domain is identical or confusingly similar to a mark in which the complainant has rights; the registrant has no rights or legitimate interests in it; and it was registered and is being used in bad faith. Paragraph 4(b) lists bad-faith indicators, including using the domain to attract users for commercial gain by creating confusion with the mark. The respondent has 20 days to reply, and the registrar implements a transfer or cancellation 10 business days after the decision unless court proceedings are filed. ICANN updated the UDRP Policy and Rules on 21 February 2024, with registrars required to implement them by 21 August 2025. Collect evidence before reporting: screenshots, full URLs, WHOIS or RDAP output, DNS records, certificate details and sample emails with headers.
Package and build controls
- Install only from an internal proxy or artefact repository with an allowlist of approved packages and versions; block direct installs from public registries in CI.
- Commit lockfiles and use install modes that fail on drift (
npm ci); disable install scripts by default where your tooling allows it and enable them per package. - Use scoped names (
@org/package) for internal npm packages, as npm recommends, and reserve your organisation's names and scopes on public registries. - Give CI jobs short-lived, narrowly scoped credentials so a malicious install cannot reach publish tokens or production keys. See the Software Supply Chain Security Guide.
People and process
- Publish the list of domains you legitimately use (including for HR, payroll and marketing platforms) so staff and customers can check.
- Enforce out-of-band verification for any change to bank details, whatever domain the request comes from.
- Use phishing-resistant MFA so a credential entered on a lookalike site cannot be replayed: FIDO2 credentials are bound to the real origin. See the Phishing-Resistant MFA Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1583.001, T1584.001, T1608.005, T1566.002, T1036.005, T1195.001 | Lookalike registration, subdomain takeover, staged link targets, phishing links, name matching, poisoned dependencies |
| MITRE D3FEND | D3-DNSDL DNS Denylisting, D3-URA URL Reputation Analysis | Blocking and scoring lookalike destinations |
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring, SC-20 Secure Name/Address Resolution Service, SR-4 Provenance, SR-11 Component Authenticity, PM-16 Threat Awareness Program | Monitoring, DNS integrity, package provenance and authenticity |
| NIST CSF 2.0 | ID.RA-03, DE.CM-01 | Threat identification and network monitoring |
| CIS Controls v8.1 | 9.2 Use DNS Filtering Services, 9.5 Implement DMARC, 16.5 Use Up-to-Date and Trusted Third-Party Software Components | Blocking, email authentication and trusted dependencies |
| ISO/IEC 27001:2022 Annex A | 5.7 Threat intelligence, 8.23 Web filtering | Lookalike intelligence feeds and blocking |
Lessons from incidents
- A familiar name is not a publisher check. The postmark-mcp malicious MCP server carried an email provider's name and behaved normally for fifteen versions before adding a hidden blind copy to every email. Verify the publisher account and repository, not the package name.
- Registry name rules do not cover everything. The PyTorch torchtriton attack used dependency confusion rather than a misspelling, but the defence is the same: resolve internal names only from your own index.
- Monitoring without a takedown owner fails. Teams that collect lookalike alerts but have no agreed route, evidence template or authority to file a UDRP watch the same domains reappear.
- Exact-domain controls create false comfort. A DMARC
p=rejectscore does nothing against a cousin domain the attacker owns and authenticates properly.
Practitioner checklist
- List primary brand domains, product names, package scopes and top supplier domains as the watch list.
- Stream Certificate Transparency logs and newly registered domain feeds, scored by MX, web similarity and age.
- Defensively register the highest-risk permutations and TLDs, and lock primary domains at registrar and registry.
- Publish null MX,
v=spf1 -alland DMARCp=rejecton every parked domain. - Enforce DMARC on sending domains and review aggregate reports monthly.
- Agree a takedown runbook: evidence template, abuse contacts, blocklist submissions, URS and UDRP decision criteria and budget.
- Route package installs through an internal repository with an allowlist, lockfiles and install scripts disabled by default.
- Reserve your names on public registries and use scoped internal packages.
- Deploy phishing-resistant MFA for workforce and administrative accounts.
- Track time to detect and time to takedown, and report both quarterly.
Standards and references
- WIPO: Guide to the Uniform Domain Name Dispute Resolution Policy (UDRP)
- ICANN: Uniform Domain-Name Dispute-Resolution Policy
- ICANN: Uniform Rapid Suspension (URS)
- IETF: RFC 9162 Certificate Transparency Version 2.0
- Unicode Consortium: UTS #39 Unicode Security Mechanisms
- IETF: RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- Chromium: IDN in Google Chrome
- MITRE ATT&CK: Acquire Infrastructure: Domains
Related NHI Mgmt Group resources: Top 10 Phishing Techniques · Open Source Security Guide · Email Security Guide · Threat Intelligence Guide