Une redirection inconnue, un compte administrateur ajouté ou un avertissement de malware sont des indicateurs, pas encore un diagnostic complet. Face à un site WordPress piraté, la priorité est de contenir le risque tout en préservant assez d’éléments pour comprendre l’accès initial et éviter une réinfection.
Supprimer le fichier visible ou restaurer immédiatement une copie peut masquer la cause. Une réponse solide documente l’incident, protège les utilisateurs, révoque les accès, reconstruit depuis des sources fiables, vérifie les données et surveille le retour en ligne.
Sommaire
La réponse courte
Notez les symptômes, l’heure et les changements récents. Limitez l’accès public selon le risque, préservez une copie de l’état compromis et contactez les responsables appropriés. Depuis un appareil sain, sécurisez les comptes et services associés.
Déterminez la fenêtre de compromission, remplacez le cœur et les composants par des versions officielles propres, examinez contenus et base, corrigez la voie d’entrée puis restaurez. Changez de nouveau les secrets après nettoyage. Si les données personnelles peuvent être touchées, suivez les obligations juridiques et contractuelles applicables.
La documentation WordPress recommande de commencer par documenter les indicateurs et leur heure.
Principes qui restent valables
Un incident WordPress peut provenir d’un composant vulnérable, d’un mot de passe réutilisé, d’un poste compromis, d’une extension piratée ou d’un accès adjacent. Mettre à jour le cœur ne ferme pas automatiquement toutes ces voies.
Les scanners ont progressé, mais aucun résultat unique ne prouve que chaque fichier et chaque entrée de base sont sains. Une alerte doit être confirmée ; une absence d’alerte ne constitue pas une garantie absolue.
Distinguer panne et compromission
Un écran d’erreur après une mise à jour peut être un problème de compatibilité. Le mode de récupération WordPress peut aider à isoler une extension ou un thème responsable d’une erreur fatale, mais il n’est pas un outil de nettoyage de malware.
Cherchez des indicateurs vérifiables : utilisateur inconnu, fichier ajouté, modification non autorisée, redirection conditionnelle, contenu injecté, alerte d’un moteur ou trafic sortant anormal.
Ne présentez pas publiquement un site comme piraté avant d’avoir confirmé les faits et coordonné la communication.
Ouvrir un journal d’incident
Notez qui a détecté quoi, quand, dans quel fuseau et par quel moyen. Conservez les captures et résultats dans un espace privé. Ajoutez les changements récents, comptes concernés, versions et actions réalisées.
Chaque intervention peut modifier les preuves. Horodatez donc la mise en maintenance, la copie, les révocations et la restauration. Distinguez observation, hypothèse et décision.
Masquez données personnelles, cookies, clés, chemins, IP et contenus clients avant tout partage avec une partie autorisée.
Contenir sans détruire les preuves
Selon la gravité, activez une maintenance contrôlée, bloquez les fonctions dangereuses, isolez l’instance ou dirigez le trafic vers une page sûre. Coordonnez avec l’hébergement pour éviter que le site attaque d’autres systèmes.
Avant de supprimer, créez une image ou une copie de la base et des fichiers compromis si la politique le permet. Cette copie n’est pas une sauvegarde saine : étiquetez-la, chiffrez-la et limitez son accès.
Ne lancez pas dix scanners qui réécrivent les fichiers avant la collecte initiale.
Utiliser un appareil et un canal sains
Si le poste administrateur est compromis, tout nouveau mot de passe peut être capturé. Effectuez les actions sensibles depuis un appareil connu comme sain et un réseau maîtrisé.
Protégez d’abord les adresses de récupération et les comptes du registrar, DNS, hébergement, sauvegarde, dépôt et services externes. Activez ou vérifiez MFA. Révoquez sessions et jetons actifs.
Un changement limité au mot de passe WordPress ne suffit pas si l’attaquant possède encore un accès SFTP, une clé API ou le compte e-mail.
Préserver les journaux et la chronologie
Collectez les journaux disponibles autour de la première activité suspecte : authentification, serveur web, application, changements de fichiers et événements de sécurité. Conservez leur fuseau, rétention et intégrité.
L’absence d’un événement peut venir d’une rétention courte ou d’une source non collectée. Évitez les conclusions absolues. Corrélez plusieurs signaux et conservez la différence entre l’heure de détection et l’heure probable d’accès.
Ne copiez pas les journaux bruts dans un article public ; ils contiennent souvent des identifiants et des données visiteurs.
Déterminer le rayon d’impact
Inventoriez sites, sous-domaines, bases, comptes et services partageant le même environnement ou les mêmes secrets. Cherchez si les mêmes identifiants ont été réutilisés ailleurs.
Vérifiez les utilisateurs ajoutés, rôles modifiés, extensions, thèmes, tâches planifiées, fichiers de démarrage, règles de redirection, clés applicatives et contenus. Examinez également les environnements de staging et les sauvegardes accessibles.
Le but n’est pas seulement de trouver un fichier malveillant, mais de décider quelles sources peuvent encore être considérées fiables.
Choisir une sauvegarde saine
Une sauvegarde antérieure à la détection peut déjà contenir la compromission. Comparez sa date à la chronologie, analysez-la hors ligne ou sur un environnement isolé et vérifiez son intégrité.
La sauvegarde doit inclure base et fichiers correspondant à un état cohérent. Le guide restaurer une sauvegarde WordPress explique le test de restauration et la validation des parcours.
Si aucune copie ne peut être déclarée saine, reconstruisez plus largement à partir de sources officielles et de contenus contrôlés.
Remplacer le cœur par une source officielle
Téléchargez la version voulue depuis WordPress.org et remplacez les fichiers du cœur selon une méthode propre. Ne vous contentez pas d’écraser quelques fichiers : un attaquant peut en avoir ajouté qui ne figurent dans aucune distribution.
Comparez les sommes ou utilisez les commandes officielles appropriées. Conservez wp-content et la configuration pour une inspection séparée ; ils ne sont pas fournis par le même paquet.
La documentation de durcissement WordPress recommande d’obtenir les versions officielles uniquement depuis la source WordPress.
Examiner extensions et thèmes
Remplacez les composants publics par des copies propres de la même version ou d’une version corrigée compatible. Pour le code personnalisé, comparez au dépôt et à une version revue. Supprimez les composants abandonnés ou non nécessaires après décision.
Cherchez des fichiers inattendus, des modifications dans les points d’entrée et du code obfusqué. Un scanner aide à prioriser, mais une comparaison à une source connue est plus explicite.
Ne réactivez pas un composant qui a probablement ouvert la voie sans correctif ou mesure compensatoire.
Examiner les téléversements et la base
Le répertoire de médias ne devrait généralement pas exécuter de code, mais une mauvaise configuration ou une extension peut modifier cette hypothèse. Recherchez les types inattendus et vérifiez les règles de serveur.
Dans la base, contrôlez utilisateurs, options sensibles, tâches, contenus injectés, widgets, scripts et réglages de paiement ou d’e-mail. Utilisez des requêtes de lecture avant toute correction et sauvegardez les lignes ciblées.
La base peut contenir une persistance même après remplacement des fichiers.
Révoquer et renouveler les secrets
Forcez la fin des sessions et changez les mots de passe uniques des comptes privilégiés. Renouvelez clés WordPress, accès base, SFTP/SSH, API, mots de passe d’application et secrets de déploiement selon le périmètre.
Effectuez un renouvellement initial pour contenir, puis un second après la reconstruction si les secrets ont pu être utilisés sur l’environnement compromis. Mettez à jour les dépendances sans stocker de valeur en clair dans le journal d’incident.
Révoquez les comptes inconnus et réduisez les privilèges.
Corriger la cause probable
La restauration sans correction reproduit le risque. Identifiez la voie la mieux étayée : version vulnérable, secret compromis, permission trop large, composant non maintenu ou appareil infecté.
Appliquez le correctif, supprimez les accès inutiles, mettez à jour le code et renforcez la surveillance. Si la cause reste incertaine, dites-le et augmentez les contrôles au lieu d’inventer une certitude.
Documentez les décisions et ce qui n’a pas pu être vérifié.
Tester avant le retour public
Sur un environnement isolé, vérifiez intégrité, utilisateurs, versions, HTTPS, pages, administration, recherche, formulaires, tâches, e-mails et transactions. Testez depuis une session déconnectée et avec un compte minimal.
Analysez la copie reconstruite avec plusieurs méthodes adaptées. Comparez les fichiers aux sources connues. Confirmez que les indicateurs initiaux ont disparu sans se limiter à eux.
Préparez un retour arrière vers la maintenance si une anomalie réapparaît.
Remettre en ligne et surveiller
Rouvrez progressivement, purgez les caches de façon contrôlée et surveillez erreurs, créations de comptes, changements de fichiers, redirections, trafic et alertes externes. Conservez une fenêtre de surveillance renforcée.
Demandez une réévaluation aux services qui avaient signalé le site selon leur procédure. Vérifiez aussi recherche, certificat et réputation d’envoi si concernés.
Une remise en ligne fonctionnelle ne clôt pas immédiatement l’incident.
Traiter communication et obligations
Identifiez les données potentiellement touchées, les personnes responsables et les délais applicables. Demandez un avis juridique ou spécialisé si nécessaire. Ne minimisez pas et ne publiez pas d’informations non vérifiées.
La communication doit distinguer faits, impact connu, mesures prises et prochaines étapes. Évitez les détails qui faciliteraient une nouvelle attaque.
Conservez les preuves nécessaires selon la politique et les obligations.
Réaliser le retour d’expérience
Après stabilisation, réunissez chronologie, cause, facteurs contributifs, impact, détection, réponse et actions. Attribuez chaque amélioration avec une échéance : mises à jour, MFA, sauvegardes immuables, surveillance ou exercice.
Mesurez le temps de détection, de contention et de restauration, sans en faire une promesse publique universelle. Testez ensuite les nouveaux contrôles.
Le but est d’améliorer le système, pas de chercher un coupable individuel.
Ordre recommandé
- Confirmer et documenter les indicateurs.
- Contenir selon le risque.
- Préserver état compromis et journaux.
- Sécuriser les comptes depuis un appareil sain.
- Déterminer le rayon et la fenêtre.
- Sélectionner des sources et sauvegardes fiables.
- Reconstruire cœur, composants, données et secrets.
- Corriger la voie d’entrée probable.
- Tester sur une copie isolée.
- Remettre en ligne, surveiller et tirer les leçons.
Les erreurs à éviter
- Effacer immédiatement le seul fichier visible.
- Restaurer une sauvegarde dont la date n’a pas été analysée.
- Changer seulement le mot de passe WordPress.
- Considérer un scanner sans alerte comme preuve absolue.
- Réinstaller depuis une source non officielle.
- Réutiliser des secrets exposés pendant le nettoyage.
- Publier journaux, identifiants ou détails d’attaque réels.
- Fermer l’incident dès que la page d’accueil revient.
Checklist site WordPress piraté
- [ ] Les indicateurs, heures et actions sont documentés.
- [ ] La contention correspond au risque.
- [ ] Une copie compromise est préservée et isolée.
- [ ] Les comptes adjacents sont sécurisés depuis un appareil sain.
- [ ] Le rayon d’impact et la chronologie sont établis.
- [ ] Les sources de reconstruction sont fiables.
- [ ] Fichiers, base, utilisateurs et secrets sont traités.
- [ ] La voie d’entrée est corrigée ou l’incertitude documentée.
- [ ] Les parcours sont testés avant remise en ligne.
- [ ] La surveillance, la communication et le retour d’expérience sont planifiés.
Conclusion
Face à un site WordPress piraté, la vitesse compte, mais l’ordre compte davantage. Documenter, contenir, préserver, révoquer, reconstruire et surveiller permet de réduire le risque sans détruire les éléments nécessaires à la compréhension.
La meilleure préparation reste un inventaire à jour, des accès minimaux et des sauvegardes réellement restaurables. Pour replacer ces responsabilités dans le choix de la plateforme, consultez choisir un hébergement WordPress.