Découverte d'actifs : ce que les sources passives
trouvent vraiment

Le 22 septembre 2026 au soir, j'ai lancé subfinder sur vulnweb.com, le domaine de test qu'Acunetix publie pour qu'on s'y entraîne. Il a remonté 98 noms d'hôtes. Sept résolvaient encore. Trois ont répondu en HTTP. Voilà, en trois chiffres, ce que donne la découverte d'actifs passive sur un domaine réel : beaucoup d'historique, un peu de surface vivante, et tout le travail consiste à séparer les deux.

Cet article reprend cette mesure source par source, puis la complète par deux autres observations : ce que les journaux de Certificate Transparency révèlent de notre propre domaine, own2pwn.fr, et ce que devient un inventaire quand personne ne le dédoublonne, sur le compte de démonstration de notre EASM.

La méthode, et pourquoi les volumes sont un plancher

Chaque commande a été enregistrée avec son horodatage et sa sortie brute. Les outils : subfinder v2.16.0, dnsx 1.2.3, httpx v1.10.0, et crt.sh interrogé directement. Aucune clé d'API n'était configurée, or 37 des 52 sources de subfinder en exigent une : Shodan, Censys, SecurityTrails, VirusTotal et la plupart des bases de DNS passif ne participaient donc pas. Sur la passe détaillée, 10 sources ont en plus renvoyé une erreur (401, 403, 429, 502, 504, 523 sur un échec DNS, délais dépassés, entre autres), crt.sh compris :

[WRN] Encountered an error with source crtsh: pq: no more connections allowed (max_client_conn)
[WRN] Encountered an error with source netlas: unexpected status code 429 received from https://app.netlas.io/api/domains_count/...
[WRN] Encountered an error with source crtsh: unexpected status code 502 received from https://crt.sh/?q=%.vulnweb.com&output=json
[INF] Found 98 subdomains for vulnweb.com in 30 seconds 8 milliseconds

Les volumes qui suivent sont donc un plancher, et une photo d'une soirée. Ce qui compte ici, c'est la proportion entre historique et surface vivante, et sur cette mesure la source la plus prolifique est aussi celle dont les noms sont le moins souvent vivants.

Ce que chaque source passive apporte vraiment

Subfinder, lancé avec -cs, indique pour chaque nom la liste des sources qui l'ont fourni. Il suffit de compter.

subfinder -d vulnweb.com -all -cs -oJ -v -timeout 30 > vulnweb.jsonl
jq -r '.sources[]' vulnweb.jsonl | sort | uniq -c | sort -rn
#   87 rapiddns
#   14 anubis
#   12 thc
#    7 hudsonrock
#    6 hackertarget
#    5 scanmalware
#    5 commoncrawl

rapiddns fournit à lui seul 87 des 98 noms, dont 77 qu'aucune autre source ne connaît. Sur ces 77, un seul résout : localhost.vulnweb.com, qui pointe vers 127.0.0.1 et n'a pas été sondé. Le reste ressemble à ce qu'on attend d'une base de DNS passif qui enregistre tout ce qu'on lui a demandé un jour : une vingtaine de noms calqués sur la nomenclature d'AWS (ec2-3-138-71-17.us-east-2.compute.vulnweb.com), des variantes qui ont tout d'une faute de frappe (esthtml5, httptestasp, testephp) et même un nom collé à lui-même, testasp.vulnweb.comtestasp.vulnweb.com.

Les petites sources font l'inverse : peu de noms, mais presque tous vivants. hackertarget, scanmalware et commoncrawl n'apportent aucun nom exclusif, et chacun de leurs noms résout. Le signal le plus fiable n'est donc pas la source, c'est la corroboration. Les 6 noms publics qui résolvent ont tous été vus par 5 sources ou plus. Les 4 noms vus par 2 ou 3 sources (virus, viruswall, antivirus1, www.test.php) ne résolvent pas, et des 88 noms vus par une seule source, seul localhost résout. Trier une liste passive par nombre de sources avant de la résoudre, c'est déjà faire une bonne partie du tri.

De 98 noms à 3 serveurs web : l'entonnoir

La résolution se fait avec dnsx, en lui demandant aussi le code de réponse, pour distinguer un nom qui n'existe plus (NXDOMAIN) d'un serveur qui ne répond pas.

dnsx -l vulnweb-hosts.txt -r 1.1.1.1,9.9.9.9 -rcode noerror,nxdomain,servfail,refused -json -silent \
  | jq -r .status_code | sort | uniq -c
#   91 NXDOMAIN
#    7 NOERROR

dnsx -l vulnweb-hosts.txt -r 1.1.1.1,9.9.9.9 -a -json -silent | jq -r '[.host, .a[0]] | @tsv'
# localhost.vulnweb.com    127.0.0.1
# rest.vulnweb.com         18.215.71.186
# testasp.vulnweb.com      44.238.29.244
# testaspnet.vulnweb.com   44.238.29.244
# testphp.vulnweb.com      44.228.249.3
# testhtml5.vulnweb.com    44.228.249.3
# www.vulnweb.com          44.228.249.3

91 noms sur 98, soit 93 %, n'existent plus dans le DNS. Ce n'est pas une défaillance des sources : elles ont vu ces noms à un moment donné, et c'est justement ce qui en fait de bons indices pour un subdomain takeover quand l'enregistrement survit à la ressource. Mais pour dresser l'inventaire de ce qui est exposé aujourd'hui, c'est du passé.

httpx -l cibles.txt -silent -status-code -title -tech-detect -follow-redirects=false -rl 2 -t 2 -json \
  | jq -r '[.url, .status_code, .webserver, .title] | @tsv'
# http://rest.vulnweb.com        200  Apache/2.4.25 (Debian)  Invicti Vulnerable REST API
# http://testasp.vulnweb.com     200  Microsoft-IIS/8.5       acuforum forums
# http://testaspnet.vulnweb.com  200  Microsoft-IIS/8.5       acublog news

httpx a aussi détecté PHP 7.1.26 derrière l'Apache de rest, et ASP.NET 2.0 sur testaspnet. Les trois autres noms, testphp, testhtml5 et www, pointent comme l'apex vers 44.228.249.3, et cette adresse n'a rien répondu ce soir-là, ni au nouvel essai de httpx à 30 s, ni à curl en HTTP comme en HTTPS (000 20.00s rc=28, délai dépassé). Ils ne sont pas morts pour autant : un nom qui résout vers une adresse muette à un instant donné reste un actif à revoir, et ce que Shodan a déjà vu répondre sur cette IP en dit souvent plus qu'un sondage ponctuel.

Certificate Transparency : ce que nos propres certificats disent de nous

Les journaux de Certificate Transparency publient chaque certificat émis par une autorité reconnue. Sur vulnweb.com, crt.sh ne connaît aucun certificat, ce qui colle avec des sites servis en HTTP clair. Le test parlant, c'est notre propre domaine, dont je connais la vérité terrain.

curl -s 'https://crt.sh/?q=%25.own2pwn.fr&output=json' | jq -r '.[].name_value' | sort -u
# analytics.own2pwn.fr
# auth.own2pwn.fr
# easm.own2pwn.fr
# iot.own2pwn.fr
# m1s2.own2pwn.fr
# own2pwn.fr
# secai.own2pwn.fr
# www.iot.own2pwn.fr
# www.m1s2.own2pwn.fr
# www.own2pwn.fr

crt.sh renvoie 108 entrées, qui correspondent à 54 certificats (chacun apparaît deux fois, en précertificat et en certificat final), 10 noms, du 10 décembre 2020 au 7 août 2026. Rien de secret là-dedans, et pourtant plusieurs choses qu'on n'a pas choisi de publier.

Trois leçons, lisibles par n'importe qui. D'abord, la date de lancement de nos produits : les premiers certificats d'auth, easm et secai datent tous du 16 mai 2026. Ensuite, analytics.own2pwn.fr est public depuis le 8 juin 2026, jour de son premier certificat. Un nom d'outil interne ne reste pas discret le temps de le durcir : ce qui est derrière doit tenir seul, authentification comprise, dès la première émission. Enfin, iot et m1s2, deux anciens projets, n'ont plus d'enregistrement A mais figurent toujours dans les journaux, le premier plus de cinq ans après son dernier certificat. Un nom entré dans CT n'en sort jamais.

La quatrième leçon porte sur l'outil lui-même. Les certificats réellement servis ce soir-là ont été récupérés un par un avec openssl s_client : six des sept dataient des 13 et 14 septembre, et aucun de ces six n'apparaissait dans crt.sh, dont le plus récent datait du 7 août. Parmi eux, le tout premier certificat de grc.own2pwn.fr :

## grc.own2pwn.fr A=[164.68.99.194 ]
subject=CN=grc.own2pwn.fr issuer=C=US, O=Let's Encrypt, CN=YE1 serial=… notBefore=Sep 14 16:50:51 2026 GMT …

Huit jours après sa mise en ligne, grc était donc invisible pour qui s'en remet à crt.sh seul. Subfinder l'a pourtant trouvé, par trois autres sources (thc, shodanct et scanmalware). Sur own2pwn.fr, crt.sh reste la source la plus complète avec 9 des 10 noms, dont les deux seuls qu'elle est seule à connaître, iot et www.iot. Il faut les deux : la source historique pour le passé, les autres pour ce qui vient d'arriver.

Le certificat wildcard ne révèle aucun nom

ginandjuice.shop, la boutique de test de PortSwigger, répond bien en HTTPS (200, derrière un équilibreur AWS). Subfinder n'en a pourtant remonté aucun sous-domaine, et crt.sh ne connaît que 11 entrées (6 certificats émis par Amazon entre mars 2022 et novembre 2025) portant deux noms seulement : ginandjuice.shop et *.ginandjuice.shop. Un wildcard publie l'étoile, pas ce qu'elle couvre. Le choix d'un wildcard réduit donc ce que CT dit de vous, au prix d'une clé privée partagée entre tous les services qu'il protège.

Le même domaine montre la limite inverse. L'inventaire que notre EASM a constitué le 16 juillet contient test.ginandjuice.shop, un nom que ni crt.sh ni subfinder n'ont restitué le 22 septembre. Sa provenance est inconnue : ces scans datent d'avant l'enregistrement de la source de découverte par actif. C'est une bonne raison de conserver cette provenance.

Un inventaire gonflé : 2 079 noms sous un seul sous-domaine

Le compte de démonstration de l'EASM d'own2pwn a été peuplé le 16 juillet 2026 par de vrais scans de cibles vulnérables publiées pour ça (vulnweb.com, ginandjuice.shop, OWASP Juice Shop, BrokenCrystals), à partir de cinq domaines déclarés. L'export de ses actifs, relu le 22 septembre, donne ceci.

98 % des sous-domaines de l'inventaire (2 079 sur 2 111) se trouvent sous un seul nom, king.brokencrystals.com, et suivent un motif mécanique :

a1ier52dr97-6-admin.king.brokencrystals.com
a1ier52dr97-6.admin.king.brokencrystals.com
a1ier52dr97-6-api.king.brokencrystals.com
a1ier52dr97-6.api.king.brokencrystals.com
a1ier52dr97-6-dev.king.brokencrystals.com

Un identifiant aléatoire, décliné avec admin, api, dev, internal, en tiret puis en point. On ne sait pas établir d'où ils viennent (DNS wildcard, certificats, DNS passif) : la provenance n'était pas enregistrée à l'époque. En revanche, on sait ce qu'ils coûtent. Un tableau de bord qui affiche 2 267 actifs quand les sous-domaines hors de ce motif ne sont que 32 noie les 41 actifs qui portent réellement un constat. La leçon vaut pour n'importe quel outil, le nôtre compris : un inventaire doit regrouper les noms par motif, tester un libellé aléatoire pour détecter un wildcard DNS avant d'accepter des milliers de noms, et garder la trace de la source de chaque actif.

Reproduire la mesure

Tout tient en quelques commandes, à lancer sur un périmètre autorisé. La seule précaution est de rester lent sur la partie active (ici 2 requêtes par seconde) et de relancer crt.sh quand il répond 502, ce qu'il fait souvent.

# 1. Collecte passive, avec la source de chaque nom
subfinder -d DOMAINE -all -cs -oJ -silent -timeout 30 > passif.jsonl
jq -r .host passif.jsonl | sort -u > hosts.txt

# 2. Ce qui existe encore dans le DNS
dnsx -l hosts.txt -r 1.1.1.1,9.9.9.9 -a -cname -resp -json -silent > dns.jsonl

# 3. Ce qui répond en HTTP, seulement pour les noms qui résolvent vers une IP publique
jq -r 'select(.a and (.has_internal_ips | not)) | .host' dns.jsonl > vivants.txt
httpx -l vivants.txt -silent -status-code -title -tech-detect -rl 2 -t 2 -json > web.jsonl

# 4. Certificate Transparency, en direct
curl -s 'https://crt.sh/?q=%25.DOMAINE&output=json' | jq -r '.[].name_value' | sort -u

Cette mesure ne couvre qu'une partie de la découverte. Elle laisse de côté le bruteforce DNS, qui devine les noms jamais publiés, les plages IP remontées par l'ASN, le scan de ports et la lecture d'une sortie nmap, et les actifs cloud ou SaaS qui portent la marque sans vivre sur l'infrastructure, le terrain habituel du shadow IT. Mais elle suffit à montrer l'ordre de grandeur : sur un domaine ancien, la collecte passive rapporte surtout de l'historique, et la valeur est dans la validation.

Elle montre aussi pourquoi une photo ne suffit pas. Une cartographie faite le 13 septembre n'aurait pas vu grc.own2pwn.fr, et le 22, crt.sh ne l'avait toujours pas indexé. C'est la différence entre un inventaire et une gestion de surface d'attaque externe : rejouer la collecte, résoudre, sonder, et signaler ce qui change. L'EASM own2pwn automatise cette collecte et cette validation sur vos domaines vérifiés, et l'exemple de king.brokencrystals.com rappelle ce qu'on doit lui demander : un inventaire dédoublonné, validé, et dont chaque ligne dit d'où elle vient. Le code source de subfinder, dnsx et httpx est sur le GitHub de ProjectDiscovery.

Questions fréquentes