En bref : la forensique informatique de serveur répond à la question de ce qui s'est réellement passé lors d'une attaque : quand, comment, avec quelles conséquences. Avec des partenaires spécialisés en forensique, nous préservons les traces avec valeur probante, analysons journaux, systèmes de fichiers et bases de données, et livrons un rapport traçable. Il sert de base aux notifications, à l'assurance et, le cas échéant, aux poursuites pénales.
Quand vous avez besoin de forensique informatique pour votre serveur
Tous les incidents n'exigent pas une enquête forensique. Elle est surtout judicieuse lorsque des données personnelles, des données de paiement ou des secrets d'affaires risquent d'être concernés, lorsqu'une plainte ou un litige est prévisible ou lorsqu'un assureur attend une preuve solide. Pour savoir si une notification à l'autorité de contrôle est nécessaire aussi, des faits établis aident davantage que des suppositions.
Après PHP2Shell s'ajoute un point particulier. Les failles CVE-2026-109618 et CVE-2026-109619 permettent l'exécution de code sans authentification, et il n'existe pas d'indicateurs de compromission (IOC) publiés et confirmés. Savoir si un serveur a été touché ne se coche donc pas sur une liste de contrôle, mais ne peut s'établir que par l'analyse comportementale : quels processus tournaient, quels fichiers sont apparus, quelles connexions sont parties vers l'extérieur ? Suis-je déjà compromis ? donne de premiers repères.
Ce qui distingue la forensique d'un nettoyage rapide
Le nettoyage veut rendre le serveur de nouveau sain. La forensique veut comprendre et prouver. L'une des questions est « Le serveur est-il de nouveau sûr ? », l'autre « Que s'est-il exactement passé, et quelles données étaient accessibles ? ». Pour les notifications, l'assurance et l'information des clients, la seconde question est généralement décisive. Les deux sont compatibles si l'ordre est respecté : d'abord sauvegarder, ensuite modifier. Quiconque commence par supprimer, corriger ou redémarrer perd des traces volatiles et ne peut souvent plus montrer par la suite ce que l'attaquant a vu.
Conservez tous les journaux du serveur à partir du 20 octobre 2026 et demandez à votre hébergeur de ne pas faire tourner ni supprimer les journaux. Des journaux manquants sont la cause la plus fréquente de questions ouvertes dans le rapport.
Quelles traces comptent sur un serveur web PHP
Sur un serveur web typique, il y a plus de traces que de nombreux exploitants ne le supposent. Leur exploitabilité dépend de leur durée de conservation et du fait qu'elles aient été sauvegardées avant l'intervention.
- Journaux d'accès et d'erreurs du serveur web et de PHP-FPM, y compris les workers qui ont planté
- Système de fichiers : fichiers nouveaux ou modifiés, leurs horodatages et propriétaires, code exécutable dans les dossiers d'envoi
- Base de données : nouveaux comptes utilisateur, paramètres modifiés, contenus introduits
- Système : tâches cron, utilisateurs, clés SSH, journaux de connexion, processus en cours et connexions réseau
- Systèmes en amont : journaux du CDN, du WAF, du pare-feu, de l'équilibreur de charge et du serveur de messagerie
Ce sont précisément les systèmes en amont que l'on oublie souvent. Ils se trouvent en dehors du serveur web et sont donc plus difficiles à manipuler pour un attaquant. Chez certains fournisseurs, ils ne sont conservés que peu de temps ; vous devriez donc les exporter tôt.
Comment PHP SOS aide-t-il concrètement ?
- Clarifier la mission : nous définissons avec vous les questions auxquelles il faut répondre, par exemple porte d'entrée, période, données concernées ou déplacement latéral dans le réseau. Il en résulte quels systèmes sont examinés.
- Sauvegarder avec valeur probante : nos partenaires spécialisés et nous-mêmes créons des copies de supports de données, de journaux, de bases de données et, si possible, de la mémoire vive. Chaque sauvegarde reçoit une somme de contrôle, chaque transmission est documentée.
- Analyser : nous analysons les journaux d'accès et d'erreurs, les modifications de fichiers, les comptes utilisateur, les tâches cron, les processus et les connexions sortantes. La méthodologie pour les journaux est décrite dans Analyser les journaux du serveur web après une attaque.
- Établir la chronologie : à partir des découvertes naît une chronologie de l'incident, dans laquelle chaque affirmation renvoie à une preuve concrète.
- Remettre le rapport : vous recevez un rapport technique et une synthèse compréhensible pour la direction.
Ce que vous recevez et ce dont nous avons besoin
Le rapport contient les éléments de preuve sauvegardés avec leurs sommes de contrôle, la documentation de la chaîne de transmission, la chronologie, la porte d'entrée établie ou probable, les systèmes et types de données concernés ainsi que des recommandations. Chaque affirmation est marquée comme établie, probable ou inconnue.
De votre part, nous avons besoin de :
- l'accès aux systèmes concernés ou l'autorisation que votre hébergeur nous fournisse des copies
- une personne habilitée à décider, qui définit l'ampleur et les priorités
- des informations sur le paysage des systèmes, les prestataires et les modifications connues des dernières semaines
- les journaux existants, y compris ceux des pare-feu, du CDN, du WAF ou des serveurs de messagerie
- l'indication de savoir si l'assureur, la police ou un avocat sont déjà impliqués
Si vous souhaitez déposer plainte, vous trouverez des indications sous Déposer plainte : points de contact centraux pour la cybercriminalité. Ce que les assureurs attendent typiquement en cas de sinistre, Cyberassurance : ce qui compte en cas de sinistre l'explique.
Ce que nous ne promettons pas
La forensique ne peut analyser que les traces qui existent. Si des journaux manquent, ont été écrasés ou manipulés par l'attaquant, des lacunes subsistent, et nous les signalons. Nous ne promettons pas qu'un tribunal appréciera nos résultats d'une manière déterminée, et nous ne donnons pas d'appréciation juridique. Nous ne désignons pas de coupables, mais décrivons ce que les traces montrent. Des affirmations comme « aucune donnée n'a sûrement fuité », nous ne les formulons que si les preuves les soutiennent.
Si l'attaque est encore en cours, le confinement a la priorité. Nous commençons alors par la réponse aux incidents et sauvegardons en parallèle autant de traces que possible.
Questions fréquentes
Que signifie une préservation des preuves recevable devant un tribunal ?
Les traces sont sécurisées de telle sorte qu'il soit possible de démontrer ensuite qu'elles sont inchangées. Cela comprend des sommes de contrôle, une chaîne de transmission documentée et le travail sur des copies plutôt que sur l'original. Savoir si un tribunal retient un élément de preuve relève toutefois de sa décision.
La forensique informatique peut-elle établir si des données clients ont fuité ?
Il est souvent possible de cerner à quelles données un attaquant a eu accès et s'il existe des indices d'exfiltration. Une exclusion certaine n'est pas toujours possible, surtout si des journaux manquent. Le résultat est donc distingué en établi, probable et inconnu.
Combien de temps faut-il conserver les journaux ?
Pour l'élucidation, aussi longtemps que possible, au moins jusqu'à la fin de l'enquête. Pour PHP2Shell, la presse spécialisée conseille de conserver les journaux du serveur à partir du 20 octobre 2026. Les obligations légales de conservation et de suppression, vous les clarifiez avec votre délégué à la protection des données.
Puis-je redémarrer ou corriger le serveur avant la forensique ?
Un redémarrage efface les traces volatiles en mémoire vive, un correctif modifie des fichiers. Si vous le pouvez, sauvegardez d'abord ou parlez-nous brièvement. Si le danger est aigu, le confinement a la priorité, et cela est documenté.