Attaques par homographes et typosquatting expliquées

Une grande partie des attaques de phishing réussies se résume à une seule chose : une victime qui fait confiance à un domaine qui n'est pas ce qu'il paraît. Les attaques par homographes et le typosquatting sont les deux techniques principales pour détourner cette confiance.

Le typosquatting

Le typosquatting consiste à enregistrer des domaines qui ne sont qu'à une faute de frappe d'un domaine légitime, puis à miser sur l'erreur humaine et les automatismes.

Variantes courantes de example.com :

• Omission : exaple.com, exmple.com
• Transposition : examlpe.com, exapmle.com
• Répétition / touche voisine : exampple.com, examole.com
• Mauvaise extension : example.co, example.cm, example.org
• Combosquatting : ajout de mots plausibles — example-login.com, example-support.com, secure-example.com

Le combosquatting est particulièrement efficace car la vraie marque est présente : un coup d'œil rapide la lit comme légitime.

Les attaques par homographes (homoglyphes)

Les attaques par homographes exploitent des caractères qui semblent identiques mais dont l'encodage diffère. Unicode contient de nombreux glyphes rendus presque comme des lettres ASCII.

• Cyrillique : а е о р с х ressemblent aux latins a e o p c x.
• Grec : ο (omicron) contre le o latin.
• Sosies latins : le chiffre 0 contre la lettre O, 1 contre l contre I, rn rendu comme m.

Un nom de domaine internationalisé (IDN) utilisant le а cyrillique dans аpple.com est un domaine totalement différent de apple.com, tout en étant visuellement indiscernable dans de nombreuses polices.

Le Punycode : la défense cachée à la vue de tous

Les navigateurs encodent les IDN en ASCII via le Punycode (préfixe xn--). La version « a cyrillique » de apple.com devient :

xn--pple-43d.com

Les navigateurs modernes appliquent des règles de mélange d'écritures et affichent souvent le Punycode brut plutôt que l'Unicode « joli » quand un label mêle plusieurs écritures — un avertissement visuel clé. Mais les clients de messagerie, les sorties de terminal et certains outils ne le font pas : c'est là que ces attaques réussissent.

Où elles apparaissent au-delà de la barre d'adresse

• Domaines expéditeurs d'email — paypa1.com dans un en-tête From.
• Texte du lien contre href — le texte affiche bank.com, l'ancre pointe ailleurs.
• Redirections OAuth et SSO — un hôte d'écran de consentement ressemblant.
• Registres de paquets — paquets npm/PyPI typosquattés (crossenv contre cross-env) pour des attaques sur la chaîne d'approvisionnement.
• QR codes — la destination reste invisible tant qu'on ne l'a pas scannée.

Détection et défense

Pour votre propre marque (proactif) :

• Enregistrez les permutations les plus risquées et les extensions courantes, et faites-les rediriger vers votre site réel.
• Surveillez les journaux de Certificate Transparency pour repérer les certificats émis sur des domaines ressemblants.
• Utilisez une surveillance de domaines ou des flux de menaces DNS qui signalent les enregistrements proches de votre marque.

Pour la protection entrante :

• Imposez DMARC (p=reject), SPF et DKIM pour que les usurpations de votre domaine soient rejetées.
• Déployez une détection qui calcule la distance d'édition et le mélange d'écritures par rapport aux marques connues.
• Bloquez les domaines récemment enregistrés (NRD) au niveau du proxy pendant une période tampon.

Une vérification manuelle rapide — normalisez un label suspect en Punycode :

# Python : révéler la vraie forme ASCII d'un label d'hôte
python3 -c "print('раypal'.encode('idna'))"
# b'xn--pypal-4ve1c'  ->  ce n'est pas 'paypal'

Pour les utilisateurs :

• Survolez pour révéler le vrai href ; sur mobile, appui long.
• Saisissez les URL connues ou utilisez des favoris plutôt que de cliquer sur les liens des messages.
• Privilégiez une MFA résistante au phishing : même si l'utilisateur atteint un clone de connexion par homographe, FIDO2/WebAuthn lie l'identifiant à l'origine réelle et refusera de s'authentifier auprès du domaine imposteur.

Ce dernier point est le plus important : des identifiants liés à l'origine transforment un sosie convaincant en impasse, car c'est le navigateur — et non l'humain — qui vérifie le domaine.

Comment GottaPhish aide

Les domaines par homographes et combosquattés font qu'un lien malveillant semble correct : aucune lecture attentive ne les repère de façon fiable. GottaPhish et son équipe d'experts vous aident à traiter précisément ce risque : des simulations construites autour de ces techniques mêmes, et des tableaux de bord mettant en évidence qui clique sur les domaines ressemblants et qui les signale. Nos experts vous accompagnent dans la configuration, conçoivent des scénarios utilisant des domaines expéditeurs sosies réalistes, vous aident à interpréter les résultats et accompagnent le déploiement d'une MFA résistante au phishing pour que la liaison à l'origine — et non la seule vigilance humaine — devienne votre garde-fou face aux fausses pages de connexion.