Subdomain takeover : comment un sous-domaine oublié devient une
porte d'entrée

En 2021, le service marketing crée promo-noel.votreboite.fr pour une landing page éphémère, hébergée chez un SaaS. La campagne se termine, on supprime la page chez le prestataire, on passe à autre chose. Personne ne touche au DNS. Trois ans plus tard, l'enregistrement CNAME est toujours là, à pointer vers une ressource qui n'existe plus. Ce sous-domaine, plus personne ne le regarde, sauf quelqu'un qui scanne votre périmètre et qui, lui, vient de comprendre qu'il peut le réclamer.

C'est le subdomain takeover (prise de contrôle de sous-domaine) : une des vulnérabilités les plus sous-estimées du web, parce qu'elle ne vient pas d'une ligne de code mais d'un enregistrement DNS qu'on a oublié de nettoyer. Elle est triviale à repérer quand on sait où regarder, et pourtant elle traîne sur des milliers de domaines de grandes marques. On va voir exactement comment elle marche, comment la détecter, ce qu'un attaquant en fait vraiment (bien au-delà du défacement) et pourquoi le scan annuel ne suffira jamais à s'en débarrasser.

Le sous-domaine fantôme : anatomie d'un angle mort

Une organisation ne gère pas un domaine, elle gère une surface qui grossit toute seule. Chaque campagne, chaque POC, chaque environnement de staging, chaque outil SaaS branché par une équipe pressée ajoute un sous-domaine. Et chaque décommissionnement laisse potentiellement derrière lui un enregistrement DNS orphelin, un dangling DNS record : une entrée (le plus souvent un CNAME) qui pointe vers une ressource externe désormais supprimée.

Le problème n'est pas la difficulté technique. Repérer un sous-domaine réclamable prend quelques commandes. Le problème est qu'il faut d'abord savoir que le sous-domaine existe, et c'est précisément là que le bât blesse : ces actifs naissent en dehors du radar de la sécurité, exactement comme le shadow IT dont ils sont souvent un sous-produit. Trivial à détecter en théorie, structurellement dur à éliminer en pratique.

Qu'est-ce qu'un subdomain takeover, exactement ?

L'OWASP en donne une définition stricte (test WSTG-CONF-10) reposant sur deux conditions cumulatives :

• Un enregistrement DNS pointe dans le vide : le record du sous-domaine vise une ressource ou un service tiers qui n'existe plus, ou n'est plus actif.
• Le fournisseur ne vérifie pas la propriété du domaine : il laisse n'importe qui rattacher ce nom à une nouvelle ressource, sans prouver qu'on est bien le légitime propriétaire.

La seconde condition est celle qu'on oublie, et c'est elle qui fait toute la différence. Un CNAME orphelin vers un provider qui exige une preuve de propriété reste un défaut d'hygiène, mais il est inerte : personne ne peut le revendiquer. Le takeover n'existe que quand les deux conditions sont réunies.

La chaîne du CNAME orphelin

L'exemple canonique de l'OWASP tient en quatre temps :www.victim.com pointe en CNAME vers victimotherdomain.com. Ce dernier expire et redevient enregistrable. Le CNAME, lui, n'est jamais retiré de la zone de victim.com. Résultat : « anyone who registers victimotherdomain.com has full control over www.victim.com », jusqu'à ce que le record soit corrigé.

Le cycle de vie en trois temps

Microsoft décrit bien la mécanique sur Azure, en trois phases qu'on retrouve chez tous les hébergeurs. La voici de bout en bout :

Création. Vous branchez app.votreboite.fr en CNAME vers app-x7.azurewebsites.net, tout route normalement. Déprovisionnement. Vous supprimez l'app Azure, mais le CNAME subsiste : il annonce un domaine actif qui ne route plus rien, c'est le record dangling. Takeover. Un attaquant recrée une ressource du même FQDN dans son propre compte, et le trafic de app.votreboite.fr atterrit désormais chez lui.

Du CNAME au détournement de zone : les variantes

Le CNAME orphelin est le cas d'école, mais ce n'est pas le seul. Quatre variantes, par gravité croissante :

• CNAME dangling : l'immense majorité des cas. Un sous-domaine pointe vers un service tiers décommissionné (S3, Azure, un SaaS). On réclame la ressource, on tient le sous-domaine.
• Le A record orphelin est plus vicieux. Le sous-domaine pointe en dur vers une IP cloud libérée, or ces adresses publiques tournent vite. Une fois réattribuée à un tiers, l'IP répond de nouveau, mais ce n'est plus vous.
• Wildcard : l'amplificateur, un *.votreboite.fr en CNAME vers un service mort ne rend pas un sous-domaine vulnérable, mais une infinité : foo., bar., n'importe quoi résout vers la même cible réclamable. Une seule erreur, surface illimitée.
• NS takeover : le scénario nucléaire, si les NS d'un sous-domaine délèguent la zone à un hébergeur DNS tiers dont la zone a été supprimée, l'attaquant la recrée et devient autoritatif. Il ne contrôle plus une page : il forge tous les records de la zone : A, MX, TXT. Plus rare, mais c'est l'impact maximal.

Repérer un sous-domaine réclamable

La détection suit toujours le même pipeline en quatre temps : énumérer la surface, lire le CNAME et sa cible, matcher l'empreinte du service, valider à la main. On ne réclame jamais une ressource en aveugle, d'abord parce que c'est hors cadre, ensuite parce qu'un faux positif coûte cher en crédibilité.

Énumérer, puis résoudre

On commence par sortir le maximum de sous-domaines. Les sources passives sont reines : elles n'envoient pas un paquet à la cible. Les logs de Certificate Transparency sont la meilleure d'entre elles, chaque certificat émis y est public, ce qui révèle des sous-domaines de staging qu'aucune wordlist ne contient.

# Sources passives, incluant les logs Certificate Transparency
subfinder -d cible.fr -all -silent -o sous-domaines.txt

# amass couvre d'autres sources (et le brute-force DNS en actif)
amass enum -active -brute -d cible.fr

# Directement depuis crt.sh, sans outil tiers
curl -s 'https://crt.sh/?q=%25.cible.fr&output=json' \
  | jq -r '.[].name_value' | sort -u

# Lire le CNAME d'un sous-domaine suspect et SA cible
dig +short CNAME promo.cible.fr
# -> promo-campagne.s3.amazonaws.com.

Lire l'empreinte du service

Quand le CNAME vise un service connu, la ressource morte renvoie un message d'erreur caractéristique, une fingerprint. La base de référence est le projet can-i-take-over-xyz d'EdOverflow, qui catalogue pour chaque service son empreinte et son statut. Ce statut est crucial : tout message d'erreur n'est pas un takeover.

# Récupérer la réponse brute pour matcher la fingerprint
curl -i http://promo.cible.fr
# HTTP/1.1 404 Not Found
# ...
# <Code>NoSuchBucket</Code>
# The specified bucket does not exist   <- bucket S3 réclamable

# Scan automatisé contre la base de signatures
subzy run --targets sous-domaines.txt --hide_fails
subjack -w sous-domaines.txt -ssl -c fingerprints.json -o takeovers.txt
nuclei -l sous-domaines.txt -t http/takeovers/

SERVICE              STATUT        EMPREINTE (réponse de la ressource morte)
-------------------  ------------  -----------------------------------------
AWS S3               Vulnérable    The specified bucket does not exist
Azure (app service)  Vulnérable    NXDOMAIN (pas de réponse HTTP)
WordPress.com        Vulnérable    Do you want to register *.wordpress.com?
Surge.sh             Vulnérable    project not found
Bitbucket            Vulnérable    Repository not found
GitHub Pages         Edge case     There isn't a GitHub Pages site here.
Heroku               Edge case     No such app
Shopify              Edge case     Sorry, this shop is currently unavailable.
Fastly               Non vuln.     Fastly error: unknown domain:
Google Cloud Storage Non vuln.     NoSuchBucket   <- FAUX AMI de S3, validé

Attention à deux faux amis. Google Cloud Storage renvoie exactement le même NoSuchBucket qu'AWS S3, mais GCP impose une validation de domaine : ce n'est pas exploitable. Et GitHub Pages n'est plus un takeover trivial depuis décembre 2019 : la vérification de domaine (challenge TXT _github-pages-challenge) existe, même si elle reste optionnelle, ce qui laisse une fenêtre sur les domaines non vérifiés. Idem pour Heroku, durci en juin 2023 par un suffixe aléatoire sur les nouvelles apps : seules les anciennes restent réclamables. La leçon : une empreinte se vérifie toujours contre le statut du jour, pas contre un tuto de 2018.

Bien plus qu'un défacement

On imagine le takeover comme un barbouillage de page d'accueil. C'est l'usage le moins intéressant. Le vrai danger tient en une phrase : le navigateur et vos applications font confiance au nom du domaine, pas à qui le contrôle réellement. Cette confiance se décline en plusieurs couches, et un sous-domaine repris les hérite toutes.

Le mythe à briser en premier : « on a du HTTPS, on est protégés ». Faux. L'attaquant qui contrôle le sous-domaine demande et obtient un certificat TLS parfaitement valide (un simple challenge ACME, gratuit chez Let's Encrypt) pour ce nom. Sa page de phishing affiche le cadenas, sous votre marque. Le réflexe « vérifier le domaine et le cadenas » qu'on enseigne aux utilisateurs joue ici contre eux.

Vient ensuite le vol de cookies de session. Un cookie posé avec Domain=votreboite.fr est envoyé par le navigateur à tous les sous-domaines (RFC 6265). Un sous-domaine repris les reçoit donc automatiquement : compromission de comptes à l'échelle. Les allowlists qui font confiance à *.votreboite.fr (en CSP, en CORS, ou comme redirect_uri OAuth) transforment quant à elles le sous-domaine en plateforme d'exécution « légitime » : script autorisé par la politique, lecture cross-origin avec cookies, vol de code d'autorisation. Reste le SSO, le plus brutal : comme le résume Okta, le talon d'Achille du partage de cookie, c'est l'intégrité des sous-domaines. Un seul nom périphérique oublié, et c'est le portail fédéré entier qui vacille.

La théorie, en production

Ces scénarios ne sont pas spéculatifs. Trois affaires récentes suffisent à s'en convaincre.

• SubdoMailing (Guardio, février 2024) : plus de 8 000 domaines et 13 000 sous-domaines de marques majeures (MSN, eBay, McAfee, UNICEF, The Economist…) détournés pour envoyer ~5 millions de mails frauduleux par jour. Le cas emblématique : marthastewart.msn.com pointait vers le domaine d'un jeu-concours de 2001, laissé à l'abandon 21 ans, ré-enregistré en 2022. Les mails passaient SPF et DMARC.
• watchTowr (2025) : des chercheurs ré-enregistrent ~150 buckets S3 abandonnés pour 420 $, et reçoivent 8 millions de requêtes réclamant des binaires logiciels, des images de VM et des configs VPN d'entreprises du Fortune 500 et de gouvernements. Chacun de ces binaires, une fois servi par l'attaquant, s'exécute sur la machine qui le télécharge.
• Azure à l'échelle (Keytos, 2023) : ~15 000 sous-domaines Azure vulnérables par mois, Microsoft retirant 700+ de ses propres domaines. Le chiffre qui fait mal : sur un an, parmi un millier d'organisations prévenues, ~2 % seulement ont corrigé.

Côté bug bounty, la liste est longue : un takeover Fastly chez Snapchat (3 000 $), un contournement d'authentification chez Roblox via sous-domaine repris, le bypass de auth.uber.com par saostatic.uber.com, et même info.hacker.one chez HackerOne. Un angle mort revient sans cesse : les acquisitions. Les domaines d'une société absorbée ne sont presque jamais ré-audités : Snapchat, Slack et Twitter s'y sont fait prendre. Les récompenses vont de quelques centaines à quelques milliers de dollars selon l'impact prouvé, et grimpent nettement quand le takeover ouvre sur un contournement d'authentification.

Remédiation : l'ordre des opérations sauve la mise

La cause racine est toujours la même : on supprime la ressource avant le DNS. La règle d'or inverse cet ordre. AWS la résume d'une formule qu'on devrait afficher dans toute procédure de décommissionnement : « supprimez toujours le DNS en premier, attendez l'expiration du TTL, puis supprimez la ressource ». Concrètement :

DÉCOMMISSIONNEMENT (le bon ordre)
  1. page de maintenance sur le sous-domaine
  2. supprimer / mettre à jour le record DNS (CNAME, A, NS)
  3. attendre l'expiration du TTL (cache resolver, jusqu'à ~1 h)
  4. SEULEMENT ALORS, désallouer la ressource cloud
  5. vérifier : le CNAME ne résout plus

PROVISIONNEMENT (l'ordre inverse)
  1. créer / réclamer le virtual host chez le provider
  2. le record DNS en dernier

L'ordre manuel ne tient pas à l'échelle. Trois leviers structurels ferment la fenêtre pour de bon :

• Coupler le cycle de vie DNS et ressource : les alias records (Azure DNS, Route 53) lient le record à la ressource : si elle disparaît, l'alias devient vide, sans dangling. À défaut, gérez DNS et ressource dans le même module d'IaC (Terraform, Pulumi) pour une suppression atomique.
• Verrouiller par preuve de propriété : un TXT asuid.<sous-domaine> côté Azure, un domaine « vérifié » côté GitHub : tant que ce record existe, aucun tiers ne peut réclamer le nom.
• Tenir un inventaire d'actifs : un mapping documenté DNS ↔ ressource ↔ équipe propriétaire. C'est laborieux, mais on ne nettoie que ce qu'on sait exister.

Le vrai problème n'est pas technique, il est temporel

Un subdomain takeover se détecte en quelques commandes, mais à un instant t. Or la surface ne tient pas en place : chaque déploiement, chaque teardown de CI/CD, chaque environnement éphémère, chaque acquisition rouvre la fenêtre entre la mort d'une ressource et le nettoyage de son DNS. Azure classe d'ailleurs la menace en « haute sévérité » précisément pour les organisations qui « créent et suppriment beaucoup de ressources ».

Un audit annuel ne voit qu'une photo figée d'un film en mouvement. L'OWASP elle-même ne recommande pas un test, mais un « monitoring continu et des vérifications périodiques ». C'est exactement la promesse de l' EASM, ce pilier de la mise en conformité NIS2 : découvrir en permanence les sous-domaines (y compris ceux que vos équipes ont oubliés), surveiller leurs enregistrements DNS, et alerter dès qu'un CNAME se met à pointer dans le vide. Pas une fois par an. En continu, parce que c'est la seule cadence qui suit celle de votre infrastructure.

À retenir

• Un subdomain takeover exige deux conditions : un record DNS qui pointe vers une ressource morte, et un fournisseur qui ne vérifie pas la propriété. Sans la seconde, le record orphelin est inerte.
• Détection en quatre temps : énumérer (subfinder, logs CT), lire le CNAME et sa cible (dig), matcher l'empreinte (can-i-take-over-xyz, subzy, nuclei), valider à la main. Jamais de réclamation en aveugle.
• L'empreinte ne suffit pas : le statut prime. GCS imite S3 sans être vulnérable, GitHub et Heroku se sont durcis. On vérifie toujours contre l'état du jour.
• L'impact dépasse le défacement : certificat TLS valide, vol de cookies de session, contournement CSP/CORS/OAuth, effondrement SSO, mails authentifiés. HTTPS ne protège pas.
• Remédiation : supprimer le DNS avant la ressource, coupler les cycles de vie en IaC, et surtout tenir un inventaire : on ne nettoie que ce qu'on connaît.
• Le défaut est facile à corriger, mais la surface bouge sans cesse : seul un monitoring continu tient le rythme.

Combien de sous-domaines votre organisation expose-t-elle, là, maintenant, et combien pointent déjà dans le vide ? Si la réponse vous fait hésiter, c'est précisément le métier de notre plateforme de gestion de surface d'attaque externe. Et si vous préférez qu'on cherche ces angles morts à la main, en conditions réelles, parlez-en avec un humain sur la page contact.