WordPress piraté ? La checklist de ce qu'aucun scanner ne peut voir
Votre site a été piraté, les journaux montrent que les modifications ont été faites depuis votre propre compte — parfois depuis votre propre adresse IP — et le scan de sécurité ne trouve rien. Cette combinaison signifie généralement que l'entrée ne s'est pas faite par le serveur. Tous les scanners et outils de surveillance qui examinent le site, Relvato compris, voient ce qui se trouve sur le serveur et ce qu'affichent les pages. Or les attaquants entrent de plus en plus par des endroits situés ailleurs : le navigateur d'un administrateur, son ordinateur, ou les comptes autour du site. Cette checklist passe ces endroits en revue, dans l'ordre où il faut les verrouiller. Pour les endroits où le malware se cache sur le serveur lui-même, voyez où se cache le malware WordPress.
Pourquoi un scan propre ne veut pas dire un site propre
Une extension de sécurité, un contrôle d'intégrité des fichiers et un audit des administrateurs répondent à la même question : qu'y a-t-il sur le serveur ? Ils repèrent un fichier déposé, un fichier du cœur modifié, un administrateur inconnu. Ils ne peuvent pas savoir si la personne qui utilise un vrai compte administrateur est bien l'administrateur. Si un attaquant utilise votre session ou vos mots de passe, chacune de ses modifications ressemble aux vôtres : les journaux montrent votre compte et, quand l'attaque s'exécute dans votre propre navigateur, votre adresse IP aussi.
Une fois le serveur propre, le travail n'est donc pas terminé. Passez en revue les endroits ci-dessous, depuis un appareil de confiance.
1. Les extensions du navigateur
Une extension peut lire et modifier chaque page que vous ouvrez, wp-admin compris, tant que vous êtes connecté. Les extensions se revendent, et un nouveau propriétaire peut publier une mise à jour qui agit discrètement sur les sites que vous administrez : ajouter un administrateur, installer une extension WordPress, modifier un fichier du thème — le tout avec votre session, depuis votre navigateur, à votre IP. C'est l'explication la plus courante de « c'était fait depuis mon propre compte ».
Ouvrez la page des extensions du navigateur (chrome://extensions dans Chrome) sur chaque ordinateur qu'utilise un administrateur. Supprimez tout ce que vous ne reconnaissez pas, n'utilisez pas, ou qui demande à « lire et modifier toutes vos données sur tous les sites » sans raison claire. Désormais, faites l'administration WordPress dans un profil de navigateur séparé, sans aucune extension.
2. L'ordinateur de l'administrateur
Les malwares voleurs de mots de passe (infostealers) copient les mots de passe enregistrés dans le navigateur et les cookies de connexion de chaque site où vous êtes connecté. Un cookie de connexion volé est une session qui a déjà passé la double authentification : le 2FA n'arrête donc pas celui qui le détient. Ces infections viennent souvent d'un logiciel piraté, d'une fausse mise à jour ou d'un faux CAPTCHA qui vous a demandé de coller une commande.
Analysez chaque ordinateur qui s'est connecté à wp-admin, à l'hébergement ou à la messagerie. Tant que vous n'êtes pas sûr qu'un appareil est sain, considérez tout mot de passe enregistré dans son navigateur comme connu de l'attaquant, et changez les mots de passe depuis un autre appareil.
3. Ce que le site a laissé dans votre propre navigateur
Un service worker enregistré pendant que vous étiez dans wp-admin vit dans votre navigateur, pas sur le serveur, et continue de tourner après le nettoyage du site. Votre navigateur conserve aussi les cookies et les scripts en cache du site.
Dans le navigateur de chaque administrateur, ouvrez le site, puis Outils de développement → Application → Stockage → Effacer les données du site. Cela supprime ses service workers, ses cookies et ses fichiers en cache pour ce site.
4. Hébergement, SFTP, SSH et base de données
Votre compte d'hébergement est au-dessus de WordPress. Un attaquant qui y est entré peut créer un utilisateur du panneau de contrôle, un compte FTP ou SFTP, une clé SSH dans authorized_keys, un utilisateur de base de données accessible à distance, ou une tâche cron dans le panneau d'hébergement qui réécrit des fichiers toutes les heures. Rien de tout cela n'est visible depuis WordPress, donc aucune extension WordPress ne peut le signaler.
Connectez-vous au panneau d'hébergement et listez tous les utilisateurs, comptes FTP, clés SSH, utilisateurs de base de données et tâches planifiées. Supprimez ce que vous n'avez pas créé, et changez les mots de passe de l'hébergement, du SFTP et de la base de données.
5. La boîte e-mail
La boîte qui reçoit les réinitialisations de mot de passe WordPress, ainsi que les messages de l'hébergeur et du registraire, est la clé de tout le reste. Une règle de transfert qui copie les e-mails de réinitialisation vers une adresse extérieure, ou un filtre qui archive les alertes de sécurité avant que vous les voyiez, survit à chaque changement de votre mot de passe WordPress.
Vérifiez les règles de transfert, les filtres, les mots de passe d'application, les applications connectées et l'e-mail et le téléphone de récupération. Activez la double authentification et déconnectez toutes les autres sessions.
6. Google, Search Console et Tag Manager
Après une intrusion, les attaquants s'ajoutent souvent comme propriétaires dans Google Search Console ou Bing Webmaster Tools. De là, ils peuvent soumettre des sitemaps de spam, demander à Google de retirer vos vraies pages et lire vos données de recherche — et un propriétaire reste propriétaire après le nettoyage du site. Le contrôle d'intégrité SEO de Relvato signale un nouveau jeton de validation sur le site, mais la liste des propriétaires se trouve dans le compte Google, pas sur votre serveur.
L'autre, c'est Google Tag Manager : quiconque peut publier un conteneur peut mettre un script sur toutes les pages sans toucher au serveur. Vérifiez les utilisateurs dans la Search Console (Paramètres → Utilisateurs et autorisations), Bing Webmaster Tools, Tag Manager et Analytics, et retirez ceux que vous ne connaissez pas.
7. Registraire du domaine, DNS et CDN
Celui qui contrôle le domaine décide où pointent le site et sa messagerie. Vérifiez les utilisateurs et les jetons d'API chez votre registraire, votre hébergeur DNS et votre CDN (Cloudflare surtout), et activez la double authentification et le verrou de transfert du registraire. La surveillance DNS de Relvato signale un changement de serveurs de noms ou de messagerie, mais elle ne peut pas voir qui détient un accès à ces comptes.
8. Clés de déploiement, intégrations et sauvegardes
Si le site se déploie depuis GitHub ou un autre dépôt, vérifiez ses clés de déploiement, ses secrets de CI et qui peut pousser. Vérifiez les intégrations qui détiennent une clé du site : services de sauvegarde, moniteurs de disponibilité, comptes cloud des constructeurs de pages, mots de passe d'application créés pour Zapier ou une application mobile.
Et les sauvegardes elles-mêmes : restaurer une sauvegarde faite après l'intrusion restaure l'intrusion. Dans Relvato, la page Sécurité du site indique quand tous les contrôles d'intégrité ont réussi ensemble pour la dernière fois — une sauvegarde de cette période est la plus sûre à restaurer.
Verrouillez dans cet ordre
L'ordre compte, car chaque compte peut réinitialiser le suivant. Commencez par l'appareil : un ordinateur de confiance, ou fraîchement nettoyé. Puis la boîte e-mail, car elle reçoit toutes les autres réinitialisations. Puis les comptes du registraire, du DNS et du CDN, puis les utilisateurs d'hébergement, SFTP, SSH et base de données. Puis WordPress : supprimez les administrateurs et mots de passe d'application inconnus, changez le mot de passe de chaque administrateur et générez de nouvelles clés de sécurité dans wp-config.php pour déconnecter toutes les sessions existantes. Enfin, les consoles tierces : Search Console, Tag Manager, statistiques et outils de déploiement.
À chaque étape, utilisez l'option « se déconnecter de toutes les sessions » quand elle existe. Changer un mot de passe ne met pas fin à une session déjà volée.
Ce que Relvato vérifie, et ce qu'il ne peut pas voir
Relvato vérifie le site de l'extérieur, comme un visiteur, et via son extension WordPress, qui signale ce qui se trouve sur le serveur — jamais le contenu des fichiers. Il détecte les fichiers déposés et le code exécuté depuis la base de données, les administrateurs cachés de l'écran Utilisateurs, les mots de passe d'application, les service workers enregistrés par du code injecté, les changements DNS et les nouveaux jetons de validation de la Search Console. Quand il voit des signes de piratage, il affiche cette checklist à côté et peut mettre le site en quarantaine pendant 48 heures.
Il ne peut pas voir votre navigateur, votre ordinateur ni les comptes de cette liste. Rien de ce qui tourne sur un serveur ne le peut. Cette partie, c'est à vous de la vérifier — et c'est souvent là que l'attaque a commencé.
Par où les attaquants entrent sans qu'un scan du serveur le voie
| Où | Pourquoi le serveur ne le voit pas | Quoi vérifier |
|---|---|---|
| Extensions du navigateur | Elles agissent dans wp-admin avec votre session, depuis votre IP | Supprimer les extensions inconnues ; administrer dans un profil sans aucune |
| L'ordinateur de l'administrateur | Les mots de passe et cookies volés servent ailleurs ; un cookie contourne le 2FA | L'analyser ; changer les mots de passe depuis un autre appareil |
| Données du navigateur de l'administrateur | Un service worker ou une session vit dans le navigateur | Effacer les données du site dans le navigateur de chaque administrateur |
| Hébergement, SFTP, SSH, base de données | Ces comptes sont au-dessus de WordPress | Utilisateurs, clés SSH, utilisateurs de base de données et tâches cron de l'hébergeur |
| Boîte e-mail | Les réinitialisations de mot de passe y arrivent | Transferts, filtres, mots de passe d'application, récupération |
| Consoles Google et Bing, Tag Manager | Propriétaires et conteneurs vivent dans des comptes Google et Microsoft | Propriétaires dans Search Console et Bing ; qui peut publier dans Tag Manager |
| Registraire, DNS, CDN | Le panneau de contrôle du domaine est ailleurs | Utilisateurs, jetons d'API, double authentification, verrou de transfert |
| Clés de déploiement et sauvegardes | Les clés sont chez d'autres services ; une sauvegarde peut contenir l'infection | Clés de déploiement, secrets de CI, intégrations ; restaurer d'avant l'intrusion |
Questions fréquentes
Pourquoi mes journaux WordPress montrent-ils mon propre compte et mon IP ?
Parce que les modifications venaient probablement de votre propre navigateur : une extension malveillante agissant avec votre session, ou un malware sur votre ordinateur. Le serveur voit un vrai administrateur faire de vraies choses, donc chaque journal paraît légitime. Vérifiez vos extensions et analysez l'ordinateur avant de lui refaire confiance.
La double authentification n'empêche-t-elle pas cela ?
Pas le vol de session. La double authentification protège la connexion ; un cookie de connexion volé est une session qui l'a déjà franchie. Générer de nouvelles clés de sécurité dans wp-config.php déconnecte toutes les sessions, et changer ensuite le mot de passe — depuis un appareil sain — empêche l'attaquant de se reconnecter.
Changer mon mot de passe WordPress suffit-il ?
Non. Cela ne met pas fin aux sessions en cours, ne révoque pas les mots de passe d'application et ne touche ni à l'hébergement, ni à la messagerie, ni au registraire, ni aux comptes Google. Suivez la checklist dans l'ordre, en commençant par l'appareil et la boîte e-mail.
Quelle sauvegarde dois-je restaurer ?
Une sauvegarde d'avant l'intrusion — en restaurer une plus récente restaure l'infection. Relvato indique sur la page Sécurité du site et dans l'alerte quand tous les contrôles d'intégrité ont réussi ensemble pour la dernière fois (« dernier état sain connu »), pour que vous sachiez de quelle période restaurer.
Relvato peut-il voir mes extensions de navigateur ou mes comptes ?
Non, et aucun outil qui tourne sur le serveur ne le peut. Relvato vérifie le site et ce que son extension signale depuis le serveur. Quand il voit des signes de piratage, il affiche cette checklist, parce que l'entrée se trouve souvent là où il ne peut pas regarder.