Comment savoir si votre site a vraiment été piraté

Croiser au moins deux canaux

La question « comment savoir si mon site est piraté » n’a pas de test unique. Un plugin de sécurité qui liste cinquante fichiers, un bandeau Chrome, un client qui envoie une capture : chacun oriente, aucun ne clôt. On confirme quand deux canaux racontent la même histoire — par exemple des titres étrangers dans `site:votre-domaine.fr` et un PHP inconnu à la racine, daté d’hier.

L’erreur fréquente est de conclure trop tôt dans un sens ou dans l’autre. « Wordfence est vert » ne dit rien d’une redirection mobile. « Le site s’affiche chez moi » ne dit rien d’un cloaking qui ne se déclenche que pour Googlebot. Inversement, une erreur 500 après une mise à jour n’est pas un piratage tant que rien d’autre ne l’accompagne.

Donnez-vous vingt à quarante minutes, pas une après-midi. Notez l’heure, l’URL exacte, l’appareil, le message. Puis enchaînez les quatre contrôles ci-dessous. Si deux sont positifs, traitez comme un incident. Si un seul l’est, creusez ce canal avant de réinstaller quoi que ce soit.

• Google : `site:` + Search Console (sécurité et inspection d’URL).
• Navigateur : alerte, redirection, pop-up — depuis un téléphone et en navigation privée.
• Administration : utilisateurs inconnus, extensions ajoutées, options de site.
• Serveur : PHP isolés à la racine, `.htaccess` retouché, dates anormales.

Ce que Google affiche déjà

Tapez `site:votre-domaine.fr` depuis un navigateur où vous n’êtes pas connecté au site. Comparez le nombre de résultats à votre vrai plan de site. Des titres en japonais, des pharmacies, des URL à paramètres que vous n’avez jamais créées : l’infection est déjà indexée. Ce n’est pas un « bug de Google », c’est du contenu servi à un robot.

Ouvrez Search Console s’elle existe encore. L’onglet Sécurité liste hameçonnage, logiciels indésirables, contenu socialement ingénieux. Une inspection d’URL sur la home montre le HTML que Googlebot télécharge. S’il diffère de ce que vous voyez, vous avez du cloaking — la preuve la plus nette qu’on puisse obtenir sans ouvrir le FTP.

Gardez une capture des résultats et le HTML « vu par Google ». Ils serviront au constat, à l’assureur, et plus tard au réexamen Safe Browsing. Si Search Console n’est plus à vous (email admin changé), c’est déjà un signe : quelqu’un a touché les comptes.

Ce que le navigateur dit (et ne dit pas)

Chrome « site trompeur », Firefox qui bloque, un antivirus d’entreprise : ce sont des listes, pas un diagnostic de fichier. Elles disent que quelqu’un a signalé votre domaine, ou qu’un crawler a vu une URL sale. Elles ne disent pas où est le script. Traitez l’alerte comme un symptôme à croiser, pas comme une preuve suffisante ni comme une panique à elle seule.

Le cadenas HTTPS vert ne rassure de rien. Un site d’hameçonnage a souvent un certificat Let’s Encrypt valide. Inversement, un certificat expiré fait peur aux visiteurs sans qu’il y ait eu intrusion. Ne renouvelez pas le certificat pour « enlever l’alerte » : vous perdez une journée.

Si seul votre réseau de bureau bloque le site, testez depuis un téléphone en 4G. Un filtre d’entreprise ou un cache DNS local imite parfois une blacklist. Si le téléphone voit la même alerte, le signalement est public.

Comptes et fichiers qui n’ont rien à faire là

Dans l’administration WordPress : Utilisateurs, triés par date d’inscription. Un `admin1882`, un email `@yandex` ou `@mail.ru`, un compte avec le rôle administrateur que personne de l’équipe ne reconnaît. Sur PrestaShop : Employés, pas Clients. Notez-les, ne les supprimez pas encore : la date et l’email figurent au constat.

Sur le serveur, via le gestionnaire de fichiers ou le FTP : fichiers PHP isolés à la racine (`wp-core.php`, `radio.php`, `images.php`, un nom de huit caractères aléatoires). Dossiers avec une date de modification d’hier alors que personne n’a travaillé. Un `index.php` de 80 Ko alors que le cœur WordPress en fait 2. Un `.htaccess` qui contient un `RewriteRule` vers un domaine que vous ne connaissez pas.

Les uploads (`wp-content/uploads`, `img/`, `upload/`) ne doivent pas contenir de `.php`. Une double extension (`facture.pdf.php`) est un classique. Si vous n’avez plus accès à wp-admin, passez par phpMyAdmin ou le panel : la table `wp_users` se lit sans le back-office.

• Utilisateurs / employés créés après la dernière intervention connue.
• PHP à la racine hors `index.php`, `wp-config.php`, `xmlrpc.php`.
• PHP dans les dossiers d’images.
• `.htaccess` ou `web.config` modifié sans vous.

Les symptômes que vous ne voyez pas depuis votre bureau

Vous êtes souvent connecté, en desktop, parfois derrière le cache d’un plugin de performance ou d’un CDN qui vous sert une version « admin ». Le script pirate filtre le user-agent, le referer, le pays, ou un cookie de session. Résultat : le site est normal chez vous, et un client sur iPhone atterrit sur un jeu ou un faux support.

Trois tests avant de conclure que « ça s’est arrangé » : navigation privée, téléphone en données mobiles, clic depuis un résultat Google plutôt que l’URL tapée dans la barre. Si l’un des trois diverge, vous avez une infection conditionnelle. C’est le cas le plus fréquent derrière « comment savoir si mon site est piraté ».

Demandez une capture à la personne qui vous a alerté, barre d’adresse visible. Votre propre écran ne remplace pas le sien. Le détail est développé dans le site marche chez vous, pas chez les visiteurs.

Dates de modification et journaux

Dans le gestionnaire de fichiers, triez par date de modification. Un thème enfant retouché à 3 h 12, un `wp-includes` touché alors que vous n’avez pas mis à jour le cœur : ce n’est pas une « synchro ». Notez les chemins. Ne les effacez pas au jugé : beaucoup de fichiers infectés sont aussi nécessaires au CMS.

Les journaux d’accès et d’erreurs PHP (cPanel, Plesk, ovh, o2switch : souvent `logs/` ou l’onglet Statistiques) montrent le premier hit vers le fichier fautif et parfois l’IP d’admin. Un 500 qui pointe `eval` ou un chemin dans `uploads` oriente vers une infection, pas vers une panne de mémoire.

Si les logs tournent sur 24 heures seulement, copiez-les maintenant. Réinstaller « pour voir » les détruit. Sans eux, on perd la chronologie — y compris pour une éventuelle fuite.

Quand ce n’est probablement pas un piratage

Une page blanche ou une 500 dans l’heure qui suit une mise à jour d’extension, sans autre signe : commencez par le journal PHP, pas par un « cleaner ». Un certificat expiré, un quota disque plein, une base saturée, un plugin de cache mal vidé après migration : la liste des fausses alertes est longue.

Un email « votre site a un virus » qui demande d’appeler un numéro ou d’installer un logiciel n’est pas un diagnostic. C’est souvent de l’arnaque au faux support, parfois servi… depuis un vrai site piraté, le vôtre ou un autre.

En revanche, ne rangez pas trop vite un incident dans « panne » si un client a vu une redirection, si `site:` a changé, ou si l’hébergeur a nommé un fichier. Ces trois éléments pèsent plus qu’un scan local vert.

Arbre de décision en cinq questions

Répondez dans l’ordre, sans sauter. 1) Un tiers (client, Chrome, hébergeur, Google) voit quelque chose que vous ne voyez pas ? 2) `site:` ou Search Console montre des URL ou un HTML étrangers ? 3) Un compte admin / employé ou un PHP à la racine est inexpliqué ? 4) Un fichier légitime a une date de modification sans intervention ? 5) L’hébergeur a cité un chemin ?

Deux « oui » ou plus : traitez comme un piratage. Un seul « oui » : creusez ce canal (reproduire, lire le log, comparer le fichier à l’original) avant de conclure. Zéro « oui » et une 500 après update : panne plutôt qu’infection.

Cet arbre évite les deux extrêmes : tout réinstaller pour une notice PHP, et « attendre que ça passe » alors que Google indexe déjà des pharmacies.

Ce que vous figez avant de toucher

Captures horodatées (URL visible), copie du compte hors serveur, liste des utilisateurs, extrait des logs. Ensuite seulement : mots de passe du panel, ticket hébergeur, nettoyage. Inverser, c’est effacer la preuve que vous cherchiez.

Si le diagnostic est positif, l’ordre des premiers gestes s’applique : constater, copier, changer le panel, prévenir, tester comme un visiteur. Pas de plugin cleaner, pas de restauration « dernière sauvegarde » sans l’ouvrir.

Vous pouvez déclarer le dossier sans fournir d’accès tout de suite. En attendant, les quatre contrôles ci-dessus tiennent en une heure et ne cassent rien.