Découverte d'actifs (asset discovery) : cartographier sa surface
d'attaque externe

Vous tapez dig +short cible.fr, une IP sort, tout va bien. Puis vous lancez subfinder -d cible.fr et l'écran défile : 47 noms d'hôtes, dont un gitlab-runner.ci.cible.fr, un vpn-legacy.cible.fr et un metabase.data.cible.fr que personne, en interne, n'a jamais déclaré. Vous veniez d'interroger un seul domaine. La liste, elle, remonte des années de déploiements oubliés. C'est ça, la découverte d'actifs : partir de presque rien et reconstituer, de proche en proche, tout ce qu'une organisation expose vraiment sur Internet.

Ce recensement porte un nom, l'asset discovery : c'est le premier geste de tout attaquant qui vise une organisation, et le défenseur qui le néglige lui laisse une longueur d'avance. Autant le mener d'abord. On va donc cartographier sa surface d'attaque externe du passif au plus actif, commandes à l'appui : énumération de sous-domaines, remontée par l'ASN, scan de ports et de services, actifs cloud, et le shadow IT qui traîne au fond de chaque périmètre.

La découverte d'actifs, du plus passif au plus actif

Il y a un ordre, et il n'est pas cosmétique. On commence toujours par les techniques passives : elles n'envoient pas un seul paquet à la cible, puisqu'on interroge des tiers (registres, moteurs de scan, journaux publics) qui ont déjà fait le travail. C'est invisible, ça ne déclenche aucun IDS, et ça ratisse large. On ne passe à l'actif (résolution, probe HTTP, scan de ports) qu'une fois qu'on a une liste de candidats à valider, parce que là, on laisse des traces dans les logs de la cible.

PASSIF  (aucun paquet vers la cible, invisible)
  crt.sh / logs CT ....... sous-domaines via certificats
  passive DNS ............ résolutions historiques (VirusTotal, ...)
  whois / ASN / RADb ..... plages IP possédées par l'organisation
  Shodan / Censys ........ services déjà indexés par des tiers
        |
        v   on obtient une liste de candidats
ACTIF   (on émet du trafic vers la cible, loggable)
  dnsx ................... on résout : lesquels existent vraiment ?
  bruteforce DNS ......... on devine les noms non publiés
  httpx ................. on sonde les serveurs web qui répondent
  naabu / nmap .......... on scanne ports et versions de services

Cette discipline (passif d'abord, actif ensuite) sépare une reconnaissance propre d'un scan bourrin qui alerte la cible dès la première minute. C'est aussi le cœur du moteur d'un EASM : si le terme ne vous parle pas, on pose tout à plat dans qu'est-ce que l'EASM.

L'énumération de sous-domaines, le nerf de la guerre

Pour l'immense majorité des organisations, la surface se cache dans les sous-domaines. La marque possède un ou deux domaines racine, mais chaque équipe, chaque produit, chaque environnement en dérive des dizaines de sous-domaines. Les énumérer, c'est 80 % du travail de découverte.

Les sources passives d'abord

La meilleure source passive, et de loin, ce sont les journaux de Certificate Transparency : chaque certificat TLS émis y est publié, public et permanent. Un certbot qui provisionne grafana.staging.cible.fr grave ce nom dans le marbre, que vous l'ayez publié ou non. On ratisse ces logs avec crt.sh, et on agrège d'autres sources OSINT (passive DNS, archives) avec subfinder ou amass.

# Sources passives agrégées (dont les logs CT), dédoublonnées
subfinder -d cible.fr -all -silent -o subs.txt

# amass en passif : moteurs OSINT, passive DNS, archives
amass enum -passive -d cible.fr

# crt.sh en direct, sans aucun outil tiers
curl -s 'https://crt.sh/?q=%25.cible.fr&output=json' \
  | jq -r '.[].name_value' | sed 's/^\*\.//' | sort -u
# cible.fr
# api.cible.fr
# vpn-legacy.cible.fr        <- oublié depuis la migration
# metabase.data.cible.fr     <- n'aurait jamais dû sortir

Le bruteforce DNS pour ce qui n'est publié nulle part

Les sources passives ne voient que ce qui a laissé une trace quelque part. Un sous-domaine interne jamais certifié, jamais indexé, reste invisible pour elles. Là, on passe en actif : on devine. On prend une wordlist de noms courants (dev, staging, vpn, admin, gitlab…) et on teste chaque combinaison en résolvant en masse. Puis on résout la liste complète pour ne garder que ce qui existe vraiment, et on sonde les serveurs web qui répondent.

# Bruteforce DNS : on teste des milliers de noms probables
amass enum -active -brute -w wordlist.txt -d cible.fr

# Résoudre toute la liste : le reste n'est que du bruit
dnsx -l subs.txt -silent -a -resp -o live.txt

# Sonder les serveurs web vivants : statut, techno, titre de page
httpx -l live.txt -sc -title -tech-detect -o web.txt
# https://metabase.data.cible.fr  [200] [Metabase]  <- panel exposé

Les sous-domaines qui pointent dans le vide

En résolvant votre liste, vous tomberez sur des noms dont le CNAME vise une ressource qui n'existe plus : un bucket S3 supprimé, une app Heroku décommissionnée. Ces dangling records dépassent le simple défaut d'hygiène. Quand le fournisseur ne vérifie pas la propriété, un tiers peut réclamer la ressource et servir du contenu sous votre marque, avec un vrai certificat TLS. C'est le subdomain takeover. Une découverte sérieuse liste donc aussi les noms qui ne mènent plus nulle part, ceux dont la ressource cible a disparu.

Remonter par l'ASN et les plages IP

Le DNS n'est qu'un angle. Une organisation qui possède ses propres blocs d'adresses (les grands comptes, les hébergeurs, les opérateurs) annonce ces plages via un numéro d'AS (Autonomous System). Partir de l'ASN, c'est récupérer d'un coup toutes les IP que l'entité route en BGP, y compris celles qu'aucun nom de domaine ne trahit.

# De l'organisation aux plages IP qu'elle possède réellement
asnmap -d cible.fr -silent
asnmap -org "Cible SA" -silent

# Depuis un AS : les préfixes annoncés en BGP (registre de routage RADb)
whois -h whois.radb.net -- '-i origin AS16276' | grep -w route

# Éclater les CIDR en IP pour la suite du pipeline
asnmap -d cible.fr -silent | mapcidr -silent -o ips.txt

Scanner les ports et les services

Une fois qu'on tient des IP et des hôtes vivants, on regarde ce qui écoute. Un nom qui résout ne dit rien du service qui tourne derrière : un 8080 ouvert peut cacher un Jenkins sans auth, un 6379 un Redis exposé en clair. On procède en deux temps : un balayage rapide des ports ouverts (naabu, très véloce), puis une empreinte fine des services trouvés avec nmap, qui identifie versions et bannières.

# Balayage rapide des ports ouverts sur les IP découvertes
naabu -list ips.txt -top-ports 1000 -silent -o ports.txt

# Empreinte fine : versions et bannières des services (nmap)
nmap -sV -sC -p- --min-rate 1000 -iL ips.txt -oA scan-services

# Sur un seul hôte, repérer un service qui traîne
nmap -Pn -sV -p 22,80,443,6379,8080,8443 cible.fr
# 6379/tcp open  redis  Redis key-value store 6.0.16   <- exposé en clair

La bannière de version ment souvent (backport de patchs, header maquillé), mais elle donne le premier tri : en confrontant ces empreintes aux flux de CVE, on fait remonter les expositions connues. La découverte bascule alors dans la gestion de vulnérabilités.

Les actifs cloud : buckets, IP éphémères et SaaS

Le cloud a fait exploser la surface d'attaque, et l'a rendue mouvante. Trois catégories d'actifs échappent systématiquement à l'inventaire classique.

• Les buckets de stockage objet. Un cible-backups sur S3, ouvert en lecture anonyme « le temps d'un test », qui contient des dumps de base. On les déniche par permutation de la marque (cible, cible-prod, cible-assets…) puis on teste l'accès sans credentials.
• Les IP éphémères. Une instance qui boot reçoit une IP publique du pool du fournisseur, la rend en s'éteignant, et cette même IP est réattribuée à quelqu'un d'autre quelques minutes plus tard. Un A record laissé en dur derrière pointe alors vers un serveur qui n'est plus le vôtre. La surface tourne vite.
• Les SaaS branchés par les équipes. Un cible.atlassian.net, un tenant Slack, un Notion public : autant d'actifs qui portent votre marque sans vivre sur votre infrastructure, et que la sécurité découvre souvent le jour de la fuite.

# Deviner et tester des buckets S3 par permutation de la marque
s3scanner scan -f buckets.txt

# À la main : le bucket est-il listable sans credentials ?
aws s3 ls s3://cible-backups --no-sign-request
curl -s https://cible-assets.s3.amazonaws.com/ | head

Le shadow IT, cœur du problème

Le fil rouge de tout ce qui précède, c'est le shadow IT : ces actifs mis en ligne hors de tout processus, par une équipe pressée, et jamais décommissionnés. Le metabase.data.cible.fr du début, l'API de staging poussée « pour deux jours » en 2022, le bucket d'un prestataire parti : aucun ne figure dans la CMDB, tous sont joignables depuis Internet. On détaille ce phénomène, et pourquoi il naît structurellement, dans notre article sur le shadow IT et les actifs exposés que personne ne gère.

La découverte d'actifs n'a de valeur que si elle éclaire ce périmètre gris. Retrouver les serveurs que l'équipe sécurité connaît déjà ne fait avancer personne ; l'enjeu, c'est le jenkins-old que plus personne ne surveille.

La boucle continue : pourquoi c'est le cœur d'un EASM

Voici le piège de tout audit ponctuel. Vous menez cette cartographie un mardi, elle est nickel. Le jeudi, une équipe déploie un nouveau service, un certificat est émis, un sous-domaine apparaît. Votre photo est déjà périmée. Une surface d'attaque externe n'est pas un état, c'est un flux : elle grossit à chaque commit, à chaque campagne marketing qui ouvre un sous-domaine, sans parler des rachats et des environnements de CI/CD qui ne vivent que deux heures.

D'où le mot de boucle plutôt que de scan. On rejoue l'énumération en permanence, on compare à l'état précédent, et on alerte sur les changements : un actif qui apparaît, un port qui s'ouvre, un CNAME qui se met soudain à pointer dans le vide. Ce « continu » sépare un simple outil de recon d'une plateforme de gestion de surface d'attaque externe. La découverte en fournit la matière ; la surveillance dans le temps en fait un dispositif qui tient dans la durée.

À retenir

• La découverte d'actifs part d'une graine (un domaine, une marque) et remonte toute la surface exposée. On procède du passif vers l'actif : sources publiques d'abord (invisibles), trafic vers la cible ensuite (loggable).
• L'énumération de sous-domaines porte l'essentiel : logs Certificate Transparency et crt.sh (subfinder, amass) en passif, bruteforce DNS pour l'invisible, puis résolution (dnsx) et probe HTTP (httpx).
• L'ASN (asnmap, RADb) récupère les plages IP possédées, mais seulement pour les organisations avec leurs propres blocs RIR ; en cloud mutualisé, il ne rattache plus rien.
• Le scan de ports et de services (naabu puis nmap) révèle ce qui écoute vraiment ; les actifs cloud (buckets, IP éphémères, SaaS) échappent presque toujours à l'inventaire.
• Le shadow IT est la vraie cible : ce qu'on cartographie d'utile, c'est ce que personne ne gère. Et comme la surface bouge sans cesse, seule une boucle continue tient le rythme.

Combien de sous-domaines, d'IP et de buckets votre organisation expose-t-elle en ce moment ? Si la réponse tient dans un tableur mis à jour l'an dernier, elle est déjà fausse. Rejouer cette découverte en continu et séparer le vrai risque du bruit de fond, c'est le travail que fait à votre place notre plateforme EASM. On la branche sur vos domaines, elle tient l'inventaire à jour pendant que vos équipes livrent.