Mon site est piraté : que faire dans l'heure qui suit

Ce qu’il faut faire dans l’ordre

Quand le site affiche une page inconnue, que Chrome parle de site trompeur, ou qu’un client envoie une capture, l’urgence n’est pas d’« enlever le virus ». Elle est de ne pas détruire ce qui permettra de le trouver. L’ordre utile tient en six gestes : constater, copier, changer le mot de passe d’hébergement, prévenir l’hébergeur, tester comme un visiteur, puis seulement nettoyer ou déléguer.

Cet ordre paraît lent. Il est plus rapide qu’une réinstallation à l’aveugle suivie d’une réinfection le surlendemain. Dans les dossiers que nous reprenons, le temps perdu l’a presque toujours été sur une restauration sale, des fichiers supprimés au hasard, ou un réexamen Google déposé trop tôt.

Si une fausse page bancaire ou un kit d’hameçonnage est en ligne sur votre domaine, c’est l’exception : on coupe cette URL tout de suite (maintenance, retrait du fichier, ou coupure courte du vhost), puis on reprend l’ordre ci-dessous. Pour le reste — redirection, spam SEO, page d’accueil défigurée, alerte antivirus — gardez le site joignable tant que vous pouvez.

• Constater : heure, URL, message, appareil.
• Copier le compte hors du serveur.
• Changer le mot de passe du panel d’hébergement, puis FTP/SFTP.
• Ouvrir un ticket factuel chez l’hébergeur.
• Tester mobile, navigation privée, clic depuis Google.
• Ensuite seulement : nettoyage ou déclaration du dossier.

Noter l’heure et figer ce que vous voyez

Écrivez ce que vous voyez, sur quel appareil, à quelle heure, et l’URL complète. Une redirection qui n’apparaît que sur iPhone, un bandeau Chrome « site trompeur », une home remplacée par un message : chaque détail réduit le temps de recherche du point d’entrée. Prenez des captures avec la barre d’adresse visible. Elles servent à l’assureur, à Google, parfois à la CNIL.

Si un client vous envoie une photo, gardez-la. Vous, derrière un cache d’administrateur ou un réseau de bureau, ne voyez souvent rien. Ce décalage n’est pas « ça s’est arrangé » : c’est le fonctionnement normal d’une infection conditionnelle (mobile, Google, pays).

Notez aussi les emails : abus de l’hébergeur, Search Console, prestataire de paiement. Le motif d’un ticket OVH ou o2switch (« malware », « phishing », « resource abuse ») décide de l’ordre. Un compte coupé pour minage ne se traite pas comme un compte coupé pour une page d’hameçonnage. Le guide des premiers gestes reprend cette checklist en version courte.

Copier le site en l’état, même infecté

Cette copie est votre preuve et votre filet. Elle permet de comparer, de retrouver un contenu supprimé par erreur, et d’établir la chronologie. Sans elle, on nettoie à l’aveugle. Stockez-la ailleurs que sur l’hébergement concerné : un zip dans le même compte se corrompt avec le reste, ou part avec un rançongiciel.

Si le FTP est déjà coupé, demandez une archive au support. Traitez-la comme un état des lieux, pas comme une source de restauration. Remettre cette archive telle quelle replace le site à l’heure de la suspension, infection comprise.

Les journaux partent dans le même sac : accès, erreurs PHP, FTP, file d’envoi mail. Réinstaller « pour se rassurer » les détruit. C’est ainsi que des dossiers simples deviennent impossibles à dater — y compris pour une éventuelle fuite de données.

Changer les bons mots de passe

L’ordre compte. Hébergement (panel) d’abord, puis FTP/SFTP ou SSH, puis administration du CMS, puis base de données, puis boîtes utilisées par le site (SMTP, newsletter). Inverser laisse une session ouverte : quelqu’un recrée le fichier que vous venez de retirer.

Un mot de passe WordPress changé pendant que le panel o2switch est encore l’ancien, c’est un théâtre. L’attaquant réécrit wp-config ou pose un mu-plugin. Distinguez aussi les mots de passe d’application WordPress : ils survivent au mot de passe principal.

Si vous partagez le même secret partout (panel = admin = messagerie), partez du principe que tout a été lu. Trois secrets distincts au minimum, stockés dans un gestionnaire, pas dans un email à l’agence.

• Panel d’hébergement et utilisateurs FTP ajoutés.
• Admin CMS + sessions (clés AUTH WordPress si besoin).
• Base MySQL et .env / wp-config.
• SMTP, Brevo, Stripe, Search Console : révoquer les clés inconnues.

Prévenir l’hébergeur sans demander « rouvrez »

Annoncez qu’une intervention est en cours et demandez les journaux, pas la réouverture immédiate. Un ticket factuel (référence d’abus, ce que vous voyez, que vous ne rouvrez pas à la main) évite une suspension automatique au moment où vous avez le plus besoin du FTP.

Si le site est déjà suspendu, lisez le motif. L’hébergeur attend une preuve que la cause est traitée. « C’est nettoyé » ne suffit presque jamais. Le constat — trouvé, retiré, corrigé — est précisément le document de la page compte suspendu par l’hébergeur.

Si la messagerie du domaine est coupée avec le site, indiquez une adresse personnelle dès le premier message. Sinon vous ne verrez jamais la réponse. C’est le piège le plus fréquent des suspensions OVH, LWS ou mutualisé générique.

Vérifier ce que voient vraiment les visiteurs

Ouvrez le site depuis un téléphone, en navigation privée, et depuis un résultat Google plutôt qu’en tapant l’adresse. Beaucoup d’attaques ne se déclenchent que dans ces conditions. Regardez aussi `site:votre-domaine.fr` : des titres en japonais ou des pharmacies signalent une infection déjà indexée.

Le cadenas HTTPS vert ne dit rien. Chrome peut afficher « site trompeur » avec un certificat valide : Safe Browsing classe le contenu, pas le chiffrement. Renouveler Let’s Encrypt pendant que le shell tourne est une journée perdue. Voir alerte site trompeur.

Si Search Console est ouverte, lancez une inspection d’URL. Un HTML différent du vôtre est une preuve de cloaking, pas un bug. Gardez ce HTML : il sert au réexamen et au constat.

Les cinq gestes qui aggravent

Supprimer des fichiers au hasard casse l’affichage sans fermer l’entrée : beaucoup de fichiers infectés sont aussi nécessaires au CMS. Restaurer une sauvegarde ancienne sans la lire relance souvent l’attaque. Réinstaller WordPress par-dessus laisse la porte (mu-plugin, cron, voisin de compte).

Demander un réexamen Google avant que le site soit propre enregistre un refus. Le délai suivant est plus long que le premier. Changer d’hébergeur avec un site encore sale déplace le problème et brûle parfois le nouveau compte en 24 heures.

Payer une rançon n’obtient souvent ni clé ni silence. Recréer un nom de domaine « pour repartir à zéro » perd l’historique SEO et n’empêche pas l’attaquant de recommencer. Ces deux réflexes sont détaillés dans pourquoi ne pas payer une rançon et changer de domaine après un piratage.

• Pas de suppression au jugé dans le FTP.
• Pas de restauration « dernière sauvegarde » sans ouvrir l’archive.
• Pas de réexamen Safe Browsing le jour même si des URL sales répondent encore 200.
• Pas de migration sale.
• Pas de plugin cleaner comme seul traitement.

Décider : continuer seul ou déléguer

Si vous savez comparer un fichier à son zip d’origine, lire un access.log et distinguer un thème enfant d’un payload, un nettoyage manuel est possible. Sinon, le risque est de retirer les symptômes — home propre, backdoor encore là — et de revivre la même scène. C’est la majorité des seconds appels.

Déléguez aussi dès qu’une boutique (checkout, cartes) ou une base clients entre en jeu : le coût d’une erreur dépasse celui d’une intervention. Un prestataire sérieux demande un accès révocable, fournit un écrit, et ne prétend pas « s’occuper de la CNIL à votre place ».

Vous pouvez créer un espace sans fournir d’accès serveur. Le prix s’affiche avant validation. En attendant, ne restez pas inactif : copie, panel, ticket, tests visiteurs. Ces quatre gestes ne cassent rien et raccourcissent le dossier, que vous continuiez seul ou non.