En bref : si votre site a été piraté, cette liste de contrôle aide à ne rien oublier : d'abord contenir et préserver les preuves, puis trouver la cause et nettoyer, ensuite renouveler tous les accès, vérifier les obligations et clore l'incident de façon documentée. L'ordre est important, car qui supprime d'abord perd des traces, et qui nettoie sans fermer la faille sera de nouveau attaqué.
À quoi sert cette liste de contrôle lorsque le site a été piraté
La liste de contrôle s'adresse à la direction, aux propriétaires et aux responsables informatiques après une attaque confirmée ou probable contre un site web, une boutique ou un serveur web PHP. Elle convient aussi après PHP2Shell, lorsqu'un serveur était accessible avant la mise à jour et qu'il existe des indices de compromission.
Tous les points ne conviennent pas à tous les environnements. Parcourez néanmoins la liste en entier et notez pour chaque point s'il est fait, sans objet ou ouvert. Ce journal sera précieux plus tard pour l'assurance, la protection des données et le bilan interne.
Consignez pour chaque étape la date, l'heure, la personne responsable et le résultat. Si plusieurs personnes sont impliquées, désignez une personne qui tient la liste et consigne les décisions.
Phase 1 : contenir et sauvegarder immédiatement
- Limiter les dégâts : mettre le site en mode maintenance ou hors ligne si des visiteurs sont menacés ou si des données risquent de fuiter. Pour PHP2Shell, le BSI (office fédéral allemand de la sécurité des technologies de l'information) recommande de déconnecter temporairement les serveurs web non corrigés si une mise à jour n'est pas possible immédiatement.
- Ne rien supprimer : ne retirer aucun fichier, ne pas réinstaller le serveur et ne vider aucun journal avant que les traces soient sauvegardées.
- Sauvegarder les journaux : copier les journaux d'accès, d'erreurs, PHP-FPM et système sur un autre système et consigner les sommes de contrôle. Pour PHP2Shell, la presse spécialisée conseille de conserver les journaux à partir du 20 octobre 2026.
- Sauvegarder une image : créer une copie des fichiers et de la base de données, et pour les serveurs virtuels un instantané, comme état de preuve, et ne pas la modifier.
- Informer les responsables : associer tôt la direction, le délégué à la protection des données, l'hébergeur et, le cas échéant, l'assurance cyber. De nombreuses assurances imposent des obligations de déclaration.
Phase 2 : trouver la cause et nettoyer
- Déterminer le point d'entrée : analyser les journaux, les modifications de fichiers et les versions. Vérifiez PHP lui-même, le CMS, les thèmes, les extensions, les identifiants et les services du serveur. Sans cause connue, le risque d'une nouvelle attaque subsiste.
- Fermer la faille : amener PHP à une version corrigée (8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou backport confirmé du fournisseur), mettre à jour le CMS et les extensions, redémarrer tous les workers PHP.
- Délimiter la période : déterminer le moment le plus précoce d'une activité suspecte. Il décide quelles sauvegardes peuvent être saines et quelles données peuvent être concernées.
- Supprimer les portes dérobées : vérifier et supprimer webshells, fichiers PHP étrangers dans les dossiers d'upload et de cache, fichiers du noyau modifiés, tâches cron, clés SSH et services système. Remplacer les fichiers du noyau à partir d'une source saine.
- Nettoyer la base de données : supprimer les comptes administrateur inconnus, les scripts introduits dans les contenus et les paramètres ainsi que les contenus de spam.
- Envisager une reconstruction : en cas de compromission profonde du serveur, une reconstruction sur un système neuf et corrigé avec des données vérifiées est souvent la voie la plus fiable par rapport à un nettoyage sur le système en cours d'exécution.
Phase 3 : renouveler les accès et renforcer
- Changer les mots de passe : pour le CMS, le compte d'hébergement, le panneau, la base de données, FTP, SFTP, SSH et la messagerie, et ce depuis un appareil sain.
- Remplacer clés et jetons : régénérer les clés d'API, les interfaces des services de paiement et d'expédition, les clés d'application du CMS, les clés SSH et les certificats qui se trouvaient sur le serveur.
- Terminer les sessions : déconnecter toutes les connexions actives dans le CMS et chez les services, et vérifier les appareils à deux facteurs enregistrés.
- Activer l'authentification à deux facteurs : pour tous les accès administrateur, y compris l'hébergement, le domaine et le DNS.
- Renforcer le serveur : vérifier et documenter les réglages PHP, les droits des fichiers, les blocages d'exécution dans les dossiers d'upload, le pare-feu et les en-têtes de sécurité.
Phase 4 : obligations, communication et clôture
- Vérifier les obligations de notification : si des données personnelles peuvent être concernées, une notification dans les 72 heures au titre de l'art. 33 du RGPD peut être nécessaire. L'évaluation relève du délégué à la protection des données ou d'un avocat. Vérifier séparément les obligations sectorielles, par exemple au titre de NIS2.
- Envisager une plainte : les Zentrale Ansprechstellen Cybercrime (points de contact centraux allemands pour la cybercriminalité) de la police prennent les plaintes des entreprises. Les journaux sauvegardés en sont une base importante.
- Informer clients et Google : informer les personnes concernées de façon factuelle et concertée. Si Google affiche une alerte, demander le réexamen après le nettoyage, comme décrit sous Supprimer l'alerte Google.
- Documenter la clôture et surveiller : consigner dans un rapport la cause, la période, les mesures et les points ouverts, en tirer des enseignements pour le plan d'urgence et surveiller les systèmes de façon renforcée dans les semaines qui suivent.
Erreurs fréquentes lors du suivi
De nombreux incidents s'éternisent parce que, dans la première agitation, on économise au mauvais endroit ou on agit trop vite. Vous devriez éviter ces erreurs :
- Ne supprimer que ce qui est visible : une page de spam supprimée ou une redirection retirée n'est pas la preuve d'un site sain. Les portes dérobées passent souvent inaperçues.
- Changer les mots de passe depuis le système touché : si un logiciel malveillant tourne encore sur l'ordinateur ou le serveur, les nouveaux identifiants peuvent aussitôt fuiter de nouveau.
- Restaurer une sauvegarde à l'aveugle : sans faille fermée et sans vérification de la sauvegarde, l'attaquant se retrouve vite à la porte.
- Comprendre le correctif comme une levée d'alerte : une mise à jour vers une version de PHP corrigée ne prouve pas que rien ne s'est produit avant et ne supprime aucun logiciel malveillant introduit.
- Vérifier les obligations trop tard : les délais commencent avec la prise de connaissance de l'incident, pas avec la fin du nettoyage.
- Aucune documentation : sans journal, les questions de l'assurance, des autorités ou des clients sont difficiles à traiter plus tard.
Cette liste de contrôle ne remplace pas un conseil juridique. Pour des questions d'obligations de notification, de responsabilité ou d'assurance, adressez-vous à votre délégué à la protection des données, à un avocat ou à votre assureur.
Comment PHP SOS aide-t-il concrètement ?
- Nous assurons la réponse à incident structurée et suivons la liste de contrôle avec vous, point par point, avec un journal.
- Nous sauvegardons journaux et états du système de façon à ce qu'ils restent utilisables pour l'assurance, les autorités et une éventuelle analyse forensique informatique.
- Nous fermons la faille, nettoyons ou reconstruisons et renouvelons les accès dans le bon ordre.
- Nous livrons un rapport final avec la cause, les mesures et les recommandations et, sur demande, surveillons ensuite les systèmes.
Questions fréquentes
Quelle est la première chose à faire si mon site a été piraté ?
Garder son calme, ne rien supprimer et limiter les dégâts. Mettez au besoin le site hors ligne ou en mode maintenance et sauvegardez journaux et fichiers avant de nettoyer. Viennent ensuite la recherche de la cause et le nettoyage.
Suffit-il de restaurer le site à partir d'une sauvegarde ?
Le plus souvent non. La sauvegarde peut déjà contenir du code malveillant, et la faille par laquelle l'attaquant est entré est encore ouverte après la restauration. Fermez d'abord la cause, puis restaurez un état vérifié et sain sur un système mis à jour.
Dois-je signaler un piratage à l'autorité de protection des données ?
Si des données personnelles peuvent être concernées, l'art. 33 du RGPD prévoit en principe une notification dans les 72 heures suivant la prise de connaissance, sauf si un risque pour les personnes concernées est peu probable. L'évaluation relève de votre délégué à la protection des données ou d'un avocat.
Quand un incident est-il vraiment clos ?
Lorsque la cause est fermée, que toutes les portes dérobées connues sont supprimées, que les accès sont renouvelés, que les obligations sont remplies et que les mesures sont documentées. Une période de surveillance renforcée ensuite en fait partie, afin de repérer d'éventuelles traces négligées.