Premiers secours · 10 min · publié le 19 janvier 2024

Quels mots de passe changer après un piratage (dans cet ordre)

Hébergement d’abord, puis FTP/SFTP, administration du site, base de données, boîtes utilisées par le CMS. Inverser cet ordre laisse une session ouverte : quelqu’un recrée le fichier que vous venez de retirer. Voici la séquence, et ce qu’on oublie presque toujours.

Réponse directe

Hébergement d'abord, puis FTP/SFTP, administration du site, base de données, boîtes utilisées par le CMS. Inverser cet ordre laisse une session ouverte.

changer mot de passe site piraté mots de passe après hack régénérer accès wordpress

Pourquoi l’ordre compte plus que la liste

Changer le mot de passe WordPress pendant que le panel o2switch ou OVH est encore l’ancien, c’est du théâtre. L’attaquant qui a le panel réécrit `wp-config.php`, crée un FTP, pose un mu-plugin. Votre nouvel admin tient jusqu’au prochain chargement. D’où la règle : celui qui peut tout réécrire se change en premier.

L’inverse (CMS d’abord, panel plus tard) est le réflexe naturel : on voit wp-admin, on agit là. Les dossiers que nous reprenons montrent souvent un fichier `radio.php` réapparu deux heures après un « j’ai tout changé ». Le panel, lui, n’avait pas bougé.

Cinq couches, dans cet ordre : 1) panel et utilisateurs d’hébergement, 2) FTP/SFTP/SSH, 3) CMS et sessions, 4) base et secrets dans les fichiers, 5) services connectés (mail, Stripe, Search Console). Chaque couche s’appuie sur la précédente. Sautez-en une, et le travail en dessous est temporaire.

  • Panel (et sous-comptes, 2FA).
  • FTP / SFTP / SSH / clés.
  • Admin CMS + invalidation des sessions.
  • MySQL + `wp-config` / `.env`.
  • SMTP, paiements, API, Search Console.
Ne commencez pas par « mot de passe oublié » WordPress si vous n’avez plus le panel. Reprenez le panel d’abord, via l’hébergeur.

Minute une : le panel d’hébergement

cPanel, Plesk, manager OVH, o2switch, LWS : c’est la clé du compte. Changez le mot de passe principal, puis ouvrez la liste des utilisateurs secondaires. Un `support2024`, un email que vous ne reconnaissez pas, un accès « webmaster » laissé à une agence partie en 2022. Révoquez, ne « désactivez pour voir » : une session cookie peut rester.

Activez un second facteur maintenant, pas « après le nettoyage ». Si l’attaquant a l’email de récupération du panel, changez aussi cet email vers une adresse personnelle que vous seul lisez — surtout si la messagerie du domaine est sur le même compte, donc potentiellement lue.

Notez l’heure du changement. Elle sert au constat et à relire les logs FTP ensuite. Si vous ne pouvez plus entrer dans le panel, passez par le support hébergeur (pièce d’identité, code client), pas par un prestataire qui « a encore le mot de passe quelque part ». Voir prestataire disparu.

Ensuite FTP, SFTP, SSH et les clés

Listez tous les comptes FTP. Sur cPanel : FTP Accounts. Un compte limité à `public_html/wp-content/uploads` suffit à déposer un PHP. Réinitialisez les mots de passe, supprimez les comptes inconnus. Si le FTP « ne marche plus », l’attaquant l’a souvent déjà changé : reprendre l’accès passe par le panel, pas par FileZilla en boucle.

SSH : `authorized_keys` dans `.ssh/`. Une clé que vous n’avez pas posée, c’est une porte qui survit à tous les mots de passe. Retirez les lignes inconnues, changez la passphrase de votre clé si elle a pu fuir. SFTP via ce compte = les mêmes droits que SSH.

Les clients FTP enregistrent les mots de passe. Après changement, mettez à jour FileZilla / Cyberduck sur toutes les machines de l’équipe, sinon quelqu’un réécrit l’ancien secret par « enregistrer ». Et un poste déjà infecté (keylogger) rend l’exercice vain : changez depuis une machine saine.

Administration du CMS et sessions encore vivantes

WordPress : tous les administrateurs, puis éditeurs si vous êtes paranoïaque à bon escient. Un mot de passe nouveau ne tue pas les cookies déjà émis. Allez dans votre profil, déconnexion partout, ou régénérez les clés `AUTH_KEY` / `SECURE_AUTH_KEY` dans `wp-config.php` (elles invalident les sessions). C’est plus net qu’un « changez votre pass » seul.

PrestaShop : Employés, pas le compte client. Magento : utilisateurs admin + les clés d’intégration. Drupal : rôles uid 1 et administrateurs. Sur tous : un second Super Admin créé à 4 h du matin se voit dans la liste, pas dans votre tête.

Si wp-admin redirige ou si votre compte a disparu, ne réinstallez pas. Passez par la base ou le panel : compte admin bloqué. Changer un mot de passe que vous ne pouvez plus saisir ne sert à rien.

Base MySQL et fichiers de configuration

L’utilisateur MySQL du `wp-config.php` a souvent les droits `ALL` sur la base. S’il a fuité (fichier lu, `.env` exposé, backup public), créez un nouvel utilisateur SQL, mettez à jour le fichier, retirez l’ancien. Changez aussi le préfixe n’est pas une priorité ; le mot de passe SQL l’est.

`wp-config.php`, `.env`, `app/etc/env.php`, `parameters.php` : ce sont des coffres. Après un piratage, considérez-les lus. Nouvelles valeurs, pas un « +1 » à la fin de l’ancien mot de passe. Vérifiez que ces fichiers ne sont plus servis en HTTP (`/.env`, `/wp-config.php.bak`).

Les dumps et backups dans `public_html` (`.sql`, `.sql.gz`, `backup.zip`) contiennent ces secrets. Retirez-les du web, pas seulement « on changera ». Un dump oublié annule le changement de mot de passe SQL.

Boîtes, SMTP, prestataires de paiement

La boîte qui reçoit « mot de passe oublié » du CMS et du panel : si elle est sur le même hébergement, l’attaquant l’a peut-être lue. Changez-la, activez la 2FA chez l’opérateur mail. Les alias `webmaster@`, `admin@`, `postmaster@` aussi.

SMTP transactionnel (Brevo, Mailgun, SMTP du panel) : révoquez les clés, régénérez. Un site qui envoie du phishing depuis votre domaine se voit dans le journal d’envoi. La clé SMTP est suffisante pour continuer après que vous avez « nettoyé » les fichiers.

Stripe, PayPal, Prestashop Checkout, Search Console, Tag Manager, Cloudflare : listez les accès, retirez les inconnus, tournez les clés API. Un pixel ou un conteneur GTM ajouté par l’attaquant survit au mot de passe WordPress. Voir aussi GTM détourné.

  • Messagerie de récupération (domaine + perso).
  • Clés SMTP / ESP.
  • Paiement : clés secrètes, pas seulement le dashboard.
  • Cloudflare / DNS : si quelqu’un peut changer les A, le reste est cosmétique.

Ce qu’on oublie : Application Passwords, employés, API

WordPress 5.6+ : Application Passwords. Elles survivent au changement du mot de passe principal. Écran utilisateur → mots de passe d’application → révoquer tout. Les sites headless et les applis mobiles en ont souvent une oubliée.

WooCommerce REST, PrestaShop webservice, Magento integrations : mêmes symptômes. Une clé `ck_` dans un vieux prestataire suffit à lire les commandes. xmlrpc.php avec multicall ouvert n’est pas un mot de passe, mais c’est un accès : limitez-le après l’incident.

Les anciens développeurs, stagiaires, « le cousin qui avait FTP » : révoquez même si « c’est quelqu’un de confiance ». L’incident montre que le secret a circulé. La confiance ne se configure pas dans cPanel.

Si le même secret servait partout

Panel = admin WP = messagerie = Stripe : partez du principe que tout a été lu. Trois secrets distincts au minimum, gestionnaire de mots de passe, pas un email à l’agence avec le tableau Excel. Le réemploi est plus fréquent que l’exploit 0-day sur les vitrines que nous voyons.

Changez aussi les services personnels si le même mot de passe y figurait (attention au scope : on parle des comptes liés au site, pas de votre banque dans cet article). L’attaquant qui a `wp-config` n’a pas magiquement votre Gmail, sauf réemploi.

Documentez le nouvel état : qui a quel accès, depuis quand. C’est la pièce que l’assureur et le prochain prestataire demandent. Sans ça, dans six mois personne ne sait si `ftp-agence` est encore légitime.

Vérifier qu’il ne reste plus de session

24 heures plus tard : plus de connexion FTP inconnue dans les logs, plus de nouvel utilisateur CMS, plus de fichier PHP daté d’après votre passage. Si un fichier revient, le secret n’était pas le bon étage (voisin de compte, cron, clé SSH).

Testez la récupération de mot de passe : l’email arrive-t-il encore dans une boîte que vous ne contrôlez plus ? Un hook pirate peut rediriger les mails d’admin. Vérifiez `admin_email` en base.

L’ordre complet de l’heure — constater, copier, panel, ticket — est dans mon site est piraté, que faire. Les mots de passe sont l’étape 3, pas la première ni la dernière.

Questions fréquentes

Dois-je changer le mot de passe de tous les utilisateurs WordPress ?

+
Administrateurs et éditeurs, oui. Abonnés et clients boutique : seulement s’il y a suspicion de lecture de la table (fuite). Forcer 2000 resets clients sans constat crée plus de dégâts que de sécurité.

La 2FA WordPress suffit-elle si le panel est encore faible ?

+
Non. Un accès panel pose un mu-plugin qui contourne la 2FA. Panel d’abord, 2FA CMS ensuite.

Faut-il régénérer les clés AUTH_KEY dans wp-config ?

+
Oui, après un accès admin suspect. Ça déconnecte tout le monde, y compris vous : prévoyez de vous reconnecter. C’est le moyen le plus propre d’invalider les cookies.

L’attaquant a changé mon mot de passe admin. Par où je passe ?

+
Panel hébergeur, puis phpMyAdmin ou WP-CLI, pas une réinstallation. Changez le panel avant de recréer l’admin, sinon il sera retouché.

Combien de temps avant que les anciens mots de passe soient « oubliés » ?

+
Jamais s’ils ont été stockés. Un secret fuité reste fuité. Rotation = nouveaux secrets, pas un délai de carence.
À lire ensuite
Mot de passe admin changé sans vous Plus d’accès FTP Application Passwords WordPress Panel différent du CMS Premiers gestes Déclarer mon site