Site Piraté : Guide Récupération Technique WordPress/Prestashop PME

Votre site affiche une page étrangère, redirige vers un casino en ligne, ou votre hébergeur vient de le suspendre pour activité malveillante. Chaque heure compte : les moteurs de recherche blacklistent les sites infectés, vos clients sont exposés, et la fenêtre de récupération propre se referme. Ce guide détaille les étapes techniques de récupération pour WordPress et PrestaShop, sans raccourci.

#1. Évaluation initiale : confirmer le piratage et isoler

Avant toute manipulation, évaluez l'étendue des dégâts sans aggraver la situation.

Signes caractéristiques d'un site compromis :

• Redirection automatique vers un site tiers (phishing, casino, pharmacie)
• Page d'accueil remplacée par un message de défacement (défacement / defacement)
• Apparition de contenus en japonais, cyrillique ou arabe dans les URLs (hack japonais SEO)
• Envoi de spams depuis votre serveur à votre insu
• Présence de nouveaux comptes administrateurs non créés par vous
• Code encodé en base64 dans les fichiers PHP
• Alerte Google Safe Browsing dans la Search Console

Actions immédiates :

# 1. Mettre le site en maintenance (depuis l'hébergeur, couper le vhost ou activer le mode maintenance)
# 2. Changer TOUS les mots de passe sans exception :
#    - Accès hébergeur (cPanel, Plesk, etc.)
#    - FTP / SFTP
#    - Base de données MySQL
#    - Compte WordPress admin
#    - Email associé au domaine
# 3. Révoquer tous les tokens d'API actifs (Stripe, SendGrid, etc.)

Contactez votre hébergeur dès cette étape. Selon cybermalveillance.gouv.fr, l'hébergeur peut prendre des mesures de confinement et dispose souvent de logs serveur précieux pour identifier l'origine de l'attaque.

#2. Sauvegarde forensique avant nettoyage

Contre-intuitif mais indispensable : sauvegardez l'état compromis avant de nettoyer.

# Via SSH — créer une archive de l'état infecté pour analyse ultérieure
tar -czf /home/backup_infected_$(date +%Y%m%d).tar.gz /var/www/html/

# Exporter la base de données dans son état actuel
mysqldump -u USER -p DATABASE_NAME > /home/db_infected_$(date +%Y%m%d).sql

Cette archive vous permettra d'analyser les IOC (indicateurs de compromission) a posteriori, de comprendre le vecteur d'entrée, et de déposer plainte si nécessaire.

#3. Identification du vecteur d'attaque

Ne pas identifier la cause = récidive garantie. Les vecteurs les plus fréquents sur WordPress et PrestaShop :

# Identifier les fichiers PHP modifiés dans les 30 derniers jours
find /var/www/html -name "*.php" -mtime -30 -ls

# Chercher les backdoors classiques
grep -r --include="*.php" -l "eval(base64_decode" /var/www/html/
grep -r --include="*.php" -l "system(" /var/www/html/
grep -r --include="*.php" -l "passthru(" /var/www/html/

Pour PrestaShop, vérifiez également les dossiers /modules/ et /override/ qui sont des cibles fréquentes.

#4. Nettoyage WordPress — procédure étape par étape

#4.1 Réinstallation du core WordPress

Ne "nettoyez" pas les fichiers core un par un. Réinstallez-les intégralement depuis les sources officielles.

# Télécharger la dernière version stable depuis wordpress.org
wget https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz

# Remplacer les fichiers core (SANS toucher wp-content et wp-config.php)
rsync -av --exclude='wp-content' --exclude='wp-config.php' wordpress/ /var/www/html/

#4.2 Plugins et thèmes

Supprimez tous les plugins et thèmes non utilisés. Pour les actifs :

# Supprimer le dossier du plugin infecté
rm -rf /var/www/html/wp-content/plugins/NOM_PLUGIN/

# Réinstaller depuis wordpress.org via WP-CLI
wp plugin install NOM_PLUGIN --activate --allow-root
wp theme install NOM_THEME --allow-root

#4.3 Vérification de la base de données

-- Vérifier les comptes admin non légitimes
SELECT user_login, user_email, user_registered FROM wp_users;

-- Chercher du code malveillant dans les options
SELECT option_name, option_value FROM wp_options 
WHERE option_value LIKE '%eval(%' 
   OR option_value LIKE '%base64_decode%'
   OR option_value LIKE '%<script%';

-- Vérifier les redirections injectées
SELECT option_name, option_value FROM wp_options 
WHERE option_name IN ('siteurl', 'home');

Supprimez tout compte administrateur non reconnu. Vérifiez la table wp_usermeta pour les utilisateurs avec le rôle administrator injecté.

#4.4 Fichiers uploads

# Les fichiers PHP n'ont rien à faire dans uploads
find /var/www/html/wp-content/uploads -name "*.php" -delete
find /var/www/html/wp-content/uploads -name "*.js" -newer /var/www/html/wp-config.php

#5. Nettoyage PrestaShop — spécificités

PrestaShop présente des vecteurs d'attaque différents de WordPress, notamment via les modules tiers et le système de surcharge (override).

# Vérifier les fichiers modifiés récemment dans les modules
find /var/www/html/modules -name "*.php" -mtime -30 -ls

# Chercher les backdoors dans les overrides
grep -r "eval(" /var/www/html/override/
grep -r "base64_decode" /var/www/html/override/

# Vider le cache PrestaShop (obligatoire après nettoyage)
rm -rf /var/www/html/var/cache/*
# ou pour les versions antérieures
rm -rf /var/www/html/cache/smarty/compile/*
rm -rf /var/www/html/cache/smarty/cache/*

Points de contrôle spécifiques PrestaShop :

• Vérifiez les modules dans Modules > Modules installés — désinstallez tout module non reconnu
• Contrôlez le fichier config/settings.inc.php (credentials base de données)
• Vérifiez les webhooks et URL de paiement dans la configuration des modules de paiement (Stripe, PayPal) — une redirection vers un endpoint frauduleux peut exfiltrer les données de carte

#6. Cas spécifique : ransomware sur hébergement web

Le ransomware ciblant les hébergements web est moins fréquent que sur les postes de travail, mais existe. Il chiffre les fichiers PHP, les médias et parfois la base de données.

Protocole :

1. Isolez immédiatement : coupez l'accès FTP, SSH, et le site
2. Ne payez pas : sans garantie de récupération et financement d'activités criminelles
3. Contactez votre hébergeur : il dispose peut-être de snapshots automatiques antérieurs au chiffrement
4. Restaurez depuis une sauvegarde saine : identifiez la dernière sauvegarde antérieure à la compromission
5. Déposez plainte : auprès de la police ou gendarmerie, avec les logs et l'archive forensique

# Identifier les fichiers chiffrés (extension inhabituelle)
find /var/www/html -name "*.encrypted" -o -name "*.locked" -o -name "*.crypt"

# Vérifier les notes de rançon
find /var/www/html -name "README*" -o -name "DECRYPT*" -o -name "HOW_TO*"

#7. Restauration et vérification post-nettoyage

#7.1 Depuis une sauvegarde saine

Si vous disposez d'une sauvegarde antérieure à la compromission (vérifiez la date avec précision) :

# Restaurer les fichiers
tar -xzf backup_saine.tar.gz -C /var/www/html/

# Restaurer la base de données
mysql -u USER -p DATABASE_NAME < backup_saine.sql

# Appliquer immédiatement les mises à jour manquantes
# (la sauvegarde peut contenir la version vulnérable)

#7.2 Scan post-nettoyage

Plusieurs outils open source permettent de vérifier l'état du site après nettoyage :

• Maldet (Linux Malware Detect) : scanner de malware orienté hébergement web
• ClamAV : antivirus open source avec signatures web
• rkhunter : détection de rootkits

# Scan ClamAV du répertoire web
clamscan -r /var/www/html/ --log=/tmp/clamscan_report.txt

# Maldet
maldet -a /var/www/html/

Soumettez également votre domaine à Google Search Console pour demander une réévaluation après nettoyage, et vérifiez le statut dans l'outil de transparence Google (google.com/transparencyreport/safebrowsing/diagnostic/).

#7.3 Vérification des redirections

# Tester les redirections HTTP depuis l'extérieur
curl -I -L https://votre-domaine.fr

# Vérifier le fichier .htaccess (WordPress)
cat /var/www/html/.htaccess

# Chercher des redirections injectées
grep -i "redirect" /var/www/html/.htaccess
grep -i "rewriterule" /var/www/html/.htaccess

#8. Durcissement post-incident

Une fois le site nettoyé et restauré, appliquez ces mesures avant la remise en ligne.

#8.1 WordPress

// wp-config.php — ajouter les clés de sécurité
// (générer sur https://api.wordpress.org/secret-key/1.1/salt/)
define('AUTH_KEY',         'nouvelle-clé-unique');
define('SECURE_AUTH_KEY',  'nouvelle-clé-unique');
// ... (8 clés au total : AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY
//  + leurs équivalents _SALT)

// Désactiver l'édition de fichiers depuis le tableau de bord
define('DISALLOW_FILE_EDIT', true);

// Laisser les mises à jour de sécurité actives — DISALLOW_FILE_MODS = false par défaut.
// Ne pas confondre avec le blocage d'exécution PHP dans /uploads, qui se fait côté serveur web (.htaccess ci-dessous).

# Fichier .htaccess à déposer dans /var/www/html/wp-content/uploads/
# La directive <Directory> n'est PAS autorisée dans un .htaccess (elle ne s'utilise
# qu'en config principale Apache) — c'est l'emplacement du .htaccess qui définit la portée.
# Syntaxe Apache 2.4 : Require all denied (l'ancienne `deny from all` est dépréciée).
<Files "*.php">
    Require all denied
</Files>

#8.2 Permissions fichiers

# Permissions recommandées WordPress
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chmod 600 /var/www/html/wp-config.php

#8.3 Mesures transverses (WordPress et PrestaShop)

#9. Obligations légales et déclarations

Un site piraté peut déclencher des obligations réglementaires selon le contexte :

Violation de données personnelles (RGPD) : Si des données de clients (emails, adresses, données de paiement) ont été exposées, vous devez notifier la CNIL dans les 72 heures suivant la prise de connaissance de la violation. La notification se fait sur notifications.cnil.fr.

Signalement cybermalveillance.gouv.fr : La plateforme Cybermalveillance.gouv.fr propose une assistance aux victimes et peut orienter vers des prestataires référencés (label ExpertCyber).

Dépôt de plainte : Conservez l'archive forensique, les logs, et toute communication des attaquants. Déposez plainte auprès de la police ou gendarmerie, ou en ligne sur la plateforme THESEE (pour les escroqueries en ligne).

#10. Quand faire appel à un prestataire

Certaines situations dépassent le DIY raisonnable :

• Vous ne disposez d'aucune sauvegarde saine antérieure à la compromission
• Le vecteur d'attaque reste non identifié après analyse
• Le site traite des données de paiement ou des données de santé
• Vous suspectez une persistance (le site est re-compromis après nettoyage)
• Vous devez produire un rapport d'incident pour votre assurance cyber

Dans ces cas, un audit forensique par un prestataire certifié est nécessaire. M-KIS réalise des diagnostics de sécurité post-incident incluant analyse forensique des logs, identification du vecteur, rapport d'incident documenté et plan de remédiation — sans dépendance à des outils propriétaires cloud américains.

Pour les PME qui souhaitent éviter de se retrouver dans cette situation, un audit de sécurité préventif reste la meilleure option. Notre audit gap ISO 27001 (5 à 12 K€ HT) couvre notamment la sécurité des applications web et la gestion des sauvegardes.

Récapitulatif des priorités par ordre chronologique :

1. Isoler et changer tous les mots de passe
2. Sauvegarder l'état infecté (forensique)
3. Identifier le vecteur avant de nettoyer
4. Réinstaller le core depuis les sources officielles
5. Nettoyer ou restaurer la base de données
6. Scanner et valider l'état post-nettoyage
7. Durcir avant remise en ligne
8. Notifier si données personnelles exposées