Comprendre les prises de contrôle de sous-domaines : Un guide pratique pour les référenceurs

Le détournement de sous-domaine n’est pas un sujet courant dans les discussions sur le référencement, mais il peut avoir un effet direct et préjudiciable sur les classements. Cet article fait part de ma propre expérience en la matière, ainsi que de la procédure que je suis désormais pour vérifier la présence de sous-domaines vulnérables lors des audits techniques.

Un peu d’histoire

Peu de temps après être passé d’un rôle de référenceur général à un poste purement technique, j’ai reçu une notification redoutable dans Search Console :

« Action manuelle appliquée – contenu piraté détecté »

L’URL signalée était une promotion de vacances oubliée hébergée sur christmas.client.co.uk. Mon responsable n’avait aucune idée de ce que c’était, et moi non plus. Après quelques recherches (et un peu de googlage frénétique), j’ai réalisé qu’il s’agissait d’un ancien sous-domaine de campagne laissé à l’abandon. Il avait depuis été réaffecté par quelqu’un d’autre pour diffuser du contenu indésirable.

Heureusement, le client était réactif et techniquement compétent, et nous avons pu résoudre le problème en quelques heures. Mais cet incident m’a fait réfléchir : combien d’autres sous-domaines négligés se cachent-ils sans qu’on s’en aperçoive, prêts à être repris ?

Ce qui s’est passé

Une prise de contrôle de sous-domaine se produit lorsque l’enregistrement DNS pointe vers un service tiers (par exemple, GitHub Pages, Heroku, AWS, etc.) et que ce service n’est plus utilisé, mais que l’entrée DNS existe toujours.

) et que ce service n’est plus utilisé, mais que l’entrée DNS existe toujours. Un attaquant peut revendiquer la ressource abandonnée sur cette plateforme et diffuser instantanément son propre contenu sous votre sous-domaine.

Dans mon cas, l’ancien microsite « calendrier de l’Avent » avait fait l’objet d’une forte promotion des années auparavant. Lorsqu’il a été abandonné, le DNS est resté actif, créant ainsi une opportunité d’exploitation. Le pirate a profité de l’autorité existante du sous-domaine et de ses liens retour pour faire la publicité d’un site de casino.

Cette situation est loin d’être rare. Des incidents similaires ont touché des portails gouvernementaux, de grandes marques et même des sites à forte autorité auxquels les modèles d’IA accordent souvent une confiance aveugle.

Pourquoi les spécialistes du référencement doivent-ils s’en préoccuper ?

On ne vous demande pas d’être un spécialiste de la cybersécurité. Mais les sous-domaines compromis peuvent déclencher des actions manuelles, transmettre l’autorité à des sites malveillants et réduire à néant des mois ou des années de travail d’optimisation. De nombreuses vulnérabilités proviennent de projets anciens dont personne ne se souvient de la mise en place.

Google traite les sous-domaines comme des propriétés distinctes à bien des égards, mais les liens entre eux peuvent toujours transférer de l’autorité. Si un sous-domaine négligé est piraté et que votre site principal y renvoie, vous vous portez garant du contenu de l’attaquant. C’est pourquoi les vérifications périodiques des sous-domaines doivent faire partie de votre routine d’audit technique.

Processus d’investigation

Découvrir les sous-domaines existants

Utilisez des outils tels que ViewDNS ou DNSDumpster. Si un client possède des dizaines ou des centaines de sous-domaines, cela vaut la peine de signaler l’existence potentielle d’actifs anciens ou inutilisés.

Identifier les plateformes d’hébergement

Vérifiez l’hébergement à l’aide d’outils tels que WhatCMS ou la commande « dig » de Google. Évitez également de visiter directement un lien compromis.

Évaluer la vulnérabilité

Comparez les plateformes d’hébergement à des services connus pour leur vulnérabilité, tels que AWS (Elastic Beanstalk/S3), GitHub Pages, Heroku, Shopify, Ghost, Microsoft Azure, Agile CRM, WordPress.com et les services JetBrains. Utilisez ViewDNS pour trouver des sous-domaines, Wappalyzer pour les profiler, et comparez les résultats avec les listes de vulnérabilités disponibles publiquement.

Si vous trouvez un sous-domaine vulnérable

S’il est lié à l’une des plateformes à haut risque et qu’il n’est pas utilisé (ou qu’il est prévu de le fermer), coordonnez-vous avec la personne qui gère les DNS pour supprimer ou repointer l’enregistrement. Bien que les référenceurs ne soient pas directement responsables de la configuration des serveurs, le fait de sensibiliser les parties prenantes aux implications en matière de sécurité et de référencement permet souvent de donner la priorité au problème.

Je ne suis pas un testeur de pénétration – juste un référenceur technique qui a rencontré ce problème suffisamment de fois pour voir la valeur des vérifications proactives. Inclure cette étape dans les audits peut éviter des maux de tête plus tard.

Exemple concret : EY.com

Un exemple récent, partagé par Michael Curtis sur LinkedIn, concernait un sous-domaine EY hébergé via Microsoft Azure. La ressource Azure a été supprimée, mais l’entrée DNS est restée.

Un pirate a enregistré une nouvelle application Azure avec le même nom d’hôte que celui utilisé précédemment par le sous-domaine d’EY. Comme le DNS pointait toujours vers ce sous-domaine, il a pu diffuser du contenu explicite sous le domaine de confiance d’EY.

Il ne s’agit pas d’un « piratage » au sens traditionnel du terme, mais d’une utilisation opportuniste d’entrées DNS abandonnées. L’attaquant n’a pas violé les systèmes internes ; il a simplement revendiqué un nom non protégé et a hérité du trafic et de la confiance qui en découlent.