Prise de contrôle de sous-domaine : détecter et corriger les enregistrements DNS orphelins

Qu’est-ce qu’une prise de contrôle de sous-domaine ?

Un sous-domaine désigne souvent une ressource que l’organisation n’administre pas elle-même : application hébergée dans le cloud, plateforme marketing, outil de support. Le lien entre votre nom et cette ressource tient à un enregistrement DNS.

La prise de contrôle de sous-domaine (subdomain takeover) exploite la rupture de ce lien. La ressource disparaît, l’enregistrement reste. Un tiers recrée alors une ressource sous le même identifiant chez le même fournisseur, et le trafic destiné à votre sous-domaine arrive chez lui.

Le guide de test de l’OWASP, à la fiche WSTG-CONF-10, résume les deux conditions nécessaires : l’enregistrement DNS de la victime pointe vers une ressource inexistante ou inactive, et le fournisseur qui l’héberge ne vérifie pas correctement la propriété du sous-domaine. La première est de votre ressort ; la seconde dépend du fournisseur, ce qui explique qu’un même oubli soit exploitable chez l’un et inoffensif chez l’autre.

Le scénario de référence

La documentation Azure de Microsoft décrit le cas d’école. Un CNAME relie un sous-domaine de l’entreprise au nom d’une application web hébergée chez le fournisseur. L’application est supprimée, le CNAME reste : l’enregistrement est dit « pendant » (dangling DNS). Un attaquant repère le sous-domaine, crée dans son propre abonnement une ressource portant le nom libéré et sert le contenu de son choix sous le nom de l’entreprise.

Aucune vulnérabilité logicielle n’est en jeu. AWS le précise dans son analyse de cette tactique : la prise de contrôle n’exploite pas une faille des services cloud, mais un écart entre ce que la zone DNS annonce et ce que l’organisation détient réellement. C’est un problème d’inventaire.

Comment naissent les enregistrements orphelins ?

Un enregistrement devient orphelin quand le cycle de vie de la ressource et celui de l’enregistrement se désynchronisent. Dans nos missions de cartographie externe, nous retrouvons les mêmes origines d’une organisation à l’autre.

• Les projets terminés. Une préproduction, une démonstration pour un salon, un prototype : la ressource cloud est supprimée pour arrêter la facturation, mais l’équipe qui gère la zone DNS n’est pas prévenue.
• Les campagnes marketing. Un jeu-concours ou une page d’événement est publié sur une plateforme tierce sous un sous-domaine dédié. La campagne se termine, l’abonnement est résilié, le sous-domaine continue de pointer vers la plateforme.
• Les services SaaS résiliés. Centre d’aide, page de statut, outil de recrutement, boutique : chaque service personnalisé avec votre nom laisse un CNAME derrière lui quand le contrat s’arrête.
• Les délégations oubliées. Une filiale, un prestataire ou une équipe a reçu la gestion d’un sous-domaine par une délégation NS vers ses propres serveurs de noms. La zone déléguée disparaît, la délégation reste dans la zone parente.
• Les rapprochements d’entreprises. Une acquisition apporte des noms de domaine, des zones et des comptes cloud dont personne ne connaît plus l’historique.

Le point commun est organisationnel : la personne qui supprime la ressource n’est pas celle qui administre la zone, et aucune étape du décommissionnement ne relie les deux.

Trois familles d’enregistrements à surveiller

Le CNAME vers une ressource nommée librement. Microsoft le juge particulièrement exposé. Il devient dangereux quand le nom de la ressource cible est choisi par le client dans un espace de noms partagé par tous les clients du fournisseur. AWS cite les compartiments S3 et les environnements Elastic Beanstalk, dont les noms sont uniques au niveau mondial et peuvent être repris par n’importe quel compte une fois libérés. À l’inverse, les noms de distribution CloudFront sont attribués par AWS et ne peuvent pas être choisis par un attaquant. Microsoft dresse une liste comparable pour Azure (App Service, stockage Blob, Front Door, Traffic Manager…).

La délégation NS vers une zone qui n’existe plus. L’OWASP la décrit comme le cas le moins probable mais celui dont l’impact est le plus élevé : celui qui reprend la zone déléguée contrôle tous les noms qu’elle contient, et pas seulement un enregistrement. Le guide de test donne l’exemple d’un serveur de noms dont le propre nom de domaine a expiré et peut être racheté. Le guide Route 53 d’AWS détaille cinq scénarios de délégation pendante ; le service bloque le premier (zone supprimée puis recréée sous le même nom), pas les quatre autres.

L’enregistrement A vers une adresse IP cloud libérée. L’adresse publique rendue au fournisseur peut être réattribuée à un autre client. Le risque existe, mais il est moins direct : une étude présentée à NSDI 2024 observe que les attaquants privilégient les ressources dont le nom se choisit librement, moins coûteuses à détourner que des adresses IP tirées au hasard dans un grand ensemble. Il peut rester longtemps inoffensif, puis servir sans préavis le contenu d’un inconnu.

Les enregistrements MX méritent la même attention : Microsoft rappelle qu’un MX orphelin peut permettre à un tiers de recevoir des courriels adressés à un sous-domaine de l’organisation.

Que fait un attaquant d’un sous-domaine repris ?

Un hameçonnage qui passe tous les contrôles visuels

La page piégée s’affiche sous votre vrai nom de domaine. Contrairement à une idée répandue, relève Microsoft, le certificat TLS ne protège pas : l’attaquant qui contrôle le sous-domaine peut obtenir un certificat valide. La victime voit votre domaine et un cadenas. C’est ce qui distingue ce risque du typosquatting, où l’attaquant doit se contenter d’un domaine proche du vôtre.

Des cookies lus depuis le domaine parent

La norme des cookies, la RFC 6265, prévoit qu’un cookie posé avec l’attribut Domain=example.com est envoyé à example.com, à www.example.com et à www.corp.example.com. Si votre application place ses cookies de session au niveau du domaine parent, chaque sous-domaine les reçoit, y compris celui que l’attaquant vient de reprendre. Microsoft précise que les cookies marqués Secure sont concernés, puisque l’attaquant dispose d’un certificat valide. La même RFC signale le problème inverse : un sous-domaine peut poser un cookie valable pour le domaine parent.

Le contournement des politiques de confiance

Beaucoup de politiques de sécurité font confiance à « tout ce qui finit par votre domaine » : une politique de sécurité du contenu (CSP) qui autorise les scripts de *.example.com, une configuration CORS qui accepte les origines de vos sous-domaines, une liste d’adresses de redirection OAuth trop large. Un sous-domaine repris hérite de cette confiance. MDN cite le contournement des CSP et le cross-site scripting ; Microsoft ajoute le contournement de CORS et la falsification de requête intersite (CSRF). Tout secret que votre application envoie encore vers ce sous-domaine, un identifiant OAuth par exemple, peut être exposé, rappelle Microsoft.

Des abus moins visibles

Tous les détournements ne visent pas vos utilisateurs. L’étude de NSDI 2024, qui a recensé 20 904 ressources détournées sur des plateformes cloud courantes, indique que 75 % des abus observés relèvent du référencement frauduleux : des pages profitent de la réputation de votre nom auprès des moteurs de recherche. Un tiers des détournements y dure plus de 65 jours, souvent sans que personne ne le remarque, jusqu’à ce qu’un éditeur de sécurité classe le sous-domaine comme malveillant.

Comment détecter les sous-domaines orphelins ?

Partir de vos zones, pas d’Internet

La source de référence est l’export de vos zones DNS, chez tous vos hébergeurs, filiales comprises. Il s’agit d’extraire les CNAME, NS, A, AAAA et MX qui pointent hors de votre infrastructure, puis de rattacher chacun à un fournisseur et à un propriétaire interne.

Compléter par les journaux de transparence des certificats

Les journaux de Certificate Transparency, définis par la RFC 6962 puis par la RFC 9162 qui la remplace, consignent publiquement les certificats TLS émis. Ils révèlent des sous-domaines que l’inventaire a oubliés, puisque chaque certificat liste les noms qu’il couvre. Et la RFC 9162 prévoit que les responsables d’un domaine surveillent les journaux pour repérer un certificat inattendu : l’attaquant qui reprend un sous-domaine et demande un certificat laisse cette trace. C’est aussi par ces journaux qu’un attaquant découvre vos sous-domaines, comme nous le décrivons dans notre article sur la reconnaissance OSINT.

Lire les réponses DNS et HTTP

La fiche WSTG-CONF-10 indique les signaux à rechercher : NXDOMAIN sur la cible d’un CNAME ou d’un A, SERVFAIL ou REFUSED sur une délégation NS. Côté HTTP, la page d’erreur caractéristique d’un fournisseur signale souvent une ressource libérée.

Comparer avec ce que vous détenez réellement

Ces signaux ont une limite décisive, que souligne AWS : si l’attaquant a déjà repris la ressource, la résolution réussit, vers sa ressource et non vers la vôtre. Les cas les plus graves échappent donc à un contrôle qui vérifie seulement que le nom répond. La détection fiable vérifie que chaque cible existe dans vos comptes : Microsoft recommande de tenir un catalogue de vos points de terminaison cloud et de leurs propriétaires ; AWS publie une règle qui confronte chaque CNAME à l’inventaire du compte. C’est le terrain du rapprochement d’inventaires, celui de la CAASM, appliqué à la surface d’attaque externe.

Tableau de diagnostic

Corriger durablement

Supprimer les orphelins trouvés règle le stock ; sans changement de procédure, le prochain projet terminé en recrée d’autres.

1. Inverser l’ordre de décommissionnement. AWS en fait un principe : supprimer d’abord l’enregistrement DNS, attendre l’expiration de sa durée de vie en cache (TTL), puis seulement supprimer la ressource, et vérifier enfin que le nom ne résout plus. MDN formule la règle symétrique pour la création : réserver d’abord la ressource chez le fournisseur, créer l’enregistrement DNS en dernier.
2. Lier l’enregistrement à la ressource quand c’est possible. Microsoft cite les enregistrements alias d’Azure DNS, qui deviennent vides quand la ressource liée est supprimée, et les verrous de suppression sur les ressources portant un nom personnalisé.
3. Activer la vérification de propriété. Chez Azure App Service, un enregistrement TXT asuid portant l’identifiant de vérification empêche un autre abonnement de valider votre domaine personnalisé. Demandez à chaque fournisseur SaaS comment il vérifie qu’un client a le droit d’utiliser un nom : MDN recommande d’en faire un critère de choix des fournisseurs.
4. Donner un propriétaire à chaque enregistrement. Chaque nom publié se rattache à une application et à un responsable ; un enregistrement sans propriétaire est un candidat à la suppression.
5. Encadrer les délégations. Ne déléguer un sous-domaine qu’à une zone que vous contrôlez et qui existe déjà, en respectant la hiérarchie : AWS recommande de déléguer chaque sous-domaine depuis sa zone parente immédiate et de vérifier que les NS de la zone parente correspondent bien aux serveurs de la zone déléguée.
6. Intégrer le DNS aux fins de contrat et revoir la zone régulièrement. Résiliation d’un SaaS, fin de campagne ou cession d’activité déclenchent une revue des enregistrements concernés ; la zone se rapproche de l’inventaire au rythme de vos changements cloud.
7. Traiter chaque découverte comme un incident possible. Microsoft demande, pour chaque enregistrement orphelin trouvé, de vérifier si une compromission a eu lieu, puis de comprendre pourquoi l’enregistrement n’a pas été retiré au décommissionnement.

Exemple type

Exemple type. Une entreprise de distribution de taille intermédiaire lance une revue de sa zone DNS principale après le rachat d’une filiale. L’équipe isole les enregistrements qui pointent vers des fournisseurs externes.

Trois cas ressortent. Un CNAME jeu-ete pointe vers une plateforme de campagnes dont l’abonnement a été résilié deux ans plus tôt ; la plateforme affiche une page « domaine non configuré ». Un CNAME preprod-catalogue vise un compartiment de stockage cloud qui n’existe plus dans aucun compte de l’entreprise. Une délégation NS confie extranet aux serveurs de noms de l’ancien prestataire de la filiale, qui ne répondent plus.

La délégation est traitée en premier, parce qu’elle ouvrirait toute une zone. Les deux CNAME sont supprimés le jour même. La consultation des journaux de transparence des certificats ne montre aucun certificat émis pour ces noms depuis la fin des services, ce qui plaide contre un détournement passé sans le prouver. L’équipe ajoute enfin une étape « retrait DNS » à la procédure de résiliation des contrats SaaS et à celle de suppression des ressources cloud.

Ce scénario est construit à partir de situations courantes en mission, pas à partir d’un client identifiable.

Limites de l’approche

La détection dépend de l’exhaustivité de l’inventaire. Une zone hébergée chez un prestataire oublié ou un domaine enregistré hors de tout processus échappe à la revue. La découverte externe comble une partie de cet angle mort sans le fermer.

La comparaison avec les ressources détenues suppose un accès à tous les comptes cloud. Microsoft demande de documenter les abonnements que l’inventaire couvre quand il ne les couvre pas tous : un compte cloud ouvert hors du périmètre de la DSI reste invisible.

L’exploitabilité varie selon les fournisseurs et dans le temps. Certains ont ajouté des vérifications de propriété ou des espaces de noms propres à chaque compte : AWS indique par exemple que les compartiments S3 créés dans un espace de noms régional propre au compte ne sont pas exposés à cette tactique. Un orphelin inoffensif aujourd’hui peut redevenir exploitable si le fournisseur change ses règles. Supprimer l’enregistrement reste la seule correction qui ne dépend pas d’un tiers.

Enfin, confirmer qu’une prise de contrôle est possible suppose en principe de créer la ressource chez le fournisseur, comme le décrit l’OWASP : un test intrusif, à mener dans un cadre autorisé, par exemple un test d’intrusion externe, et jamais sur des actifs dont la propriété n’est pas établie.