Recherche IP inverse : pivoter sur l'infrastructure sans se noyer dans l'hébergement partagé

Une recherche IP inverse répond à une question simple : qu'est-ce qui réside par ailleurs à cette adresse ? C'est l'un des pivots les plus productifs disponibles pendant une enquête, et l'un des plus faciles à mal employer. Appliquez-le à un serveur dédié faisant tourner trois kits de phishing et vous avez trouvé une campagne. Appliquez-le à une IP d'hébergement partagé et vous avez trouvé quatre mille sites de petites entreprises, dont trois sont compromis et aucun n'a de rapport avec les autres.

La technique n'est pas la partie difficile. Savoir quand le résultat signifie quelque chose, oui.

Ce que renvoie réellement la recherche

Une requête DNS ordinaire résout un domaine vers une adresse. Une recherche IP inverse renverse l'opération : à partir d'une adresse, elle renvoie les domaines connus pour y résoudre. Les bonnes implémentations renvoient deux ensembles plutôt qu'un :

• Les résolutions actuelles — les domaines pointant vers l'adresse maintenant.
• Les résolutions historiques — les domaines qui y pointaient auparavant et ont depuis déménagé.

L'ensemble historique est fréquemment le plus intéressant des deux en réponse à incident. Les attaquants font tourner leur infrastructure, et un domaine qui résolvait vers une adresse connue comme malveillante il y a trois semaines constitue une preuve, même s'il résout aujourd'hui vers quelque chose d'anodin. Travailler uniquement sur les résolutions actuelles, c'est voir la position présente de l'attaquant et rien de son historique.

Le problème de l'hébergement partagé

C'est le piège qui pousse à se méfier de la technique : il mérite d'être décrit avec précision.

Les serveurs d'hébergement partagé hébergent couramment des milliers de domaines sans lien entre eux sur une seule adresse IP. Les réseaux de diffusion de contenu font pire : une seule adresse de périphérie peut servir des millions de domaines locataires. Dans les deux cas, le fait que votre domaine suspect partage une IP avec un domaine connu comme malveillant ne porte pratiquement aucune information. Ils partagent un propriétaire, pas une complicité.

Deux heuristiques séparent le signal du bruit :

• Le nombre de voisins. Une population réduite implique un hébergement dédié ou semi-dédié, où la co-localisation est un choix délibéré d'un opérateur. Une population importante implique une infrastructure partagée, où la co-localisation est un accident de provisionnement. Le seuil est flou, mais la différence entre cinq voisins et cinq mille ne l'est pas.
• La proportion de malveillants, pas leur nombre. Trois domaines signalés sur cinq forment une grappe. Trois domaines signalés sur quatre mille correspondent à un hébergement partagé statistiquement ordinaire. Le nombre seul vous égarera ; c'est la proportion qui compte.

Combinez les deux et l'interprétation est généralement sans ambiguïté. Faible nombre et forte proportion signifient une infrastructure dédiée d'attaquant, et toute la liste des voisins mérite attention. Nombre élevé et faible proportion signifient que vous n'avez rien appris sur votre domaine et qu'il faut pivoter autrement.

Quand arrêter de pivoter

Certaines configurations d'hébergement rendent la recherche IP inverse structurellement non informative. Les reconnaître tôt épargne une heure de poursuite inutile :

• Les adresses de périphérie de CDN. La recherche inverse renvoie la liste des locataires du CDN. Cela vous apprend que le domaine utilise un CDN et rien sur qui l'exploite.
• Les répartiteurs de charge cloud et les entrées partagées. Même problème : l'adresse appartient à la couche frontale du fournisseur, pas au locataire.
• Les pages de stationnement et de bureau d'enregistrement. De grands nombres de domaines sans lien résolvent par défaut vers une infrastructure de stationnement. Une co-localisation à cet endroit signifie « les deux sont inutilisés », ce qui est parfois intéressant et rarement concluant.
• Les puits de collecte (sinkholes). Les domaines pointés vers une adresse de sinkhole sont regroupés par celui qui pratique le sinkholing, non par leur opérateur. Une IP de sinkhole avec des centaines de voisins malveillants est un artefact de recherche, pas une campagne.

Dans chacun de ces cas, le mouvement productif consiste à pivoter sur quelque chose que l'opérateur contrôle : serveurs de noms, détails du certificat TLS, ou historique DNS montrant où le domaine résolvait avant de passer derrière une infrastructure partagée.

Là où la recherche IP inverse fait la différence

Mettez de côté les cas d'hébergement partagé et la technique se révèle réellement solide dans plusieurs situations récurrentes.

Étendre une campagne de phishing depuis une seule URL signalée

Les utilisateurs signalent un lien. Le domaine résout vers une adresse hébergeant une poignée d'autres domaines, dont plusieurs sont également des sosies de marque enregistrés dans la même fenêtre. Vous disposez maintenant de la campagne et non d'une de ses instances, ce qui change à la fois la demande de retrait et le périmètre de la notification aux utilisateurs.

Trouver les frères et sœurs d'une infrastructure C2

Les serveurs de commande et de contrôle sont souvent provisionnés par petits lots sur le même hébergement. Une recherche inverse sur une adresse C2 confirmée, filtrée sur les faibles nombres de voisins, fait fréquemment apparaître les autres nœuds de l'opérateur avant que ceux-ci ne figurent dans un flux. Ce sont les adresses qu'il vaut la peine de bloquer par anticipation.

Évaluer la réputation d'hébergement d'un domaine inconnu

Parfois, les voisins constituent le verdict. Un domaine sans historique propre, hébergé sur une adresse où la plupart des domaines co-localisés sont signalés, justifie raisonnablement une escalade même sans preuve directe à son encontre. C'est le seul cas où une forte proportion de malveillants sur une adresse moyennement peuplée fait l'essentiel du travail analytique.

Établir le périmètre rétrospectif d'une intrusion

Une fois que vous détenez une adresse contrôlée par l'attaquant, la recherche IP inverse historique montre quels autres domaines l'utilisaient pendant la fenêtre d'intrusion. Ces domaines ont leur place dans vos requêtes de journaux même s'ils résolvent ailleurs aujourd'hui — et ils expliquent fréquemment un trafic qui semblait alors sans rapport.

Cartographier sa propre exposition

Tournée vers l'intérieur, la même recherche montre lesquels de vos propres domaines partagent un hébergement, ce qui fait parfois apparaître des sites de préproduction oubliés, des micro-sites marketing expirés et des propriétés gérées par des tiers que personne n'a inventoriées. Hébergement partagé signifie rayon d'impact partagé.

Un workflow de pivot qui tient

1. Partez d'un indicateur confirmé, non d'un soupçon. Pivoter depuis un domaine non vérifié multiplie l'incertitude au lieu de la résoudre.
2. Résolvez-le et vérifiez d'abord le type d'hébergement. Si l'adresse appartient à un CDN ou à une grande couche frontale cloud, arrêtez et pivotez ailleurs.
3. Récupérez la liste des voisins, actuelle et historique. Notez la taille de la population avant de lire une seule entrée.
4. Calculez la proportion de malveillants plutôt que de chercher des noms familiers. La proportion avant le nombre, à chaque fois.
5. Filtrez vers le sous-ensemble plausible — enregistré dans une fenêtre voisine, schéma de nommage similaire, choix de TLD comparable, mêmes serveurs de noms.
6. Vérifiez chaque candidat indépendamment. Le co-hébergement est une raison de regarder, jamais un verdict en soi. Confirmez avec la réputation de domaine et, lorsque la page résout encore, une analyse d'URL.
7. Réinjectez ce que vous confirmez dans vos contrôles, et conservez l'ensemble non confirmé comme contexte de recherche plutôt que comme entrée de blocage.

L'étape six est celle où la plupart des enquêtes par IP inverse déraillent. Bloquer une liste entière de voisins parce que deux de ses membres étaient malveillants, c'est ainsi qu'une équipe de sécurité met hors ligne le site d'un client.

À l'échelle d'une enquête

La recherche IP inverse d'isMalicious renvoie ensemble les domaines résolvant actuellement et ceux qui pointaient auparavant vers l'adresse, signale si celle-ci ressemble à un hébergement partagé et attache le statut de menace des domaines co-hébergés — ce qui rend possible le jugement sur la proportion de malveillants sans exporter une liste de domaines pour l'enrichir ailleurs.

Associez-la à la réputation IP pour le verdict d'hébergement et au contexte ASN pour voir si tout le bloc réseau possède un historique, car certains fournisseurs concentrent les abus au niveau de l'ASN d'une manière que les recherches d'adresses individuelles sous-estiment. Lorsqu'un pivot produit une longue liste de candidats, la recherche en masse vérifie l'ensemble en une requête plutôt qu'un par un, et l'API place le même pivot à l'intérieur d'un SIEM ou d'un playbook SOAR, de sorte qu'une adresse figurant dans une alerte arrive avec ses voisins déjà évalués.

Employée avec les vérifications de population et de proportion en place, la recherche IP inverse est l'un des pivots les plus rentables de la boîte à outils d'un analyste. Employée sans elles, c'est un générateur fiable de faux positifs assénés avec assurance.