isMalicious vs SecurityTrails : données de découverte et verdicts de réputation ne sont pas le même produit

SecurityTrails a construit un produit solide autour d'une question précise : à quoi ressemble l'empreinte DNS de ce domaine, aujourd'hui et historiquement ? Découverte de sous-domaines, chronologies de DNS passif, historique WHOIS, énumération de surface d'attaque. Si c'est votre question, il y répond bien.

Cette comparaison revient parce que les données de découverte ne clôturent pas une enquête. Savoir qu'un domaine possède 400 sous-domaines et a changé deux fois de serveurs de noms en 2024 constitue un contexte utile, et ne vous dit pas si l'un de ces éléments est malveillant. Cet écart — entre ce qui existe et ce qui est dangereux — est le point de séparation des deux produits.

Ce que SecurityTrails réussit

• Des enregistrements DNS historiques d'une réelle profondeur, remontant plus loin que la plupart des sources et couvrant les types d'enregistrements de façon assez complète pour la recherche sur longue durée.
• La découverte de sous-domaines à une échelle qui en fait un choix par défaut pour l'énumération de surface d'attaque.
• Le WHOIS et l'historique de domaine, incluant les changements dans le temps et non seulement l'enregistrement courant.
• La cartographie de surface d'attaque, qui agrège les éléments précédents en une vue de l'empreinte externe d'une organisation.

Pour la reconnaissance, la découverte d'actifs et la recherche en DNS passif, il s'agit d'un outil spécialisé qui mérite sa place.

Là où la limite apparaît

Les limites se situent toutes du côté de l'évaluation plutôt que des données :

• Aucun verdict de réputation. SecurityTrails renvoie des enregistrements, non des jugements. Un analyste lisant une chronologie DNS doit encore déterminer si quelque chose y indique une activité malveillante.
• Aucune analyse d'URL pour les logiciels malveillants. Aucun point de terminaison ne récupère une page pour l'évaluer : le triage du phishing exige donc un outil distinct.
• Aucun suivi des groupes de ransomware, si bien qu'un indicateur lié à une campagne d'extorsion n'apporte aucun contexte de ce type.
• Aucune surveillance du dark web pour les signaux d'exposition d'identifiants ou de données.
• Une tarification entreprise depuis le rachat par Recorded Future. L'accès est de plus en plus intégré aux offres d'entreprise de Recorded Future, ce qui modifie le mode d'achat pour les équipes plus petites.
• Aucun calibrage pour l'automatisation des listes de blocage. Le modèle de données sert la recherche, non l'envoi d'infrastructure confirmée malveillante vers les pare-feu et les résolveurs DNS.

Ces deux derniers points motivent généralement la recherche d'alternative. Les équipes quittent rarement SecurityTrails parce que les données DNS les ont déçues ; elles le quittent parce qu'il leur fallait un verdict et un flux d'application, et qu'elles se retrouvaient à négocier un contrat grand compte pour ni l'un ni l'autre.

Ce que fournit isMalicious

isMalicious est construit autour de la question de l'évaluation :

• Des verdicts de réputation multi-sources pour les IP, domaines et URL, avec une classification de menace plutôt que des enregistrements bruts.
• L'analyse d'URL avec suivi de la chaîne de redirection, pour trier un lien signalé plutôt que rechercher l'historique d'un domaine.
• Un renseignement CVE avec les statuts CVSS, EPSS et KEV, qui relie un actif exposé à l'exploitation effective de sa vulnérabilité.
• Le suivi des groupes de ransomware et les signaux d'exposition sur le dark web.
• Des exports de listes de blocage et des collections STIX/TAXII, pour qu'un verdict atteigne les contrôles d'application sans étape d'export sur mesure.
• Une offre gratuite en libre-service et une tarification transparente, pour que l'évaluation n'exige pas un cycle d'achat.

Côté découverte, isMalicious fournit les enregistrements DNS, l'historique DNS, la visibilité des sous-domaines, le WHOIS et l'âge de domaine dans le cadre d'un rapport de menace. Cela couvre les besoins d'enrichissement de la plupart des workflows SOC. Cela n'égale pas SecurityTrails pour les chronologies historiques exhaustives, et si la recherche en DNS passif sur longue durée constitue une part essentielle de votre métier, cette différence est réelle.

Comparaison des fonctionnalités

| Capacité | SecurityTrails | isMalicious | | :--- | :--- | :--- | | Profondeur historique DNS / sous-domaines | Oui, spécialiste | Partielle | | Recherche WHOIS | Oui | Oui | | Verdict de réputation IP | Non | Oui | | Réputation de domaine | Partielle | Oui | | Analyse d'URL | Non | Oui | | Corrélation multi-sources | Non | Oui | | Suivi des groupes de ransomware | Non | Oui | | Renseignement CVE (CVSS, EPSS, KEV) | Partiel | Oui | | Surveillance du dark web | Non | Oui | | Export liste de blocage / STIX-TAXII | Non | Oui | | API en masse | Oui | Oui | | Offre gratuite en libre-service | Non | Oui |

La répartition qui fonctionne en pratique

Plutôt que de remplacer l'un par l'autre, la plupart des workflows mûrs répartissent le travail par question :

1. La découverte d'abord, là où l'étendue compte. Énumérer l'empreinte d'une organisation lors d'un démarrage, d'une acquisition ou d'une évaluation externe est un problème de découverte, et l'outil spécialisé l'emporte.
2. L'évaluation ensuite, sur les résultats. Une fois que vous disposez d'une liste de sous-domaines et de résolutions historiques, la question opérationnelle est de savoir lesquels sont exposés, signalés ou déjà compromis. C'est une question de réputation et de vulnérabilité.
3. L'application en troisième. Ce qui est confirmé malveillant doit atteindre les contrôles qui le bloquent, ce qui suppose un flux plutôt qu'une interface de recherche.

Le mode de défaillance consiste à prendre la première étape pour la totalité du travail. Un rapport de surface d'attaque listant 400 sous-domaines sans évaluation de risque attachée génère du travail au lieu d'en réduire : quelqu'un doit encore vérifier chacun d'eux.

Là où le volume atterrit

Cette étape de vérification explique pourquoi l'enrichissement en masse compte particulièrement ici. L'énumération de sous-domaines sur une organisation de taille moyenne renvoie couramment des centaines de noms d'hôte, et les passer par des recherches unitaires relève exactement du genre de tâche qu'on commence, laisse à moitié faite, puis abandonne.

La recherche en masse accepte directement la sortie de l'énumération — domaines, IP et URL mélangés dans une requête — et renvoie la réputation avec le contexte complet par entrée, ce qui transforme une liste de découverte en liste priorisée. Brancher le même appel dans les workflows SIEM via l'API permet aux évaluations récurrentes de surface d'attaque de produire un différentiel de ce qui a changé et de ce qui est nouvellement signalé, au lieu d'un tableur neuf chaque trimestre.

Pour commencer

Si votre travail relève de la recherche en DNS passif et de l'énumération historique exhaustive, SecurityTrails est le spécialiste et cette comparaison doit vous y renvoyer. S'il vous faut des verdicts, du contexte d'exploitation et un flux que les contrôles d'application peuvent consommer — ou si le conditionnement en offre entreprise est ce qui vous pousse à regarder ailleurs — consultez le face-à-face sur la page de comparaison SecurityTrails.

L'étape suivante concrète consiste à prendre une liste de sous-domaines existante et à la passer par la recherche en masse. La comparaison utile n'est pas un tableau de fonctionnalités ; c'est le nombre d'entrées qui revient avec un verdict attaché, face au nombre qu'il vous resterait à évaluer à la main.