Plan d’urgence WordPress : détecter, isoler et corriger les sites piratés

Contexte et cadre réglementaire (pourquoi maintenant et quoi vérifier en urgence)

Les plugins restent le vecteur principal de compromissions : vulnérabilités d'exécution à distance, mises à jour signées après compromission de comptes contributeurs, ou backdoors distribuées via extensions abandonnées. Pour prioriser, il faut rapprocher l'état du site des bases publiques : vérifier versions de WordPress et des extensions via wordpress.org/security et WPScan, puis corréler avec les avis et IOCs publiés par Wordfence et Sucuri. Ces validations déterminent la probabilité d'exploitation et l'étendue du nettoyage requis.

Sur le plan légal et procédural, la réponse française impose des exigences de conservation des preuves et de notification. La CNIL encadre la notification des violations de données personnelles selon critères d'exposition et de sensibilité ; l'ANSSI et CERT‑FR émettent des recommandations sur la capture et la préservation des logs, images disque et captures réseau, ainsi que sur la tenue d'une chaîne de custody. Documenter chaque action (qui, quand, commandes exécutées, hachages produits) est indispensable pour rester conforme et pour permettre une éventuelle notification.

Techniquement, vérifiez d'emblée trois familles d'éléments : 1) versions et vulnérabilités connues des composants (core, thèmes, plugins) via les sources indiquées ; 2) signes évidents d'installation persistante (fichiers modifiés, comptes administrateurs inconnus, tâches CRON suspectes, connexions sortantes ou webhooks persistants) ; 3) intégrité des sauvegardes (dates, hachages, et tests de restauration isolée). Ces contrôles orientent la décision entre restauration depuis une sauvegarde saine et nettoyage forensique complet.

Points clés à retenir

• Détection rapide via scans externes et matching d'IOCs : produire inventaire de fichiers modifiés et hachages pour la traçabilité.
• Isolation immédiate (mode maintenance 503, blocage des accès, révocation de sessions) puis choix entre restauration depuis backup vérifié ou nettoyage forensique.
• Corrections durables : patching, suppression d'extensions non maintenues, rotation complète des secrets, MFA et sauvegardes immuables.
• Respect procédural et légal : conservation des preuves (logs, images disque, captures mémoire), documentation horodatée et notification CNIL/CERT‑FR si nécessaire.

Détecter : checklist d'urgence (scans, IOCs et preuves) — Quickstart opérationnel

En 30–90 minutes, exécuter une séquence minimale automatisée et collecter les preuves : lancer un scan externe (par exemple via Sucuri ou Wordfence live scanner) pour détecter injections et SEO spam, lister les comptes WordPress présents en exportant la table users et journaliser les comptes nouveaux ou modifiés, et extraire les logs serveurs (syslog, access.log, error.log). Produire un inventaire de fichiers modifiés sur les 30 derniers jours avec la commande fournie : « find -mtime -30 -type f -exec sha256sum {} ; » et conserver ces hachages. Télécharger ou noter les IOCs publiés par Wordfence, Sucuri et WPScan (hashes, patterns d'obfuscation PHP, URLs de C2) puis matcher ces indicateurs localement. Enfin, si possible, prendre un snapshot VM/disque et, pour les équipes qui peuvent le faire, capturer la mémoire des processus suspects ; ces artefacts sont précieux pour une analyse forensique ultérieure.

Isoler et corriger : procédure pas-à‑pas (mode maintenance → restauration → hardening)

Une fois la compromission confirmée, appliquez d'abord une isolation stricte. Mettre le site en mode maintenance avec une réponse 503 affichant une page statique, couper tous les accès non essentiels (FTP, SFTP, SSH) sauf pour l'équipe forensique et les administrateurs désignés, révoquer les sessions WordPress et forcer la réinitialisation des mots de passe administrateurs si nécessaire. Bloquer les adresses IP et agents utilisateurs identifiés comme malveillants au niveau du WAF ou via règles Cloudflare/NGINX pour réduire toute exfiltration en cours.

La décision de restaurer ou de nettoyer dépend de la disponibilité et de la confiance dans les sauvegardes. Si vous disposez d'un backup récent dont l'intégrité est vérifiée, restaurez-le sur un environnement isolé, appliquez immédiatement tous les patchs nécessaires et rejouez les procédures de validation contre les IOCs publiés. Si aucune sauvegarde fiable n'existe, entamez un nettoyage forensique : remplacer le cœur de WordPress, les thèmes et plugins par des copies officielles, rechercher et supprimer les fichiers malicieux et vérifier les CRON jobs et hooks dans la base de données pour détecter des backdoors. Dans tous les cas, validez la correction par un re-scan et une revue manuelle du code ; si un doute subsiste, sollicitez un contrôle indépendant par une tierce partie.

Pour prévenir une récidive, appliquez des corrections durables : patch immédiat des composants vulnérables, suppression des extensions non maintenues, politique stricte de gestion des mises à jour, et rotation complète des secrets (clés API, mots de passe de la base, tokens OAuth). Renforcez les protections : WAF, authentification à deux facteurs pour les comptes administrateurs, moindre privilège pour les comptes, sauvegardes immuables et tests de restauration réguliers. Préparez ensuite la communication : synthèse factuelle interne et externe, procédure de notification CNIL si des données personnelles ont été exposées, et signalement à CERT‑FR avec transmission des IOCs pour informer d'autres opérateurs.

Conclusion — Synthèse, checklist finale et perspectives

Résumé de l'urgence opérationnelle : détecter rapidement avec scans et IOCs, isoler le site et bloquer les vecteurs externes, restaurer depuis une sauvegarde propre ou nettoyer sous contrôle forensique, puis corriger durablement par patchs et rotation des secrets. Ne remettez jamais en production sans preuve documentée de la résolution de la cause racine et sans validation de restauration effectuée en environnement isolé. Après l'incident, transformez l'expérience en amélioration continue : post‑mortem documenté, inventaire strict des plugins et roadmap de suppression des extensions à risque, intégration d'IOCs dans vos outils de monitoring et exercices de simulation réguliers. Cette démarche permet de limiter l'impact opérationnel et de répondre aux obligations réglementaires françaises tout en renforçant la résilience des sites hébergés.