Typosquatting : définition, détection et recours, mesurés sur notre
propre domaine

Le typosquatting (ou typosquattage) consiste à enregistrer un nom de domaine qui ressemble à celui d'une marque, en pariant sur une faute de frappe, une lecture rapide ou une extension oubliée. C'est une branche du cybersquattage, qui désigne plus largement tout dépôt de mauvaise foi d'un nom reprenant la marque d'autrui. Plutôt que de le décrire sur un domaine imaginaire, j'ai passé le 22 septembre 2026 notre propre domaine, own2pwn.fr, dans dnstwist. Tous les chiffres et toutes les sorties de terminal de cette page viennent de cette mesure, commandes comprises, pour que vous puissiez la refaire sur le vôtre.

Ce que génère dnstwist sur un nom de sept caractères

dnstwist applique une série d'algorithmes, qu'il appelle des fuzzers, puis interroge le DNS pour chaque nom produit. La première commande génère tout, sans filtrer, en imposant deux résolveurs publics (on verra plus bas pourquoi ce paramètre n'est pas un détail) :

$ dnstwist --nameservers 1.1.1.1,9.9.9.9 -t 8 --format json own2pwn.fr > all.json
# start_utc: 2026-09-22T19:51:38Z   end_utc: 2026-09-22T19:51:45Z   rc=0

$ jq -r '.[] | select(.fuzzer!="*original") | .fuzzer' all.json | sort | uniq -c | sort -rn
     93 homoglyph
     68 insertion
     36 addition
     31 bitsquatting
     28 replacement
      7 omission
      6 transposition
      6 hyphenation
      5 subdomain
      5 repetition
      3 vowel-swap
      3 various
      2 plural

Deux enseignements tombent de cette répartition. D'abord, les homoglyphes pèsent près d'un tiers du total, et 58 d'entre eux sont des noms internationalisés encodés en punycode (xn--…) : un caractère cyrillique ou accentué qui, à l'écran, se confond avec la lettre latine. Ce sont les variantes qu'aucune relecture humaine n'attrape, et les seules qu'un dépôt défensif ne peut pas raisonnablement couvrir. Ensuite, les fautes de frappe au sens strict (omission, transposition, répétition) ne représentent que 18 noms sur 293. Le typosquatting ne se limite donc pas aux fautes de frappe : sur ce nom, l'essentiel du volume vient des caractères insérés, ajoutés et des bits inversés. Le bitsquatting parie sur une erreur matérielle, un bit de mémoire qui bascule et change une lettre en une autre voisine en binaire ; rare, mais dnstwist le génère par défaut.

Ce qui existe vraiment : deux réponses, zéro squat

La même recherche avec --registered ne garde que les noms qui obtiennent une réponse DNS, et --whois ajoute date de création et registrar. Sortie réelle, raccourcie à ses champs utiles :

$ dnstwist --nameservers 1.1.1.1,9.9.9.9 -t 8 --registered --whois --format json own2pwn.fr
[
  { "domain": "own2pwn.fr",  "fuzzer": "*original", "dns_a": ["164.68.99.194"],
    "dns_mx": ["aspmx1.migadu.com"], "whois_created": "2020-05-29", "whois_registrar": "OVH" },
  { "domain": "own2.pwn.fr", "fuzzer": "subdomain", "dns_a": ["!ServFail"],
    "whois_created": "2006-06-26", "whois_registrar": "Dynadot Inc" },
  { "domain": "own2p.wn.fr", "fuzzer": "subdomain", "dns_a": ["213.186.33.5"],
    "whois_created": "2015-03-09", "whois_registrar": "OVH" }
]
# start_utc: 2026-09-22T19:51:45Z   end_utc: 2026-09-22T19:51:49Z   rc=0

Les deux "sosies" n'en sont pas. Le fuzzer subdomain coupe le nom par un point, si bien que own2.pwn.fr est un sous-domaine de pwn.fr et own2p.wn.fr un sous-domaine de wn.fr. Les dates WHOIS le trahissent : 2006 et 2015, soit celles des domaines parents, déposés des années avant own2pwn.fr (2020). Un dig direct le confirme, et montre au passage que dnstwist compte comme "enregistré" un nom qui ne répond que par une erreur :

$ for d in own2.pwn.fr own2p.wn.fr pwn.fr wn.fr; do for t in A NS MX; do echo "$d $t: $(dig @1.1.1.1 +short $t $d | tr "\n" " ") [status $(dig @1.1.1.1 $t $d | grep -o "status: [A-Z]*")]"; done; done
own2.pwn.fr A:  [status status: SERVFAIL]
...
own2p.wn.fr A: 213.186.33.5  [status status: NOERROR]
...
pwn.fr A:  [status status: SERVFAIL]
...
wn.fr A: 185.199.111.153 185.199.109.153 185.199.108.153 185.199.110.153  [status status: NOERROR]
wn.fr NS: dns100.ovh.net. ns100.ovh.net.  [status status: NOERROR]

pwn.fr répondait SERVFAIL à 1.1.1.1 au moment de la mesure, et son sous-domaine hérite de l'erreur. Une ligne !ServFail dans un rapport dnstwist n'est pas une preuve d'existence, et c'est ce qui rend le piège suivant si trompeur.

Le changement d'extension : une sur quinze

dnstwist ne teste d'autres extensions que si on lui en donne la liste. J'en ai retenu quinze, génériques et nationales, avec --tld. Une seule est déjà prise :

$ dnstwist --nameservers 1.1.1.1,9.9.9.9 -t 4 --registered --whois --tld tld.txt --format json own2pwn.fr
  ...
  { "domain": "own2pwn.xyz", "fuzzer": "tld-swap", "dns_a": ["194.147.98.229"],
    "dns_ns": ["ns7.alidns.com"], "whois_registrar": "GMO Internet Group, Inc. d/b/a Onamae.com" }

$ for t in A AAAA NS MX TXT; do echo "$t: $(dig @1.1.1.1 +short $t own2pwn.xyz | tr "\n" " ")"; done
A: de6p34hg.seckd-cname.com. mqgj2p9t.seckd-cname.com. 94.154.114.169 194.147.98.229
AAAA: de6p34hg.seckd-cname.com. mqgj2p9t.seckd-cname.com.
NS: ns8.alidns.com. ns7.alidns.com.
MX:
TXT:

$ whois own2pwn.xyz | grep -iE "creation|created|updated|expir|registrar:|status|name server" | head -20
Updated Date: 2025-10-15T04:57:06.0Z
Creation Date: 2025-10-10T04:52:28.0Z
Registry Expiry Date: 2026-10-10T23:59:59.0Z
Registrar: GMO Internet Group, Inc. d/b/a Onamae.com
...

own2pwn.xyz a été déposé par un tiers le 10 octobre 2025, cinq ans après own2pwn.fr. Il résout vers deux adresses IP via des CNAME, et ne publie ni MX ni TXT, donc aucun serveur de réception déclaré et aucun SPF. Ces constats ne disent rien de l'intention du titulaire, et je ne les interprète pas plus loin. Ils fixent en revanche ce qu'il faut surveiller : l'apparition d'un MX, d'un enregistrement SPF ou d'un certificat pour ce nom changerait sa nature, de même que son éventuel non-renouvellement à l'échéance d'octobre 2026. Attention à une lecture trop rassurante de l'absence de MX : elle n'empêche en rien d'émettre des courriels depuis ce nom, ce qui compte pour l'usurpation d'identité d'entreprise par courriel.

Le piège du résolveur saturé : 232 faux positifs

Mon premier passage n'a pas produit ces chiffres. J'avais lancé deux dnstwist en parallèle sans l'option --nameservers, donc contre le résolveur local de la machine (systemd-resolved devant dnsmasq). Plusieurs centaines de requêtes simultanées (estimation) l'ont saturé, il a répondu SERVFAIL à tout, et dnstwist a interprété chaque SERVFAIL comme une réponse :

$ dnstwist --registered --whois --format json own2pwn.fr > registered.json
# start_utc: 2026-09-22T19:49:50Z   end_utc: 2026-09-22T19:51:17Z   rc=0

$ jq 'length' registered.json
233
$ jq '[.[] | select(.dns_a == ["!ServFail"])] | length' registered.json
232
$ jq -c '.[0] | {domain, dns_a}' registered.json
{"domain":"own2pwn.fr","dns_a":["!ServFail"]}

233 domaines "enregistrés" au lieu de 3, en 87 secondes au lieu de 4. Le symptôme qui aurait dû suffire est la première ligne : le domaine d'origine lui-même en !ServFail, alors qu'il répond normalement. Un rapport de ce genre, transmis tel quel, déclenche une alerte sur des dizaines de "clones" qui n'existent pas. Le run a été écarté mais conservé dans les données brutes, et les passages retenus interrogent 1.1.1.1 et 9.9.9.9 directement, l'un après l'autre.

Refaire la mesure sur votre domaine

La séquence complète, dans l'ordre où je l'ai déroulée. Le premier bloc est celui qu'on saute et qui coûte le plus cher quand on le saute.

D=exemple.fr   # votre domaine

# 1. Le resolveur repond-il ? Les deux lignes doivent renvoyer la meme adresse.
dig +short A $D
dig @1.1.1.1 +short A $D

# 2. Toutes les permutations, resolveurs publics explicites, puis repartition.
dnstwist --nameservers 1.1.1.1,9.9.9.9 -t 8 --format json $D > all.json
jq -r '.[] | select(.fuzzer!="*original") | .fuzzer' all.json | sort | uniq -c | sort -rn

# 3. Seulement ce qui repond, avec la date de creation.
dnstwist --nameservers 1.1.1.1,9.9.9.9 -t 8 --registered --whois --format json $D > registered.json
jq -r '.[] | [.domain, .fuzzer, (.dns_a // [] | join(",")), .whois_created // "-"] | @tsv' registered.json

# 4. Changement d'extension : une extension par ligne dans tld.txt.
dnstwist --nameservers 1.1.1.1,9.9.9.9 -t 4 --registered --whois --tld tld.txt --format json $D

# 5. Chaque "hit" se reverifie a la main, sur un autre resolveur.
dig @9.9.9.9 NS candidat.tld
dig @9.9.9.9 MX candidat.tld

Trois règles de lecture évitent l'essentiel des erreurs. Tout rapport dont la ligne *original n'affiche pas votre vraie adresse est à jeter. Une date WHOIS antérieure à votre propre dépôt signale presque toujours un domaine parent légitime, pas un squatteur. Et un MX sur un nom qui imite le vôtre reste le signal le plus parlant, parce qu'il n'a aucune raison d'exister hors d'une intention de recevoir du courrier sur ce nom. Pour la liste tld.txt, partez des extensions de vos marchés, des génériques et des extensions bon marché que les campagnes de phishing affectionnent.

Les certificats, l'autre capteur, et son retard

Un clone servi en HTTPS a besoin d'un certificat, et chaque certificat public est inscrit dans les journaux de Certificate Transparency. On les interroge souvent via crt.sh, et la méthode est détaillée dans Certificate Transparency et shadow IT. Même jour, même domaine, une mesure invite à la prudence : sur les sept certificats que servaient les hôtes de own2pwn.fr, les six émis les 13 et 14 septembre n'apparaissaient pas encore dans la réponse JSON de crt.sh le 22, seul le septième, émis le 7 août, y figurait. Une veille qui ne lit que cet index a donc pu avoir plus d'une semaine de retard ce jour-là. Les journaux eux-mêmes ne sont pas en cause, c'est l'index gratuit qui les agrège ; une surveillance sérieuse lit les journaux directement ou passe par plusieurs sources.

Les recours quand un sosie devient hostile

Détecter un domaine ne dit pas encore quoi en faire. Enregistrer un nom proche d'une marque n'est pas interdit en soi : tout repose sur la mauvaise foi et l'usage. Le droit français saisit le typosquatting à travers la contrefaçon de marque (articles L.713-2 et suivants du code de la propriété intellectuelle), la concurrence déloyale et le parasitisme (article 1240 du code civil), et, quand le nom sert à tromper, l'escroquerie et l'usurpation d'identité (articles 313-1 et 226-4-1 du code pénal).

Les trois conditions de l'UDRP sont un nom identique ou similaire au point de prêter à confusion, l'absence de droit ou d'intérêt légitime du titulaire, et un enregistrement et un usage de mauvaise foi. Un domaine qui ne fait que résoudre, sans contenu établi, remplit rarement la troisième : c'est une raison de plus pour documenter son évolution dans le temps plutôt que d'agir sur une simple ressemblance. Pour un .fr, la procédure SYRELI de l'AFNIC est l'équivalent national, plus rapide et moins cher. En pratique, on combine les voies : signalement immédiat pour couper une campagne, procédure extrajudiciaire pour récupérer le nom, tribunal si l'enjeu le justifie.

Au-delà des domaines

Le même pari sur la faute de frappe vise les registres de paquets : un nom proche d'une bibliothèque populaire sur npm ou PyPI, et un pip install mal tapé exécute du code arbitraire dans votre CI. C'est une porte d'entrée de l'attaque sur la chaîne d'approvisionnement logicielle, et elle se défend par le verrouillage des dépendances plutôt que par une veille DNS.

Pour les domaines, la mesure ci-dessus a une limite évidente : c'est une photo. Elle dit qu'au 22 septembre 2026 aucun sosie en .fr de own2pwn.fr n'était déposé, pas qu'il n'en existera pas demain. Un domaine peut être déposé, équipé d'un certificat et d'un MX, utilisé puis abandonné entre deux photos. Comme le subdomain takeover, c'est un risque de surface externe, qui se traite par une surveillance continue : c'est le principe de l'EASM, la gestion de la surface d'attaque externe, qui rejoue ces permutations à chaque scan et ne remonte que les variantes effectivement enregistrées et qui résolvent, avec l'adresse vers laquelle elles pointent.

• Contrôler le résolveur avant tout : si *original revient en !ServFail, le rapport entier est faux.
• Lire les dates WHOIS : sur own2pwn.fr, les deux seules réponses en .fr étaient des domaines parents antérieurs, pas des squats.
• Surveiller l'évolution, pas l'existence : un sosie qui gagne un MX, un SPF ou un certificat mérite une action, un sosie inerte mérite un suivi.

Si vous voulez que ce suivi tourne sans y penser, c'est le rôle de notre plateforme de surveillance de la surface d'attaque externe. Et pour faire le point à la main sur un cas précis, la page contact mène directement à un pentester.

Questions fréquentes