Page d'accueil défigurée : ne pas se contenter de republier

Récit : ce que le client a envoyé à 7 h 12

Capture iPhone, barre d’adresse encore sur le bon domaine, home remplacée par un drapeau, un pseudo, parfois un message politique ou une rançon. Ce n’est pas un cache navigateur. C’est un défacement : l’attaquant veut être vu. C’est utile — il laisse des traces plus grossières qu’une redirection mobile discrète.

Le titulaire, lui, ouvre le site au bureau : parfois il voit encore l’ancienne home (cache CDN, cache plugin, cookie admin). Il répond « chez moi c’est bon ». Le client a raison. On garde la capture, URL, heure. On ne commence pas par Elementor → republier.

Si le message contient une rançon ou des menaces, cette capture est une pièce. Voir message de rançon et preuves. Ne payez rien. Ne répondez pas sur la page.

• Capture horodatée, URL complète.
• Qui voit quoi (admin vs visiteur vs mobile).
• Le texte exact (signature, lien, wallet) recopié à côté.

Ce qu’on a figé avant de toucher à index

Dans ce dossier-là : zip du vhost + dump, email d’aucun abus encore, Search Console encore aux mains du titulaire. On a listé les utilisateurs WP : un `admin` historique, plus un `wpsupport` créé à 3 h 48. On n’a rien supprimé. On a noté.

Côté fichiers : `index.php` à la racine réécrit (signature HTML du groupe), `style.css` du thème enfant avec un commentaire en plus, un `wp-content/uploads/2026/08/x.php`. Dates alignées sur 3 h 40–3 h 55. Ça oriente vers un accès qui écrit plusieurs chemins — admin WP ou FTP, pas seulement « un plugin a planté ».

Sans cette photo, republier la home aurait tout recouvert : dates, HTML de revendication, preuve pour l’assureur. Le titulaire voulait « que ça reparaisse avant 9 h ». On a pris vingt minutes. Ça a évité de tout perdre à 22 h.

Pourquoi republier à 8 h a échoué à 22 h

Le titulaire, avant notre passage, avait collé l’ancienne home dans Elementor et vidé le cache. À 8 h 05 le site « allait bien ». `wpsupport` était toujours là. `x.php` aussi. À 22 h 17, nouvel index, autre message. Classique. Republier le symptôme visible n’invalide pas une session ni un PHP dans uploads.

Le CDN avait même servi l’ancienne home à une partie des visiteurs jusqu’à 10 h, ce qui a donné l’illusion d’un « bug intermittent ». Les captures clients de 7 h et de 22 h étaient la réalité. Le bureau, le cache.

C’est la leçon que le guide site défiguré répète : le critère n’est pas « la page est revenue ». C’est « plus personne d’autre que vous ne peut la modifier ».

Les comptes qu’on a trouvés ensuite

Outre `wpsupport` : un compte FTP `backup` limité à `public_html`, mot de passe identique à l’admin WP de 2019, jamais tourné. Panel intact (chance). Search Console : aucun utilisateur Google ajouté. Donc plutôt FTP + WP que prise du Google Workspace.

On a changé le panel quand même, puis FTP, puis tué les sessions WP (clés AUTH), puis retiré `wpsupport`. L’ordre inverse, vu plus tôt dans la matinée, n’aurait rien tenu. Mots de passe dans cet ordre.

PrestaShop aurait été la même histoire côté Employés. Un défacement « que des fichiers » sans compte fantôme existe (faille d’upload seule). On cherche les deux, toujours.

Fichiers, thème, et options en base

Remettre `index.php` depuis le zip du cœur. Diff du thème enfant, retirer le commentaire et toute URL inconnue. Supprimer `x.php` après copie. Vérifier `.htaccess` (ici, intact — donc pas le vecteur de la home).

En base : `siteurl` / `home` encore corrects. En revanche une option `widget_text` avec un iframe 1×1, et `show_on_front` inchangé. Sans la base, on aurait eu une home fichier propre et un widget qui réinjecte. Les défacements « propres fichiers, sale options » sont fréquents sur les sites dont la home est une page CMS, pas `index.php`.

Cherchez aussi les articles / pages créés à 3 h 50 (souvent vides, ou une page « hacked »). Ils restent dans l’admin et parfois dans `site:`.

• index et front-page du thème.
• uploads PHP.
• mu-plugins.
• options, widgets, page d’accueil assignée.

Republier dans l’ordre, pas « la home d’abord »

Copie → identification entrée (ici : FTP faible + upload PHP, plugin de formulaire obsolète) → retrait portes → secrets → puis home légitime et purge CDN. Inverser, c’est offrir une vitrine propre à quelqu’un qui a encore les clés.

Si vous devez absolument afficher quelque chose avant la fin (événement, presse), une page statique de maintenance factuelle vaut mieux qu’une home CMS encore branchée sur une base non auditée. Voir faut-il couper : pas besoin d’éteindre le domaine.

Après republication : inspection Search Console, `site:`, mobile privée. Un défacement indexé laisse un snippet moche quelques jours. Ce n’est pas une raison de changer de nom de domaine.

La semaine suivante : le vrai test

J+1, J+3, J+7 : dates de fichiers, liste utilisateurs, `site:`. Dans ce dossier, rien. Le plugin formulaire a été retiré, pas seulement « mis à jour plus tard ». Un update tardif aurait laissé la faille ouverte le soir du défacement.

Si la home revient, ce n’est pas « ils ont le serveur ». C’est une porte oubliée : autre PHP, voisin, Application Password, clé SSH. Reprendre la checklist backdoor, pas republier une troisième fois.

Les visiteurs qui ont vu le message : un mot aux interlocuteurs directs suffit en général. Pas un communiqué de crise pour un défacement sans fuite. Prévenir les clients : seulement si données ou paiements.

Ce que ce dossier a coûté d’avoir inversé

Deux heures le matin (republication seule), une soirée de deuxième défacement, un jour de nettoyage réel, des captures clients sur les réseaux. Le coût n’est pas le HTML de la home. C’est l’ordre.

Les dossiers que nous reprenons ont souvent « déjà remis la page » deux ou trois fois. À chaque fois un compte ou un fichier oublié. Ce n’est pas de la malchance. C’est le symptôme traité comme la maladie.

Si vous êtes au matin de la première capture : figez, ne collez pas l’ancienne home tout de suite. Si vous êtes au troisième matin : arrêtez de republier, cherchez l’entrée, ou déléguez.