Mon site est hacké : que faire ?

Votre site est compromis — ou vous pensez qu'il l'est. Cette doc vous donne la marche à suivre dans l'ordre, sans brûler d'étapes. L'enjeu : contenir le plus vite possible, puis remettre d'aplomb proprement, et enfin comprendre ce qui s'est passé pour que ça ne se reproduise pas.

1. Détecter — les signaux

Les symptômes classiques, seuls ou combinés :

• Défigurement — la page d'accueil affiche autre chose que votre contenu (message de groupe, pub illicite, drapeau).
• Redirections inattendues — le site renvoie vers un domaine étranger, souvent uniquement pour certains user-agents (mobile, Googlebot) ou via referrer.
• Alerte Google Safe Browsing — page rouge « Site trompeur » dans Chrome/Firefox, ou dropout du site des résultats Google.
• Pics CPU ou bande passante — le site se met à consommer anormalement : cryptomineur planqué, botnet qui utilise le serveur.
• Envois de spam — vous recevez des bounces d'emails que vous n'avez pas envoyés, ou l'IP du serveur apparaît en blacklist (Spamhaus, SpamCop).
• Logs anormaux — accès admin depuis un pays improbable, requêtes POST vers des URL inconnues, nouveaux comptes utilisateur admin.
• Fichiers modifiés récents inexpliqués, en particulier wp-config.php, thèmes, plugins, .htaccess, ou de nouveaux fichiers PHP dans wp-content/uploads/.
• Signalement par un client ou un visiteur — souvent le premier canal d'alerte.

2. Confiner — bloquer la fuite

L'objectif : arrêter les dégâts en cours (exfiltration, spam, propagation), tout en préservant les preuves.

2.1 Alerter Datacampus

Ouvrez un ticket en qualifiant URGENT ou appelez au 05 16 64 00 75. Donnez : URL concernée, symptômes, heure de constat, ce que vous avez déjà fait ou pas. On peut :

• Isoler la VM du réseau le temps de l'analyse.
• Basculer un snapshot en lecture seule pour préserver les preuves.
• Scanner côté serveur avec nos outils (maldet, antivirus, analyse de logs).
• Proposer une restauration depuis un backup antérieur au compromis.

2.2 Couper le site si nécessaire

Si le site sert de relais (redirection malveillante, phishing, spam), on le coupe ou on le bascule sur une page maintenance. Ça casse l'activité mais ça limite la casse juridique et la réputation. Exemple d'un .htaccess de maintenance :

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteCond %{REMOTE_ADDR} !^VOTRE\.IP\.FIXE\.ICI$
RewriteRule .* /maintenance.html [R=503,L]
ErrorDocument 503 /maintenance.html

Avec une IP fixe en exception, vous gardez l'accès pour nettoyer.

2.3 Changer tous les mots de passe — depuis une machine saine

On change dans cet ordre, depuis un poste de confiance (pas celui qui pourrait être infecté, pas depuis le site admin si on soupçonne un keylogger) :

1. Mot de passe Plesk / espace client.
2. Mots de passe SSH / SFTP (et mieux : régénérer les clés SSH).
3. Mot de passe base de données (penser à mettre à jour wp-config.php en même temps).
4. Mots de passe admin CMS (WordPress, Prestashop, etc.) — pour tous les comptes, pas seulement le vôtre.
5. Mots de passe FTP.
6. Mots de passe email associés au site (pour reset).
7. Clés API tierces (Stripe, Mailjet, SendGrid, etc.) — révocation puis régénération.

3. Investiguer — identifier le compromis

3.1 Scanner

• WordPress — plugin Wordfence (scan malware + diff fichiers core), WP-CLI : wp core verify-checksums, wp plugin verify-checksums --all.
• Côté serveur — Datacampus peut lancer maldet (Linux Malware Detect) et ClamAV sur vos fichiers.
• Scan externe — Sucuri SiteCheck, VirusTotal (URL), URLScan.io.

3.2 Chercher les fichiers modifiés récemment

# Fichiers modifiés dans les 7 derniers jours
find /var/www/site -type f -mtime -7 -ls

# Uniquement les .php suspects
find /var/www/site -type f -name "*.php" -mtime -7 -ls

# Fichiers créés récemment dans uploads (zone classique de dépôt)
find /var/www/site/wp-content/uploads -type f -mtime -30 -name "*.php"

Un .php dans uploads/ est presque toujours anormal. Un PNG avec du PHP à l'intérieur (polyglot) se détecte avec file + grep <?php.

3.3 Comparer à une version saine

Si le code est versionné (Git) :

# Fichiers modifiés par rapport au dernier tag / commit sain
git status
git diff HEAD -- wp-content/themes/
git fsck

Si pas de Git, téléchargez la version officielle du CMS/plugins/thèmes et comparez (diff -r, rsync --dry-run --itemize-changes).

3.4 Examiner les logs

• Access log Apache/nginx — rechercher les requêtes POST vers les fichiers suspects identifiés en 3.2, les User-Agents anormaux, les bursts de requêtes.
• Error log — traces d'exécution de scripts inattendus.
• Logs auth (SSH, Plesk) — connexions réussies depuis IP inhabituelles.
• Logs CMS — WordPress activité (plugin WP Activity Log si installé), historique Prestashop.
• Comptes utilisateurs admin — lister ceux de la base, chercher les comptes récents ou inconnus.

4. Nettoyer ou restaurer

Deux voies. La deuxième est presque toujours préférable.

4.1 Restaurer un backup antérieur au compromis (recommandé)

C'est propre, rapide, sans doute : on remet une version saine, datée. L'enjeu critique est de connaître la date du compromis — restaurer un backup postérieur au premier hack ne sert à rien.

1. Identifier la date du compromis (modification de fichiers, création de user admin, entrée en log).
2. Choisir un backup antérieur à cette date.
3. Restaurer (Datacampus s'en charge sur les offres infogérées).
4. Appliquer immédiatement tous les correctifs de sécurité manquants sur la version restaurée, avant de remettre en ligne.
5. Changer tous les mots de passe une nouvelle fois (le backup restauré contient les anciens).
6. Réinjecter uniquement les données post-backup dont vous êtes sûr qu'elles sont saines (commandes, inscriptions, contenu éditorial).

4.2 Nettoyer en place (si pas de backup exploitable)

Plus risqué, plus long, moins sûr. Dans cet ordre :

1. Supprimer les backdoors identifiées (fichiers PHP inconnus, web shells, uploads vérolés).
2. Réinstaller le core du CMS depuis la source officielle, en écrasant : wp core download --force pour WordPress.
3. Réinstaller tous les plugins et thèmes depuis leur source officielle. Les thèmes nullés et plugins piratés sont l'une des causes n°1 : les remplacer par des versions légitimes ou les supprimer.
4. Purger les comptes admin inconnus, régénérer les salts (ex : wp config shuffle-salts).
5. Inspecter la base : plugin auto-install caché, options contenant du code (wp_options, wp_usermeta), injections en post_content.
6. Régénérer le sitemap, soumettre à Google Search Console en vérifiant « Problèmes de sécurité ».

5. Post-mortem — comprendre pour éviter la récidive

Un incident qui se répète signifie que la cause racine n'a pas été traitée. Questions à se poser :

• Plugin/thème vulnérable ? — comparer la liste installée avec les CVE récentes (WPScan, patchstack.com).
• Mot de passe faible ou réutilisé ? — brute-force, credential stuffing.
• Compte admin compromis ? — machine du compte infectée, phishing.
• Version de CMS/PHP obsolète ? — MAJ retardées.
• Permissions fichiers trop larges ? — 777 vu dans l'arborescence.
• Injection SQL / LFI non filtrée ? — souvent liée à un plugin ancien.
• Secrets exposés ? — .env, .git, backups .sql dans le docroot.

Durcissement post-incident

• MAJ auto du core et des plugins critiques activée.
• 2FA sur tous les comptes admin, sans exception.
• Limite de tentatives de connexion (fail2ban, plugin Limit Login Attempts Reloaded).
• WAF applicatif (Wordfence, Imunify côté Plesk, Cloudflare).
• Scan régulier (hebdo) avec alerte.
• Backups testés : une restauration par trimestre au moins.
• Revue de l'arbre des permissions et des comptes utilisateur.

Voir la doc Hardening général : les essentiels pour la checklist complète. Pour WordPress spécifiquement, voir la doc WordPress : hardening.

Obligations légales

Si des données personnelles sont compromises (fuite, exfiltration), vous avez une obligation RGPD : notification à la CNIL sous 72 h (cnil.fr) et information des personnes concernées si risque élevé. C'est une décision que vous prenez (Datacampus est sous-traitant au sens RGPD), mais nous vous fournissons les éléments techniques nécessaires (dates, périmètre, preuves).

Plainte possible auprès de la police / gendarmerie (plateforme Thésée). Signalement à l'ANSSI via cybermalveillance.gouv.fr pour les incidents significatifs.