01 06Confirmez le piratage sans modifier le site

Guides · Site internet · Piratage

Site internet piraté : que faire pendant les 72 premières heures ?

Préservez les preuves, coupez l’accès public, renouvelez les accès compromis et vérifiez si des données personnelles ont été touchées. Voici les actions à mener dans l’ordre.

Par 10 min de lecturePublié le

La réponse en bref

Si votre site internet a été piraté, commencez par noter l’heure et les signes observés. Ne supprimez aucun fichier et ne restaurez pas encore de sauvegarde. Faites d’abord conserver une copie du site, de la base de données et des journaux techniques.

Coupez ensuite l’accès public au site ou placez-le derrière une page de maintenance, sans détruire l’environnement compromis. Depuis un appareil sain, renouvelez les accès à l’hébergement, à l’administration du site, au nom de domaine, à la base de données et aux services reliés. Révoquez les sessions encore ouvertes.

Dans les premières heures, demandez au prestataire d’identifier les données et les comptes auxquels l’attaquant a pu accéder. Si des données personnelles sont concernées, le délai de notification à la CNIL peut être de 72 heures. Si une assurance cyber peut couvrir l’incident, d’autres délais s’ajoutent pour la plainte et la déclaration du sinistre.

Remettez en ligne une installation reconstruite à partir de sources fiables, après avoir corrigé le point d’entrée. Restaurer une sauvegarde sans connaître la date du piratage peut réintroduire l’attaque.

Dès le premier signe

Confirmez le piratage sans modifier le site

Un site piraté n’affiche pas toujours une page de rançon. Les signes les plus visibles sont une redirection vers un autre site, une alerte du navigateur ou de la Search Console, un nouveau compte administrateur, des courriels envoyés depuis votre domaine, ou des fichiers modifiés sans intervention prévue.

Faites une capture de ce qui s’affiche et notez l’adresse de la page, la date, l’heure et la personne qui a constaté le problème. Vérifiez depuis un autre appareil sans vous reconnecter à l’administration. À ce stade, observez et conservez ; ne supprimez rien.

Dans les premières heures

Coupez l’accès public, conservez les preuves

Avant toute suppression, faites copier les fichiers du site, sa base de données et les journaux disponibles. La copie doit conserver l’état compromis tel qu’il a été découvert. Elle servira à chercher le point d’entrée et à dater les actions de l’attaquant.

Placez ensuite le site derrière une page de maintenance ou bloquez son accès public. Depuis un appareil qui n’a pas servi à administrer le site pendant l’incident, changez d’abord les accès principaux : hébergement, administration du site et nom de domaine. Révoquez les sessions actives, puis poursuivez avec la base de données, le transfert de fichiers, les clés d’API et la messagerie.

À ne pas faire

  • Réinstaller ou nettoyer le site avant d’en avoir conservé une copie
  • Restaurer une sauvegarde sans connaître la date probable de l’intrusion
  • Changer les mots de passe depuis un appareil qui peut être compromis
  • Annoncer publiquement l’origine ou l’étendue de l’attaque avant de les avoir confirmées
Voir le détail technique : conserver, nettoyer et reconstruire

Les éléments à conserver selon l’hébergement

Conservez les données avant de lancer un antivirus, de mettre à jour une extension ou de restaurer une sauvegarde. Travaillez ensuite sur une copie.

Ce qu’il faut conserver et vérifier, selon l’environnement d’hébergement.
EnvironnementÀ conserver en prioritéPoints de persistance à vérifier
WordPress ou autre CMS sur hébergement mutualiséFichiers, export complet de la base, journaux d’accès et d’erreur, liste des comptes administrateurs, historique disponible dans l’espace clientExtensions obligatoires ou inconnues, thème actif, tâches planifiées, règles de redirection, fichiers de configuration, comptes créés récemment
Serveur virtuel ou dédiéImage ou instantané du disque, journaux système et web, connexions SSH, processus et tâches planifiées, règles de pare-feuClés SSH autorisées, services ajoutés, tâches système, utilisateurs, proxy web, fichiers temporaires et mécanismes de démarrage
Infrastructure cloudInstantanés des volumes, historique des actions d’administration, journaux du répartiteur de charge, du pare-feu applicatif et du stockage, règles réseau, identités et rôlesNouvelles clés, nouveaux rôles, fonctions ou tâches planifiées, secrets modifiés, règles réseau élargies, journaux désactivés
Domaine, DNS et CDNHistorique des changements DNS, comptes et sessions, règles de redirection, cache et événements du pare-feuServeurs de noms modifiés, sous-domaines ajoutés, redirections, règles qui contournent l’origine

Renouveler les accès dans le bon ordre

  1. Depuis un appareil sain, renouvelez le compte principal de l’hébergement ou du cloud et activez l’authentification à deux facteurs.
  2. Révoquez les sessions, jetons et clés existants avant d’en créer de nouveaux.
  3. Renouvelez l’accès au nom de domaine et vérifiez les serveurs de noms.
  4. Renouvelez les comptes d’administration du site, de la base, du transfert de fichiers et de la messagerie d’envoi.
  5. Remplacez les secrets utilisés par le site : clés d’API, mots de passe de base de données, clés de signature et accès aux sauvegardes.
  6. Documentez ce qui n’a pas été renouvelé et la raison.

Valider avant la réouverture

  1. Le point d’entrée connu est fermé ou compensé par une mesure documentée
  2. Aucun compte administrateur, aucune clé et aucune tâche planifiée inconnus ne restent actifs
  3. Les fichiers exécutables viennent d’une source fiable
  4. Les contenus repris ont été contrôlés
  5. Les sessions ont été révoquées et les secrets renouvelés
  6. La journalisation et la surveillance fonctionnent
  7. Une sauvegarde post-reconstruction a été créée hors de l’environnement compromis
Le premier jour

Alertez l’hébergeur et vérifiez vos obligations

Prévenez l’hébergeur dès que la copie initiale est conservée. Demandez-lui de préserver ses propres journaux, de confirmer les actions déjà prises et de signaler tout accès inhabituel à l’espace client ou au serveur.

Si des données personnelles ont pu être perdues, modifiées ou consultées, commencez immédiatement l’évaluation nécessaire à la notification de la CNIL. Le délai peut être de 72 heures à compter de la connaissance de la violation. Vérifiez aussi le contrat d’assurance cyber : la plainte et la déclaration du sinistre suivent leurs propres délais.

Avant la reconstruction

Identifiez et fermez le point d’entrée

Recherchez d’abord les causes fréquentes : une extension ou un thème non mis à jour, un compte administrateur protégé par un mot de passe réutilisé, des identifiants d’hébergement ou de transfert de fichiers récupérés sur un autre appareil, ou une clé technique restée active.

Croisez les journaux du serveur avec les dates de modification des fichiers, les connexions à l’administration et les changements de comptes. Ne vous limitez pas aux fichiers les plus récents : certaines intrusions modifient leurs dates apparentes. Si le point d’entrée reste inconnu, dites-le clairement et renforcez la surveillance avant toute remise en ligne.

Quand le point d’entrée est fermé

Reconstruisez puis remettez en ligne

Repartez d’une installation saine. Réinstallez le système de gestion de contenu, les extensions et le thème depuis leurs sources officielles. Ne reprenez de l’ancien site que les contenus et les données contrôlés. Une sauvegarde antérieure n’est utilisable que si sa date précède l’intrusion et si sa restauration a été vérifiée.

Avant de rouvrir le site, supprimez les comptes inconnus, renouvelez les clés et mots de passe, révoquez toutes les sessions, activez l’authentification à deux facteurs sur les comptes d’administration et vérifiez les redirections, les tâches planifiées et les réglages DNS. Surveillez ensuite les nouveaux fichiers, les connexions et les erreurs.

Après la remise en ligne

Corrigez ce qui a permis l’intrusion

Rédigez un compte rendu court : point d’entrée confirmé ou probable, données touchées, accès renouvelés, composants reconstruits et actions qui restent à mener. Corrigez ensuite la cause : mises à jour, suppression des comptes inutiles, authentification à deux facteurs, séparation des accès et surveillance des erreurs.

Vérifiez enfin qu’une sauvegarde indépendante de l’hébergement peut réellement être restaurée. La fréquence des tests doit suivre le rythme de changement du site et le temps maximal de perte acceptable pour l’entreprise ; elle ne se résume pas à un chiffre identique pour tous.

Ce qu’il faut demander à votre prestataire

  1. Avez-vous conservé une copie des fichiers, de la base de données et des journaux avant toute suppression ?

    Une date, un périmètre, un emplacement et la confirmation que la copie conserve l’état compromis.

  2. Quel est le point d’entrée confirmé ou probable, et quels éléments techniques soutiennent cette conclusion ?

    Une cause nommée, une période et les journaux ou fichiers qui la rendent plausible. « Nous ne savons pas encore » vaut mieux qu’une certitude sans preuve.

  3. Quels comptes, sessions, mots de passe et clés ont été révoqués ou renouvelés ?

    Une liste exhaustive couvrant l’administration, l’hébergement, le domaine, la base, le transfert de fichiers, la messagerie et les services reliés.

  4. Quelles données personnelles ont pu être perdues, modifiées ou consultées, et quelles incertitudes restent ouvertes ?

    Une réponse par base, formulaire, compte ou espace de stockage, avec la période d’exposition estimée.

  5. Le site remis en ligne a-t-il été reconstruit depuis des sources fiables ou simplement nettoyé ?

    La liste de ce qui a été réinstallé, de ce qui a été repris et de ce qui a été contrôlé avant la réouverture.

  6. De quelle sauvegarde saine disposons-nous, et sa restauration complète a-t-elle été testée ?

    La date de la sauvegarde, la preuve qu’elle précède l’intrusion et le résultat d’un test de restauration.

Les sources