Le détournement de sous-domaine, expliqué — et comment le détecter | Scanthra

Scanthra · 7 min de lecture · Mis à jour Mai 2026

Le mécanisme, en un paragraphe

Il y a trois ans, quelqu'un dans ton équipe a créé evenements.tonentreprise.com comme CNAME pointant vers ton-evenement.herokuapp.com. La campagne marketing s'est terminée, l'application Heroku a été supprimée, le CNAME dans le DNS a été oublié. Aujourd'hui, n'importe qui peut s'inscrire sur Heroku, revendiquer le nom ton-evenement.herokuapp.com, et servir le HTML qu'il veut. Les navigateurs qui visitent evenements.tonentreprise.com reçoivent leur page, avec ton domaine dans la barre d'adresse, avec la confiance de ta marque. TLS/SSL (chiffrement) fonctionne parce que des services comme Heroku émettent des certificats automatiquement. Du point de vue du navigateur, c'est une visite parfaitement légitime sur ton vrai site.

Pourquoi c'est important

Des attaques réelles observées dans la nature :

• Phishing. « Connecte-toi à ta-banque.exemple.com » arrive sur la page de l'attaquant avec un parfait cadenas TLS.
• Vol de cookies. Si ton domaine parent place des cookies sur .exemple.com, le sous-domaine détourné peut les lire simplement en vivant sous le même parent.
• Empoisonnement SEO. Les attaquants redirigent depuis ton sous-domaine vers des hôtes de fraude publicitaire ou de malware. Google met parfois en liste noire l'ensemble de exemple.com en conséquence.
• Atteinte à la marque. Une histoire du type « Le sous-domaine propre d'Acme Corp sert des pages d'arnaques crypto » est difficile à nettoyer.

Les services vulnérables

Le détournement de sous-domaine est une classe de vulnérabilité contre tout SaaS qui : (1) permet aux utilisateurs de revendiquer un sous-domaine arbitraire sur la plateforme, et (2) ne vérifie pas que le demandeur possède aussi le domaine d'origine. Parmi les plateformes historiquement vulnérables :

• Heroku, buckets AWS S3 (hébergement de site statique), Azure Cloud Apps / Traffic Manager / CDN, GitHub Pages, GitLab Pages, Shopify, Squarespace, Tumblr, Webflow, Netlify, Vercel, Fastly, Pantheon, Zendesk, Statuspage, SendGrid, Mailgun, Tilda, Strikingly, Surge.sh, Ghost.io, Cargo, Read the Docs.

L'indicateur de détournement de chaque plateforme est légèrement différent — la plupart affichent une empreinte caractéristique « no such app » / « bucket does not exist » / « 404 Not Found » quand le nom n'est pas revendiqué. Le dépôt EdOverflow/can-i-take-over-xyz sur GitHub, maintenu par la communauté, garde la liste à jour.

Comment détecter toi-même les enregistrements suspendus

Étape 1 — Énumérer tes sous-domaines

Tu ne peux pas corriger ce que tu ne connais pas. Sources pour un inventaire complet :

• Le fichier de zone de ton fournisseur DNS — exporte chaque enregistrement A, AAAA et CNAME.
• Les logs de transparence des certificats via crt.sh — chaque certificat TLS jamais émis pour ton domaine est public.
• Les scans passés, les entrées dans le gestionnaire de mots de passe, les wikis internes — partout où quelqu'un a pu ajouter un sous-domaine que personne n'a supprimé.

Étape 2 — Résoudre chacun

Pour chaque enregistrement :

• Si c'est un A/AAAA pointant vers une adresse IP que tu ne possèdes plus — supprime.
• Si c'est un CNAME pointant vers un service tiers, récupère l'URL et regarde la réponse. « No such app », « There isn't a GitHub Pages site here », « NoSuchBucket » ou « Repository not found » sont des signes de détournement possible.
• Si dig +short cname.sous-domaine renvoie un NXDOMAIN pour la cible — c'est un fort signal de détournement.

Étape 3 — Supprimer ou récupérer

Si tu n'as plus besoin du sous-domaine, supprime l'enregistrement DNS. Si tu en as encore besoin, pointe-le vers un asset actuel. Évite de pointer vers des applications cloud « de substitution » — elles tendent à dériver vers un état vulnérable.

Comment prévenir le suivant

• Propriétaire DNS par enregistrement. Chaque enregistrement de sous-domaine dans ta zone doit avoir un propriétaire documenté dans les notes de ton fournisseur DNS ou dans un tableur interne.
• Check-list de déprovisionnement. « Clôturer le site de campagne » doit inclure « supprimer le CNAME DNS pointant vers l'hébergeur de la campagne ».
• Audit DNS trimestriel. 30 minutes par trimestre évitent un incident qui nuit à la marque.
• Wildcards avec précaution. Un CNAME générique *.exemple.com vers un service tiers est une invitation permanente au détournement pour tout nom non revendiqué.

Comment Scanthra détecte ça

Notre module DNS Recon interroge les logs publics de transparence des certificats (de façon passive, sans brute-force DNS) et signale chaque sous-domaine qui a déjà eu un vrai certificat. On met en évidence les sous-domaines de développement, de staging et à apparence d'administration comme problèmes détectés — les candidats classiques pour des enregistrements oubliés et suspendus. La détection de détournement de sous-domaine elle-même (vérifier si chaque cible CNAME est non revendiquée sur un fournisseur vulnérable connu) est sur notre feuille de route et bénéficiera en premier aux utilisateurs payants.