Les sous-domaines (api.votre-site.fr, admin.votre-site.fr, mail.votre-site.fr, blog.votre-site.fr, etc.) représentent la principale surface d'attaque DNS d'une organisation. Ils s'accumulent au fil des projets, sont rarement documentés, expirent silencieusement, et se font compromettre via subdomain takeover sans que personne ne s'en aperçoive. Surveiller uniquement le domaine principal laisse un angle mort qui couvre 70 à 90 % de la surface réelle.
Sur un domaine professionnel typique, on trouve entre 10 et 100 sous-domaines actifs. La majorité ne sont pas dans les outils de monitoring de l'organisation. Voici pourquoi c'est dangereux et comment construire un dispositif de surveillance complet.
Pourquoi les sous-domaines sont la vraie surface d'attaque
Quatre raisons font des sous-domaines la cible préférée des attaquants :
1. Ils héritent de la confiance du domaine principal
Un sous-domaine partage le cookie root, la marque, l'historique SEO et la légitimité visuelle. Un email de phishing depuis support.votre-marque.fr a beaucoup plus de chances de tromper qu'un email depuis un domaine inconnu — y compris auprès des employés.
2. Ils s'accumulent sans gouvernance
Chaque projet, chaque outil tiers, chaque test crée typiquement un sous-domaine. Personne ne les inventorie. Au bout de quelques années, l'organisation a 30 à 100 sous-domaines actifs dont la moitié n'est plus utilisée mais reste vivante en DNS.
3. Ils sont la cible privilégiée du subdomain takeover
Quand un sous-domaine pointe via CNAME vers un service tiers (Heroku, GitHub Pages, Shopify, AWS S3, Azure, Netlify, Vercel) qui est ensuite désaffecté sans nettoyer le CNAME, n'importe qui peut récupérer la ressource côté service tiers et s'approprier le sous-domaine.
4. Leurs certificats SSL expirent souvent
Le certificat du domaine principal est généralement bien suivi. Ceux des sous-domaines (notamment ceux gérés séparément, sans wildcard) sont les premiers à expirer faute d'attention.
Les 5 risques majeurs à monitorer
1. Subdomain takeover via CNAME orphelin
Le risque le plus médiatisé. Détection : auditer chaque CNAME de votre zone DNS et tester la destination. Si le service tiers retourne une erreur "this resource is not claimed" ou similaire, le sous-domaine est vulnérable et n'importe qui peut le revendiquer en quelques minutes.
Outils gratuits : subjack, subzy, nuclei (templates takeover), ou un monitoring DNS qui croise vos CNAME avec une base de patterns vulnérables.
2. Certificat SSL expiré sur sous-domaine
Quand le wildcard ne couvre pas tous les sous-domaines (ex. différentes régions, différents niveaux de profondeur), chaque sous-domaine a son propre certificat avec sa propre date d'expiration. Sans monitoring, le sous-domaine support.api.votre-site.fr peut être down depuis trois semaines sans que personne ne s'en aperçoive.
3. Sous-domaine orphelin pointant vers une IP morte
Un sous-domaine qui pointe vers une IP qui ne répond plus (serveur mis hors service, instance EC2 supprimée, container Kubernetes qui n'existe plus). Risque : si l'IP est ré-attribuée par le fournisseur cloud (cas classique chez AWS et Azure), un autre client récupère votre nom de domaine. Il peut alors monter un service phishing qui exploite votre légitimité résiduelle.
4. Sous-domaine exposant un service interne par erreur
Console admin Kibana publiquement accessible, dashboard Grafana ouvert, base Elasticsearch sans auth, panel d'admin Symfony en mode debug. Les sous-domaines internes qui se retrouvent exposés (par mauvaise config firewall, mauvais routage cloud) sont une catégorie d'incident classique.
5. Sous-domaine apparaissant sur une base de threat intelligence
Si un de vos sous-domaines est compromis et utilisé pour distribuer du malware ou du phishing, il finit sur les bases publiques URLhaus ou Google Safe Browsing. Cela apparaît dans les navigateurs comme un avertissement « site dangereux » sur tous vos sous-domaines proches, par effet de halo.
Comment inventorier tous vos sous-domaines
Avant de monitorer, il faut savoir ce qui existe. Trois approches complémentaires :
1. Export de la zone DNS
Exporter tous vos enregistrements depuis le panel admin de votre registrar ou fournisseur DNS. Inventaire de référence côté propriétaire.
2. Certificate Transparency logs
Tous les certificats SSL émis sont enregistrés publiquement dans les CT logs (initiative Google). Outils gratuits qui les interrogent : crt.sh, Censys, certspotter. Permet de découvrir des sous-domaines pour lesquels un certificat a été émis, même si vous ne les avez pas inventoriés.
3. Énumération DNS active
Outils comme amass, subfinder, assetfinder qui combinent CT logs, brute-force de wordlists, et requêtes DNS pour identifier les sous-domaines actifs. Vue exhaustive mais peut générer des faux positifs.
Recommandation : combiner les trois pour ne rien rater. La différence entre les trois listes révèle souvent des sous-domaines fantômes.
Comment monitorer tous vos sous-domaines en continu
1. Inventaire vivant
Documenter chaque sous-domaine avec son objectif, son propriétaire, son service de destination, sa date de dernier audit. Versionner en Git ou dans un wiki. Réviser tous les 3 mois.
2. Monitoring DNS centralisé
Un outil qui surveille tous vos sous-domaines depuis une seule interface, alerte au moindre changement DNS, croise les CNAME avec les patterns connus de takeover, et vérifie l'expiration SSL individuelle de chaque sous-domaine.
3. Procédure de désaffectation
Quand un projet se termine, supprimer le CNAME ou A AVANT de désaffecter le service tiers. Ordre inverse = subdomain takeover.
4. Audit régulier des CT logs
Vérifier mensuellement crt.sh pour repérer les nouveaux certificats émis sur vos sous-domaines. Détecte les sous-domaines créés sans votre connaissance (par un service tiers, un développeur), ou pire, par un attaquant qui aurait usurpé un sous-domaine.
5. Filtrage threat intelligence
Croiser périodiquement la liste de vos sous-domaines avec URLhaus et Google Safe Browsing. Détecte les compromissions actives.
Cas concret : un subdomain takeover évité
Une entreprise SaaS avait créé blog.votre-saas.fr en 2022 sur Medium for Brands. Service interrompu en 2024, abonnement non renouvelé. Le CNAME blog.votre-saas.fr → custom.medium.com est resté en place dans la zone DNS — personne ne l'a nettoyé.
En janvier 2025, un audit de routine via outil de monitoring DNS détecte que le CNAME pointe vers une ressource Medium « not claimed ». Vulnérabilité de type subdomain takeover identifiée. Action immédiate :
- Test du takeover en interne (réservation de la ressource Medium par l'équipe sécurité pour bloquer un attaquant)
- Suppression du CNAME blog.votre-saas.fr de la zone DNS
- Communication interne pour rappel de la procédure de désaffectation
Coût : 15 minutes d'intervention. Risque évité : phishing depuis blog.votre-saas.fr exploitant la marque, potentiellement des semaines avant détection sans monitoring.
Ce qu'il faut retenir
- Les sous-domaines représentent 70 à 90 % de la vraie surface d'attaque DNS d'une organisation.
- Cinq risques principaux : subdomain takeover, SSL expiré, IP morte, service interne exposé, présence sur threat intelligence.
- L'inventaire complet combine export zone DNS + CT logs + énumération active.
- Monitoring centralisé continu = seule défense réaliste contre la dérive.
- La procédure de désaffectation (supprimer DNS AVANT service tiers) prévient la majorité des subdomain takeovers.
Questions fréquentes
Combien de sous-domaines a une entreprise typique ?
Entre 10 et 100 sous-domaines actifs pour une PME, plusieurs centaines pour une organisation de taille moyenne, des milliers pour les grands groupes. La majorité sont créés au fil de l'eau et oubliés.
Comment savoir si un sous-domaine est vulnérable au takeover ?
Tester chaque CNAME : si la résolution échoue ou si le service de destination retourne une erreur du type "this resource is not claimed" ou "NoSuchBucket" (AWS S3), le sous-domaine est vulnérable. Outils gratuits : subjack, subzy, nuclei avec templates de takeover.
Un certificat wildcard couvre-t-il tous mes sous-domaines ?
Non. Un wildcard *.votre-domaine.fr couvre uniquement les sous-domaines de premier niveau (api.votre-domaine.fr, blog.votre-domaine.fr) mais pas les sous-sous-domaines (support.api.votre-domaine.fr). Pour ces derniers, il faut soit un wildcard imbriqué *.api.votre-domaine.fr, soit des certificats individuels.
Comment être alerté quand un nouveau certificat est émis pour un de mes sous-domaines ?
S'abonner aux Certificate Transparency logs via des services comme Cert Spotter (gratuit jusqu'à un certain volume), Facebook CT Monitoring, ou intégrer crt.sh dans un script de monitoring. Particulièrement utile pour détecter les certificats émis frauduleusement par un attaquant ayant pris le contrôle d'un sous-domaine.
Que faire si je découvre un sous-domaine vulnérable ?
Trois actions immédiates : 1) Si vous gérez encore le service tiers, restaurer la ressource pour bloquer le takeover. 2) Sinon, supprimer le CNAME ou A de la zone DNS. 3) Auditer les autres sous-domaines pour vérifier qu'aucun n'est dans la même situation.
Un monitoring DNS détecte-t-il automatiquement les subdomain takeovers ?
Les bons outils oui. Domains Defender, par exemple, croise vos CNAME avec une base de patterns connus de services tiers vulnérables (Heroku, GitHub Pages, AWS S3, Shopify, etc.) et alerte si une de ces destinations retourne un signal de ressource non revendiquée.
Reprendre le contrôle de tous vos sous-domaines
Surveiller uniquement le domaine principal en 2026 revient à surveiller la porte d'entrée d'une maison qui a 50 fenêtres ouvertes. Un dispositif sérieux couvre l'inventaire complet, le monitoring continu, et la détection des patterns de compromission.
Domains Defender surveille tous vos sous-domaines en continu (DNS, SSL, threat intelligence URLhaus + Google Safe Browsing), alerte au moindre changement, et offre des plans adaptés au volume — du domaine seul (Solo) aux domaines illimités (Enterprise). Hébergé en France, conforme RGPD, essai gratuit 7 jours à partir de 4,99€ HT/mois.
Auditer vos sous-domaines gratuitement — ou activer la surveillance continue.