Typo-Squatting Detection

Overview

Typo-squatting (also called URL hijacking) is when attackers register domain names that are visually similar to legitimate domains, exploiting common typing errors or visual confusion to deceive users.

Scope note: this topic covers misspellings — names that differ from the target by an edit, a homoglyph, or a TLD swap. It does not cover correctly-spelled names that combine a brand with a product or function word (exampledrive.com, example-billing.net). Those are found by substring search rather than fuzzy matching, and they defeat a different set of checks — age, a redirect to the brand’s real site, and a brand-shaped MX. See datapulse_help(topic="brand_adjacent") for that shape.

Defensive Registration

Important context: Reputable domain owners often proactively purchase confusingly similar domains to protect their brand. A typo-squatted domain whose address records point at the same infrastructure as the legitimate domain is consistent with defensive registration, but only when that infrastructure is the brand’s own: a shared CDN or parking IP is not evidence of anything, so corroborate with registrar and creation date before concluding.

“Same infrastructure” means the A/AAAA records, not where a redirect lands. A domain that redirects to the brand’s real site ends up on the brand’s infrastructure while its own address records point somewhere else entirely. In that case the page you render and the TLS certificate you validate belong to the redirect destination and say nothing about the domain under investigation. Compare scrape.final_url and scrape.tls.subject against the domain you asked about, and resolve its address records separately. A redirect to the brand issued from a general-purpose VPS is a third party pointing at the brand, not a defensive registration.

Common Typo-Squatting Techniques

Detection Workflow

Step 0: Discover Typosquatting Domains

Use datapulse_dns_searchlabels to find domain labels similar to your target:

datapulse_dns_searchlabels(search_term="example")

This returns matching labels with their TLD spread. Focus on:

• Fuzzy matches with low scores (few edits from original) — likely typosquatting
• High TLD count on a fuzzy match — widespread registration is a red flag
• Substring matches — may be legitimate or brand abuse

Step 1: Analyze Suspected Typo-Squatted Domain

datapulse_live_dns(domain="examp1e.com")
datapulse_live_dns(domain="example.com")

Compare IP addresses—same infrastructure suggests defensive registration.

Step 2: Check Registration Details

datapulse_live_rdap(query="examp1e.com")
datapulse_live_rdap(query="example.com")

Registrant identity is GDPR-redacted in RDAP — infer relationships from registrar and infrastructure, not contacts (see datapulse_help(topic="registrant_lookup")).

Defensive registration indicators:

• Same registrar (especially MarkMonitor, CSC for enterprise)
• Similar creation dates
• Same nameservers

Indicators that warrant investigation (none is proof of malice on its own):

• Different registrar/infrastructure from the brand — inconsistent with defensive ownership, not malicious by itself
• Recent creation date
• Different nameservers

Step 3: Historical Analysis

datapulse_dns_dphistory(domain="examp1e.com")

What to look for:

• When did the domain first appear?
• Has it changed infrastructure recently?
• Does history show parking pages or redirects?

Risk Assessment Matrix

IDN Homograph Attacks

Internationalized Domain Names (IDN) enable Unicode characters that look identical to ASCII:

Detection: Look for xn-- prefix in Punycode representation:

datapulse_live_dns(domain="xn--exmple-cua.com")

MX Record Analysis

Typo-squatted domains with MX records are particularly dangerous—they can intercept misdirected emails. The datapulse_live_dns response includes MX records alongside all other record types.

Red flags:

• MX records present on typo domain
• Different mail infrastructure than legitimate domain
• Generic mail providers (could receive misdirected mail)

MX presence is not the whole question. An MX record is an unverified claim: anyone may publish one pointing at any host, including a major provider’s, without that provider having provisioned anything. Confirm the named platform actually accepts the domain before treating the record as evidence of a working mail path, and read SPF and DMARC separately — their absence makes a domain spoofable outbound whether or not it can receive mail. See datapulse_help(topic="brand_adjacent").

Related Topics

• datapulse_help(topic="brand_adjacent") - Correctly-spelled brand+product names that pass the age, redirect, and MX checks
• datapulse_help(topic="subdomain_cloaking") - Hostnames that hide attacker control behind trusted-looking labels
• datapulse_help(topic="rdap") - RDAP registration data interpretation
• datapulse_help(topic="reconnaissance") - Full domain investigation
• datapulse_help(topic="dns") - DNS lookup tools