Surface d'attaque externe : comment faire l'inventaire de la vôtre en 30 minutes

Introduction

Posez la question à une DSI : « combien d'actifs exposez-vous sur Internet ? ». Vous obtiendrez un chiffre. Faites l'inventaire réel deux heures plus tard, vous en trouverez davantage. C'est systématique, et ce n'est pas un problème de compétence : c'est la conséquence normale de dix ans de campagnes marketing, de migrations, de préproductions laissées en ligne et de prestataires qui ont créé un sous-domaine « juste pour un test ».

Cet écart porte un nom dans le métier : la surface d'attaque externe. Et il existe un acronyme pour la discipline qui consiste à la maîtriser, EASM (External Attack Surface Management). Avant d'acheter une plateforme qui porte cet acronyme, on peut faire l'exercice à la main. C'est ce que propose cet article : une méthode en cinq passes, réalisable en une demi-heure sur votre propre domaine, avec des outils publics et gratuits.

Ce qu'on appelle surface d'attaque externe

C'est l'ensemble de ce qu'un attaquant peut atteindre depuis Internet sans identifiants et sans être invité. Concrètement : vos noms de domaine, vos sous-domaines, vos adresses IP publiques, les services qui écoutent dessus, vos applications web et vos API, vos buckets et vos environnements cloud exposés.

Ce n'est pas votre parc informatique. Ce n'est pas non plus votre inventaire d'actifs au sens de l'ISO 27001, qui couvre aussi l'interne. Nous avons écrit un guide séparé sur la cartographie du système d'information, qui traite l'exercice dans son ensemble. Ici, on se limite strictement à ce qui est visible du dehors, parce que c'est la partie qu'un attaquant voit avant vous.

Une définition opérationnelle, plus utile que la définition académique : votre surface d'attaque externe, c'est tout ce qui répond à une requête venue d'Internet et que vous ne pouvez pas éteindre sans prévenir quelqu'un.

Les six familles d'actifs qui manquent toujours

Sur les périmètres que nous cartographions, l'écart entre l'inventaire déclaré et la réalité se loge presque toujours dans les mêmes catégories. Par ordre de fréquence :

1. Les sous-domaines de campagne. promo-2023.exemple.fr, webinar.exemple.fr, créés par le marketing avec un prestataire, jamais supprimés.
2. Les environnements de recette et de préproduction. preprod, staging, uat, demo. Souvent avec les mêmes données qu'en production et une authentification plus faible.
3. Les héritages de fusion-acquisition. Une société rachetée en 2021 dont les domaines pointent encore vers une infrastructure que plus personne ne patche.
4. Les outils métier en SaaS déclarés en CNAME. Le sous-domaine est chez vous, le service est ailleurs, et la responsabilité de la mise à jour est floue pour tout le monde.
5. Les API et les endpoints techniques. api, ws, graphql, admin, vpn, rarement dans le même inventaire que les sites web.
6. Les enregistrements DNS orphelins. Un CNAME qui pointe vers un bucket ou une instance libérée depuis. C'est le scénario de prise de contrôle de sous-domaine, et il est trivial à exploiter quand il se présente.

Sur ces six familles, quatre ne relèvent pas de la DSI au moment de leur création. C'est pour ça que l'inventaire déclaré ne suffit jamais.

La méthode, en cinq passes

Prenez votre domaine racine. On l'appellera exemple.fr dans les commandes. Comptez trente minutes pour un périmètre de PME ou d'ETI mono-marque, davantage si vous avez plusieurs marques.

Passe 1 : les domaines, pas seulement le domaine

Commencez par lister les noms que vous possédez vraiment. Le registre est votre source de vérité, et il s'interroge en RDAP, le successeur structuré de WHOIS :

curl -s https://rdap.org/domain/exemple.fr | jq '{
  registrar: .entities[]?.vcardArray,
  status: .status,
  events: [.events[] | {action: .eventAction, date: .eventDate}]
}'

Trois choses à regarder dans la réponse :

• La date de création. Elle vous dit si le domaine fait partie de l'historique de la société ou d'une acquisition oubliée.
• Le registrar. Plusieurs registrars pour une même marque, c'est le symptôme d'achats faits en dehors du processus.
• Le champ status. Cherchez clientTransferProhibited. Son absence signifie que le verrou de transfert n'est pas posé, et c'est un vrai constat, pas un détail administratif : c'est la porte des détournements de domaine.

Faites le tour de vos marques commerciales, de vos noms de produits et des extensions que vous avez déposées défensivement. Beaucoup d'entreprises redécouvrent à ce stade des .com achetés il y a huit ans qui redirigent encore quelque part.

Passe 2 : les sous-domaines, via les certificats

C'est la passe la plus rentable. Chaque fois que quelqu'un chez vous a généré un certificat TLS, l'autorité de certification l'a publié dans les journaux de Certificate Transparency. Ces journaux sont publics, et ils sont consultables gratuitement :

curl -s 'https://crt.sh/?q=%25.exemple.fr&output=json' \
  | jq -r '.[].name_value' | sed 's/^\*\.//' | sort -u > sous-domaines.txt

Vous obtiendrez une liste brute, avec des doublons et des entrées mortes. C'est normal, et c'est déjà beaucoup plus complet que votre zone DNS, parce que le certificat a été demandé par la personne qui montait le service, pas par celle qui tient l'inventaire.

Vérifiez ensuite lesquels répondent encore :

for h in $(cat sous-domaines.txt); do
  ip=$(dig +short "$h" A | tail -1)
  [ -n "$ip" ] && echo "$h -> $ip"
done

Un piège classique à ce stade : le wildcard DNS. Si *.exemple.fr résout vers une IP, tous vos tests répondront et votre liste sera inutilisable. Testez un nom qui ne peut pas exister avant de conclure quoi que ce soit :

dig +short ff-nx-probe-7f3.exemple.fr A

Si ça répond, vous avez un wildcard, et il faut alors comparer les réponses HTTP plutôt que la simple résolution DNS.

Passe 3 : ce qu'il y a derrière les adresses

Regroupez les IP obtenues et regardez à qui elles appartiennent. L'opérateur réel se lit sur l'ASN, et Team Cymru l'expose par DNS, sans clé ni quota :

dig +short 1.0.0.127.origin.asn.cymru.com TXT

Le format est particulier : on inverse les octets de l'adresse avant d'ajouter le suffixe. Pour 127.0.0.1, on interroge donc 1.0.0.127.origin.asn.cymru.com.

Ce que vous cherchez ici, c'est la cohérence. Trois hébergeurs pour une entreprise qui n'en déclare qu'un, c'est une piste. Une adresse chez un fournisseur cloud sur un compte que personne ne revendique, c'en est une meilleure.

Passe 4 : ce qui est ouvert

Pour chaque adresse publique, vous voulez savoir quels ports répondent et quelles versions tournent dessus. Vous pouvez scanner vous-même, mais sur des IP mutualisées d'hébergeur c'est une mauvaise idée juridiquement autant que techniquement. La voie passive existe : Shodan publie InternetDB, une API sans clé qui rend ce qu'il a déjà observé.

curl -s https://internetdb.shodan.io/1.1.1.1 | jq

Vous récupérez les ports, les produits identifiés avec leur version, et les CVE que Shodan a corrélées. Attention à la lecture : ces CVE sont déduites d'une bannière de version, pas vérifiées. Un service peut afficher une version vulnérable et avoir été patché par rétroportage de la distribution. Prenez la liste comme une file de priorités à instruire, pas comme un rapport de vulnérabilités. Nous détaillons cette différence dans notre comparatif des types de scans de vulnérabilités.

Passe 5 : la couche mail et la couche registre

Cette passe prend cinq minutes et c'est souvent celle qui remonte le risque le plus concret, parce qu'un domaine mal configuré s'usurpe sans toucher à votre infrastructure.

dig +short TXT exemple.fr | grep spf
dig +short TXT _dmarc.exemple.fr
dig +short MX exemple.fr
dig +short CAA exemple.fr

Ce qu'on regarde :

Faites la manipulation sur tous les domaines de la passe 1, pas seulement le principal. Les domaines secondaires, qui n'envoient pas de mail, sont ceux qu'on oublie de protéger, et donc ceux qu'on usurpe.

Ce que cette méthode ne verra pas

Autant le dire franchement, parce que c'est ce qui distingue un inventaire honnête d'un faux sentiment de couverture :

• Les sous-domaines sans certificat. Un service en HTTP simple ou derrière un certificat auto-signé n'apparaît pas dans les journaux CT. Il faut une énumération DNS par dictionnaire pour le trouver.
• Ce qui a été mis en ligne depuis votre dernier passage. Une photo à un instant T se périme.
• Les actifs des filiales et des prestataires qui portent votre marque sans porter votre domaine.
• Les vulnérabilités applicatives. Rien de tout cela ne teste une injection, un contrôle d'accès cassé ou une logique métier de travers. Vous avez un inventaire, pas un audit.

Et surtout : cette méthode donne une photo. Or la surface bouge. Entre le moment où vous terminez ce tableur et le moment où votre comité de direction le lit, quelqu'un a probablement publié un sous-domaine. Nous avons vu des inventaires soignés devenir faux en trois semaines, non pas par négligence, mais simplement parce que l'entreprise continuait de travailler.

Le raccourci

Les cinq passes ci-dessus, nous les avons câblées dans un aperçu gratuit accessible depuis la page d'accueil. Vous saisissez un domaine, il interroge le DNS public, le registre RDAP, l'ASN et InternetDB, puis rend un rapport lisible. Aucune inscription, et l'analyse tourne pour l'essentiel dans votre navigateur.

C'est un aperçu, pas la plateforme. La différence tient en un mot : la récurrence. Flawfence refait cette cartographie en continu, y ajoute une énumération DNS par dictionnaire, teste réellement les vulnérabilités trouvées au lieu de les déduire d'un numéro de version, et vous alerte quand quelque chose de nouveau apparaît sur votre périmètre. C'est le même exercice, mais tous les jours et sans vous.

FAQ

Surface d'attaque externe et cartographie du SI, c'est pareil ?

Non. La cartographie du SI couvre tout, y compris l'interne, les flux et les applications métier. La surface d'attaque externe n'est que la partie visible depuis Internet. Elle est plus étroite, mais c'est celle qu'un attaquant explore en premier, et c'est la seule qu'on peut cartographier sans rien installer.

Ai-je le droit de faire ces recherches sur mon propre domaine ?

Oui. Les cinq passes décrites ici s'appuient sur des données publiques (DNS, journaux de transparence des certificats, registre RDAP, observations Shodan). Vous ne touchez pas la cible. La question se pose différemment pour un scan de ports actif, qui lui atteint le serveur : sur une infrastructure mutualisée, vous n'êtes pas seul dessus.

À quelle fréquence refaire l'exercice ?

Trimestriellement si vous le faites à la main, c'est déjà bien. Le bon rythme théorique est continu, parce que le risque n'apparaît pas au moment du scan mais au moment de la mise en ligne. Entre les deux, un compromis raisonnable existe : refaire la passe 2 (certificats) tous les mois, elle prend cinq minutes et c'est celle qui bouge le plus.

Combien d'actifs vais-je découvrir en plus de mon inventaire ?

Impossible à promettre, ça dépend entièrement de votre historique. Sur nos cartographies, l'écart se situe couramment entre 20 et 30 % pour une entreprise structurée, et il grimpe fortement en cas de croissance externe. Si vous trouvez zéro écart, vérifiez votre méthode avant de vous réjouir.

Conclusion

Un inventaire de surface externe n'est pas un projet, c'est un après-midi. Ce qui est difficile, ce n'est pas de le faire une fois, c'est de le maintenir vrai. Commencez par les cinq passes, notez ce que vous trouvez, et surtout notez qui est responsable de chaque actif découvert. C'est cette colonne-là, plus que la liste elle-même, qui rendra service à votre prochaine analyse de risque.

Et si vous voulez la photo avant de vous lancer, saisissez votre domaine sur la page d'accueil. Vous saurez en une minute si l'exercice vaut la demi-heure.