Posez la question à votre équipe : combien de sous-domaines l'organisation a-t-elle ? La réponse vient vite, souvent avec un chiffre rond. Puis comparez-la à ce que n'importe qui peut trouver en deux minutes, de l'extérieur, sans rien vous demander. L'écart entre les deux chiffres est la mesure la plus honnête de votre exposition : ce qui est en ligne à votre nom, mais que personne ne revendique.
Les attaquants n'ont pas besoin de forcer la porte principale, surveillée, corrigée, documentée. Ils cherchent celle que tout le monde a oubliée.
Ce qui reste en ligne quand le projet s'arrête
L'exposition sans propriétaire ne naît pas d'une erreur. Elle naît d'une fin : une campagne qui se termine, un projet qu'on ferme, un fournisseur qu'on remplace, une entreprise qu'on achète. Le projet s'arrête, la ligne budgétaire disparaît, l'équipe passe à autre chose. Ce qui était en ligne, souvent, y reste.
On retrouve les mêmes familles d'une organisation à l'autre :
- Le sous-domaine d'une ancienne campagne : un site de concours, une page d'événement, un portail de test monté par une agence. Le contrat est fini, l'adresse pointe toujours quelque part.
- L'instance infonuagique d'un projet terminé : une machine virtuelle de démonstration, un espace de stockage partagé « pour le temps du projet », une base de données de recette jamais éteinte.
- L'outil acheté par un service : un logiciel en mode SaaS payé par carte de crédit par le marketing, les ventes ou les RH, avec des données de l'entreprise dedans et une connexion à votre messagerie. La TI ne le voit pas, donc personne ne le révise. C'est le cousin du shadow AI dont parlait notre série IA.
- Le serveur ou l'équipement en fin de vie : il marche, il rend service, mais l'éditeur ne publie plus de correctifs. Chaque faille découverte après la fin du support reste ouverte pour toujours.
- Le DNS ou le certificat orphelin : un enregistrement qui pointe vers un service qui n'existe plus, un certificat qui expire sans que personne ne reçoive l'alerte, parce que l'adresse de notification était celle d'un employé parti.
- L'ancien site d'une filiale : après une acquisition, le site, la messagerie et les serveurs de l'entreprise achetée continuent de vivre à côté des vôtres, avec leurs propres règles, ou sans règles.
Ce que ça change : aucun de ces actifs n'apparaît dans le plan de correction, parce qu'aucun n'a de propriétaire pour l'y inscrire. Ils ne sont pas mal gérés. Ils ne sont pas gérés du tout.
Le cas d'école : la prise de contrôle d'un sous-domaine
Un exemple montre pourquoi l'oubli n'est pas inoffensif. Microsoft le décrit en détail dans sa documentation Azure, sous le nom de « dangling DNS », un enregistrement DNS qui pend dans le vide. Le scénario tient en trois temps :
- Création. Une équipe crée une ressource infonuagique et ajoute dans votre zone DNS un alias, par exemple
promo.votreentreprise.com, qui pointe vers elle. - Suppression. Le projet se termine, la ressource est supprimée. L'alias, lui, reste dans votre DNS.
- Prise de contrôle. Un attaquant repère l'alias orphelin, crée chez le même fournisseur une ressource portant le nom libéré, et reçoit désormais le trafic destiné à votre sous-domaine. Il en contrôle le contenu.
Microsoft qualifie ces prises de contrôle de menace « courante » et « de gravité élevée » pour les organisations qui créent et suppriment beaucoup de ressources. Les conséquences qu'il énumère dépassent l'image de marque : une page d'hameçonnage hébergée sous votre propre nom de domaine, des témoins de session récupérés auprès de visiteurs de bonne foi, et même un certificat TLS valide obtenu par l'attaquant pour ce sous-domaine. Microsoft le souligne : un certificat ne protège pas contre ce scénario, puisque l'attaquant peut en obtenir un. Statut : documenté par l'éditeur.
Le mécanisme n'est pas propre à Azure. Tout service qui vous attribue un nom que vous pointez depuis votre DNS, puis le libère quand vous le supprimez, peut produire le même vide. La correction est simple ; c'est l'inventaire qui est difficile.
Pourquoi votre inventaire ne les voit pas
La plupart des inventaires sont construits de l'intérieur : ce que la TI a acheté, installé, déclaré. L'exposition sans propriétaire, elle, se voit de l'extérieur. Elle existe parce qu'elle n'est passée par aucun des processus qui alimentent l'inventaire.
C'est pour cela que la CISA a fait de la découverte d'actifs une obligation, et non une bonne pratique. Sa directive opérationnelle BOD 23-01, publiée le 3 octobre 2022 pour les agences fédérales américaines, part d'un constat : une visibilité continue et complète des actifs est « une condition préalable de base » pour toute organisation qui veut gérer son risque. Elle impose une découverte automatisée des actifs tous les sept jours, et une recherche de vulnérabilités sur tout ce qui a été découvert tous les quatorze jours. Statut : texte officiel. Vous n'êtes pas une agence fédérale, mais l'ordre de grandeur vaut pour tout le monde : un inventaire refait une fois par an décrit une organisation qui n'existe plus.
Pour la fin de vie, la CISA est tout aussi nette. Sa liste des « mauvaises pratiques » place en tête l'usage de logiciels sans support dans les infrastructures critiques, une pratique qu'elle juge dangereuse et « particulièrement grave » pour les technologies accessibles depuis Internet. Un équipement en fin de vie exposé, c'est une faille connue qui ne sera jamais corrigée.
C'est précisément le terrain de la gestion de la surface d'attaque externe (EASM) : regarder l'organisation comme un attaquant la voit, plutôt que comme elle se décrit.
La méthode : trouver, attribuer, décider
1. Trouver, de l'extérieur. Partez de vos noms de domaine et énumérez ce qui existe réellement : sous-domaines, adresses IP, services qui répondent, certificats émis à votre nom. Ajoutez ce que l'extérieur ne montre pas mais que la comptabilité connaît : les abonnements SaaS payés par carte de crédit, les comptes infonuagiques ouverts par projet, les domaines enregistrés par une agence.
2. Attribuer un propriétaire, nommément. Pour chaque actif, une personne, pas un service. Si personne ne lève la main en deux semaines, l'actif devient la responsabilité par défaut de la personne qui pilote la sécurité, avec un délai pour décider. Un actif sans nom à côté reste exposé indéfiniment.
3. Décider : garder, corriger ou retirer. Trois issues seulement.
- Garder : l'actif sert, il entre dans l'inventaire, le plan de correction et la surveillance, comme les autres.
- Corriger : il sert, mais il est mal configuré, sans support ou mal protégé ; on le met à niveau, on le remplace, ou on l'isole d'Internet en attendant.
- Retirer : il ne sert plus. On supprime l'enregistrement DNS puis la ressource, dans cet ordre : si la ressource disparaît la première, l'alias pend dans le vide, même quelques jours. On résilie l'abonnement, on récupère les données.
Puis, pour que le stock ne se reconstitue pas, ajoutez une ligne à vos procédures de fin de projet, de changement de fournisseur et d'intégration d'acquisition : « retirer les enregistrements DNS et les accès, vérifier qu'ils ont disparu ». Microsoft fait exactement cette recommandation : mettre la suppression de l'entrée DNS dans la liste des vérifications obligatoires quand on retire un service.
Le test de la semaine : vingt minutes, deux chiffres
- Demandez à votre équipe, sans qu'elle cherche : combien de sous-domaines avons-nous ? Notez le chiffre.
- Ouvrez un moteur de recherche des journaux de transparence des certificats, comme crt.sh, et cherchez votre domaine principal. Ces journaux sont publics et ne fonctionnent qu'en ajout : chaque certificat TLS émis pour vos noms y est inscrit, et n'importe qui peut les consulter. Les attaquants le font.
- Comptez les sous-domaines distincts qui apparaissent, puis comparez.
Trois résultats doivent vous alerter. Un écart que personne ne sait expliquer entre les deux chiffres : votre inventaire décrit ce que vous avez prévu, pas ce que vous avez. Des noms que personne ne reconnaît : chacun est un actif sans propriétaire, à traiter cette semaine. Des noms de projets terminés, de campagnes passées ou d'une entreprise achetée : vérifiez qu'ils ne pointent plus nulle part, ou qu'ils pointent vers quelque chose que vous contrôlez encore.
Ce test ne voit que ce qui a reçu un certificat. Il sous-estime donc le problème : c'est un plancher, pas un plafond.
Ce que vous devriez avoir samedi prochain
Une liste, même courte, des actifs exposés que personne ne revendiquait, avec à côté de chacun un nom et une décision : garder, corriger ou retirer. Et une ligne ajoutée à vos procédures de fin de projet. C'est modeste. C'est aussi la partie de la surface d'attaque que les attaquants trouvent en premier, parce que personne ne la défend.
Pour aller plus loin sur la méthode, notre fiche sur la gestion de la surface d'attaque externe explique comment passer d'un inventaire ponctuel à une découverte continue.
Sources : Microsoft Learn, Prevent dangling DNS entries and avoid subdomain takeover · CISA, Binding Operational Directive 23-01, Improving Asset Visibility and Vulnerability Detection on Federal Networks · CISA, Bad Practices · Certificate Transparency, How CT Works