Un sous-domaine oublié (dev, old, backup) est le vrai site pirate

Le www propre n’est pas un diagnostic

Vous ouvrez https://www.votre-domaine.fr, la vitrine est là, le cadenas est vert. Un client, lui, a cliqué un lien old.votre-domaine.fr/wp-login.php ou a vu une alerte Chrome sur backup.votre-domaine.fr. Vous répondez « chez moi ça marche ». Les deux avez raison. Vous n’avez pas regardé le même hôte.

Les bots et Google, eux, suivent tout ce que le DNS publie. Un A record oublié vers le même serveur, un CNAME vers un ancien hébergeur, un vhost « par défaut » : c’est un site. S’il tourne un WordPress 5.8 avec un formulaire vulnérable, il n’a pas besoin de votre permission pour servir un kit ou du spam SEO.

Dans les dossiers que nous reprenons, le motif n°1 de « on a nettoyé, ça revient » n’est pas toujours un backdoor sur www. C’est old. ou staging. encore ouvert, même panel, mêmes identifiants FTP. L’attaquant réécrit un fichier sur www depuis le voisin. Wordfence sur la prod ne lit pas l’autre document root.

• Tester `site:votre-domaine.fr` et comparer à `site:www.votre-domaine.fr`.
• Ouvrir le DNS : tous les A, AAAA, CNAME, pas seulement www.
• Ouvrir le panel : domaines, sous-domaines, addon, parked.

Où ces sous-domaines survivent

Chez l’hébergeur mutualisé (o2switch, OVH, LWS, PlanetHoster), créer un sous-domaine est un clic. Le supprimer du marketing n’efface ni le DNS ni le dossier. On « bascule en www » en 2019, old. reste. Le certificat Let’s Encrypt se renouvelle tout seul. Personne ne s’y connecte. Les bots, si.

Deuxième lieu : un ancien prestataire. Le CNAME staging.domaine.fr pointe encore vers un VPS ou un Netlify oublié. Vous n’avez plus le mot de passe. Le site y est, parfois une copie de la base clients. Ce n’est plus « votre » FTP, c’est encore votre nom.

Troisième lieu : le mail. webmail., mail., autoconfig. sont parfois de vrais vhosts avec une interface web. Moins souvent un WordPress, plus souvent une page par défaut ou un Roundcube exposé. Ce n’est pas le sujet le plus fréquent en phishing, mais ça entre dans l’inventaire.

Les noms qui reviennent (dev, old, backup, shop)

dev. et staging. : copies de prod, debug allumé, plugins d’import encore là. old. et backup. : archives « au cas où » après une refonte, souvent plus vulnérables que la prod. shop. ou boutique. : un WooCommerce ou un Presta à côté de la vitrine, mal mis à jour. www2. : bascule avortée.

test., demo., preprod., recette. : mêmes risques, parfois un jeu de données réel (commandes, patients). new. : la refonte en cours, admin/admin. blog. : un WordPress distinct, thème nulled, jamais dans le contrat de maintenance.

Les inventions de l’attaquant (secure., login., update.) ne sont « oubliées » que si un wildcard DNS les fait résoudre. Sans wildcard, ces noms exigent un enregistrement. S’ils résolvent, quelqu’un les a créés — vous, une agence, ou quelqu’un qui avait le DNS. Voir wildcard et générateur.

• dev, staging, preprod, recette, test, demo.
• old, backup, archive, www2, new.
• shop, boutique, booking, resa, blog, shop2.

Inventaire : DNS, panel, Search Console

Le DNS est la source. Exportez la zone. Tout hostname avec un A, AAAA ou CNAME est un candidat. Les MX et TXT ne servent pas de site web, mais un CNAME « www » mal compris peut cacher un second A sur le nu. Notez aussi les nameservers : si une partie de la zone est chez Cloudflare et l’autre chez OVH, vous avez deux endroits à lire.

Le panel liste les vhosts et les document roots. Un sous-domaine peut pointer vers le même dossier que www (alors une infection est partagée) ou vers un dossier cousin. Les deux cas se traitent différemment. Un addon domain (autre nom) n’est pas un sous-domaine : autre article, même réflexe d’inventaire — domaine stationné.

Search Console, propriété domaine, plus `site:`. Les titres étrangers, les URL /wp-content/ sur un hôte que vous ne gérez plus, les sitemaps inconnus : c’est la liste de fermeture. Inspectez ces URL. Un 200 sur old. avec un HTML qui n’est pas le vôtre suffit à tenir une alerte Safe Browsing sur le nom entier, pas seulement sur old.

Fermer, isoler ou nettoyer

Si plus personne ne s’en sert : retirez l’enregistrement DNS, retirez le vhost, retirez le document root après archive. Dans cet ordre. Un vhost qui reste avec un dossier vide peut encore répondre 200 sur une page par défaut. Un DNS qui reste envoie les visiteurs chez un voisin ou un parking.

Si c’est une préprod encore utile : mot de passe HTTP (htpasswd) ou VPN, pas d’indexation (robots + noindex), même niveau de correctifs que la prod, comptes distincts. « On mettra le mot de passe lundi » est le scénario que nous retrouvons le lundi suivant, kit en ligne.

Si c’est un vrai site (boutique, blog) : on le nettoie comme la prod. Même protocole WordPress piraté : copie, panel, utilisateurs, mu-plugins, uploads. Puis on décide s’il doit rester un sous-domaine ou fusionner. Ne « redirigez » pas un hostname de phishing vers www : 410 sur ce hostname, ou extinction DNS.

• Inutile : DNS off, vhost off, dossier archivé hors serveur.
• Préprod : authentification, noindex, correctifs, comptes à part.
• Métier : nettoyage complet, puis 410 sur les chemins de kit.

Index et Safe Browsing sur un hostname oublié

Safe Browsing classe souvent le hostname, parfois le chemin, parfois le domaine entier. Un kit sur old. peut faire afficher « site trompeur » sur www. Ce n’est pas Google qui « se trompe de site » : c’est le même nom aux yeux d’une partie des listes. D’où l’intérêt de tuer old. vraiment, pas de le cacher.

Pour l’index, `site:old.domaine.fr` doit tendre vers zéro après 410 ou après disparition DNS. Un 301 de old. vers www envoie les URL spam dans l’index de la prod. Encore une fois : on ne range pas, on tue. Le guide pages spam s’applique hostname par hostname.

Le réexamen se dépose quand les inspections des hôtes concernés sont propres. Si vous n’avez que le préfixe www, vous ne voyez pas old. Ajoutez la propriété domaine ou un préfixe pour old. — le temps d’un incident, ce n’est pas du luxe.

Le même compte, le même mot de passe

old. et www sur le même utilisateur FTP, c’est un seul secret. Le changer sur wp-admin de la prod ne suffit pas. Panel d’abord, puis FTP, puis chaque admin CMS. Les mots de passe d’application de old. survivent aussi.

Les cron du panel (sauvegarde old. vers www, rsync « pour la préprod ») recopient l’infection. Lisez les tâches. Un rsync inverse (prod vers old.) après nettoyage de www réinfecte old. ; l’inverse aussi. Notez le sens avant d’éteindre.

Si old. est chez un autre hébergeur, vous avez deux tickets, deux copies, deux jeux de mots de passe. Ne migrez pas old. « pour simplifier » tant qu’il est sale : vous offrez un second compte à suspendre. Voir compte suspendu.

Après : ne plus jamais « laisser tourner »

Une fois par trimestre : export de zone DNS, liste des vhosts, `site:domaine.fr`. Tout hostname sans propriétaire nommé se ferme. C’est plus court qu’un second incident.

Interdisez la création de sous-domaines « pour tester » sans date de fin et sans htpasswd. L’agence qui pose recette. pour un sprint et part doit avoir un ticket de fermeture, comme un compte admin.

Si l’inventaire vous dépasse (vingt CNAME, trois prestataires, un wildcard), déclarez le site. On commence par la carte des hôtes, pas par un scan de la home. Les premiers gestes restent : constater, copier, panel — sur chaque hostname utile, pas seulement sur www.