Subdomain takeover : comment ça arrive et comment le repérer

Un subdomain takeover commence par un CNAME pointant vers un service résilié. Comment les records orphelins sont exploités et comment auditer sa zone.

Un subdomain takeover se produit quand un record DNS, le plus souvent un CNAME, pointe vers une ressource externe qui n'existe plus, et qu'un tiers recrée cette ressource sous le même nom. À partir de là, votre sous-domaine sert un contenu que vous ne contrôlez pas. L'attaquant obtient une page hébergée sous votre domaine, avec votre réputation en caution : phishing crédible, distribution de malware, et selon la configuration un accès aux cookies posés sur le domaine parent. Le DNS lui-même n'a jamais été compromis. Il a continué à dire la vérité sur une cible que vous avez oublié de nettoyer. Cet article détaille le mécanisme, les services concernés, la méthode d'auto-audit et la prévention.

Le mécanisme : le record orphelin

La vulnérabilité suit un cycle de vie que tout gestionnaire de site connaît :

Vous créez blog.exemple.com en CNAME vers un service hébergé, par exemple votresociete.une-plateforme.com.
Le service tourne pendant des mois ou des années. Tout fonctionne.
Vous résiliez l'abonnement ou supprimez le projet. La plateforme libère le nom votresociete.
Personne ne supprime le CNAME. Il pointe désormais vers une ressource qui n'existe plus : c'est un record orphelin, un « dangling record ».

Voici l'avant et l'après :

Avant (service actif) :
blog.exemple.com.  CNAME  votresociete.une-plateforme.com.
                          -> la plateforme sert VOTRE contenu

Après résiliation (record orphelin) :
blog.exemple.com.  CNAME  votresociete.une-plateforme.com.
                          -> le nom est libre sur la plateforme

La résolution DNS continue de fonctionner. Le record est valide et l'infrastructure de la plateforme répond toujours. La seule chose qui manque, c'est la ressource derrière le nom. Si la plateforme laisse n'importe quel client enregistrer ce nom libéré, celui qui le réclame reçoit tout le trafic envoyé vers blog.exemple.com. Les visiteurs voient votre URL dans la barre d'adresse et une page qui répond derrière. C'est ce qui rend l'attaque redoutable pour le phishing : rien ne semble anormal.

Le CNAME est le vecteur le plus courant parce qu'il délègue un hostname entier à un tiers, mais un record A pointant vers une IP cloud restituée pose exactement le même problème. Pour revoir le comportement de ces types de records, consultez notre guide des types de records DNS.

Les services typiquement concernés

Toute plateforme qui associe des noms choisis par le client à des hostnames peut être touchée. Quand la ressource derrière un record orphelin a disparu, la plateforme renvoie en général une erreur reconnaissable. Ce sont ces signaux qu'un défenseur cherche pendant un audit :

Service	Signal d'une ressource orpheline
GitHub Pages	« There isn't a GitHub Pages site here »
AWS S3	Page d'erreur « NoSuchBucket »
Heroku	Page d'erreur « No such app »
Azure (cloudapp, azurewebsites)	NXDOMAIN ou page d'erreur Azure par défaut
Shopify	« Sorry, this shop is currently unavailable »
Vercel	404 avec « DEPLOYMENT_NOT_FOUND »

Beaucoup de fournisseurs ont resserré la vis ces dernières années. GitHub Pages et d'autres exigent maintenant une vérification de propriété du domaine avant d'attacher un domaine personnalisé, ce qui ferme la voie facile. Mais la fenêtre s'est réduite sans disparaître : des plateformes plus anciennes, des hébergeurs régionaux et des services sans vérification restent réclamables, et la vérification ne vous protège pas si votre record orphelin pointe vers un service qui ne l'a jamais mise en place.

Auditer son propre domaine

Pas besoin d'outillage spécialisé pour une première passe. Trois temps :

Exportez votre zone DNS depuis votre fournisseur (Cloudflare, Route 53, OVH, votre registrar) et listez chaque CNAME et chaque record A qui pointe hors de votre propre infrastructure.
Pour chacun, vérifiez que la ressource cible répond encore et vous appartient toujours. Ouvrez le hostname dans un navigateur et confirmez que le contenu est le vôtre, pas une page d'erreur de plateforme.
Supprimez tout record dont le service cible a été résilié, migré, ou que personne ne sait identifier.

Pour inspecter un record en ligne de commande :

dig CNAME boutique.exemple.com +short

Si la réponse pointe vers une plateforme SaaS, chargez la page et lisez la réponse. Une erreur de plateforme comme celles du tableau ci-dessus, sur un hostname que vous publiez toujours en DNS, est exactement le signal qu'un opportuniste recherche. Traitez-le en urgence : supprimez le record ou récupérez la ressource le jour même.

Prévenir durablement

Le vrai correctif est procédural, pas technique. Quand vous résiliez un service, supprimez le record DNS dans le même ticket, la même pull request ou la même fenêtre de changement. Un décommissionnement n'est terminé que quand les deux côtés ont disparu. La plupart des takeovers remontent à une résiliation qui a sauté cette étape des années plus tôt.

Au-delà de cette habitude, maintenez un inventaire vivant de chaque sous-domaine pointant vers un service externe, avec son propriétaire interne, et passez cette liste en revue à intervalle fixe. Un rythme trimestriel convient à la plupart des équipes. Notre article sur ce que couvre la surveillance DNS explique où les contrôles au niveau des records s'insèrent dans cette routine.

Si vous utilisez Domain Sentinel, le champ Extra names de la surveillance DNS permet d'ajouter jusqu'à dix sous-domaines critiques par domaine, chacun surveillé comme un hostname à part entière. Leurs records CNAME et A sont capturés chaque jour, et tout changement déclenche une alerte email. Dix, c'est peu : retenez les sous-domaines qui pointent vers un service externe. Cela garde votre inventaire honnête : un record qui change ou apparaît sans ticket correspondant se remarque. Soyons clairs sur les limites : l'outil enregistre ce que votre DNS répond, il ne teste pas si la ressource cible existe encore côté plateforme. La défense, c'est la suppression des records obsolètes ; la surveillance est le filet qui vous prévient quand la zone dérive.

Commencez aujourd'hui par l'export : récupérez votre fichier de zone, listez les records pointant vers des services externes, vérifiez chacun, supprimez les morts. La plupart des zones de plus de quelques années réservent au moins une surprise. Et comme le record orphelin n'est qu'une des façons dont un sous-domaine finit par servir le contenu de quelqu'un d'autre, lisez notre article sur la détection du DNS hijacking pour l'attaque cousine, celle où la zone elle-même est modifiée.