Sous-domaines : la surface d'attaque cachée
Chaque organisation possède plus de sous-domaines qu'elle ne l'imagine. Au-delà des classiques www, mail, ftp, il existe des sous-domaines pour les environnements de développement (dev, staging, test), les API (api, api-v2), les panneaux d'administration (admin, panel, cpanel), les services internes (jira, confluence, gitlab), et les services cloud (app, cdn, assets). Chacun d'entre eux représente un point d'entrée potentiel pour un attaquant. Le Subdomain Finder automatise la découverte de ces sous-domaines, fournissant une carte complète du périmètre du domaine.
Le problème de la sécurité des sous-domaines est aggravé par le « shadow IT » : des services créés par différentes équipes, souvent oubliés après la phase de test, qui restent exposés sur Internet sans mises à jour de sécurité, sans surveillance et parfois avec des identifiants par défaut. Un sous-domaine oublié comme staging.exemple.com avec une version vulnérable du CMS est un cadeau pour tout attaquant. La première défense est la prise de conscience : savoir quels sous-domaines existent.
Techniques d'énumération des sous-domaines
Le Subdomain Finder utilise de multiples sources : les Certificate Transparency Logs (registres publics de tous les certificats SSL émis, qui contiennent les noms d'hôte couverts), la recherche DNS par force brute avec des listes de mots (interrogeant des milliers de noms courants), l'analyse des enregistrements DNS existants (NS, MX, TXT contiennent souvent des références à des sous-domaines), et d'autres sources OSINT. La combinaison de plusieurs techniques maximise la couverture.
Que faire avec les sous-domaines trouvés
Une fois la liste obtenue, chaque sous-domaine doit être analysé. Vérifiez le certificat SSL avec SSL Check — les sous-domaines sans HTTPS ou avec des certificats expirés sont un signal d'alarme. Contrôlez les en-têtes de sécurité avec Security Headers pour identifier les configurations faibles. Recherchez les sous-domaines qui résolvent vers des IP privées (10.x, 172.16-31.x, 192.168.x) indiquant une configuration erronée, et les CNAME orphelins pointant vers des services désactivés (risque de subdomain takeover).
Le subdomain takeover est un risque particulièrement grave : si un CNAME pointe vers un service cloud (ex. something.azurewebsites.net) qui n'est plus actif, un attaquant peut réclamer ce nom d'hôte chez le fournisseur cloud et servir du contenu arbitraire sur votre sous-domaine. Cela permet un phishing crédible, la distribution de malwares et la compromission de la réputation du domaine. La prévention est simple : supprimez les enregistrements DNS des sous-domaines qui ne sont plus utilisés.
Pour un audit de sécurité complet du périmètre, combinez le Subdomain Finder avec une analyse systématique de chaque sous-domaine trouvé. Documentez chaque sous-domaine avec son objectif, son responsable et sa date de dernière utilisation. Cette cartographie continue du périmètre est une composante fondamentale de tout programme de sécurité, et le Domain Health peut fournir un rapport consolidé sur la santé globale du domaine et de ses dépendances.