En bref : la chronologie d'un incident informatique classe toutes les observations, décisions et mesures dans l'ordre chronologique, dans un fuseau horaire uniforme, idéalement l'UTC. Chaque ligne indique la source, l'observation, la preuve et une évaluation : prouvé, probable ou inconnu. On obtient ainsi une image compréhensible du moment où l'attaquant était dans le système, de ce qu'il a pu atteindre et du moment où vous en avez eu connaissance.
Pourquoi, à la fin, tout le monde demande « quand »
Après un incident, les questions viennent de toutes parts. Le délégué à la protection des données veut savoir depuis quand des données personnelles étaient accessibles. L'assureur demande quand le dommage a été découvert et déclaré. La direction souhaite savoir si la faille était déjà ouverte avant la dernière mise à jour. Toutes ces questions ont un point commun : elles portent sur des instants.
Sans chronologie, chacun répond à ces questions de mémoire, et les réponses se contredisent. Avec une chronologie bien tenue, il existe une base commune à laquelle tous les participants se réfèrent. Elle constitue aussi l'ossature du rapport final.
Avec PHP2Shell, la chronologie est particulièrement parlante, car les dates clés publiques sont bien documentées. Elles peuvent servir de points d'ancrage à côté de vos propres observations. La séquence complète des événements publics est décrite dans le guide PHP2Shell : la chronologie.
La structure : les colonnes dont une chronologie a besoin
Un tableau suffit, dans un tableur ou dans un document partagé. L'important, ce sont des colonnes fixes, remplies pour chaque ligne. Le modèle suivant montre les dates clés publiques de PHP2Shell comme ancrages et, en dessous, des entrées propres typiques sous forme de marqueurs :
| Heure (UTC) | Source | Observation | Preuve | Évaluation |
|---|---|---|---|---|
| 17 octobre 2026 | Reportages médiatiques | première tentative d'attaque observée sur PHP2Shell | article de presse | prouvé en tant que reportage médiatique |
| 20 octobre 2026 | php.net | annonce préalable des mises à jour de sécurité | avis sur php.net | prouvé |
| 21 octobre 2026, 14:00 | php.net | publication des versions 8.5.12, 8.4.27, 8.3.36, 8.2.35 | avis sur php.net | prouvé |
| heure propre | journal d'accès | multiplication d'erreurs 500 sur des pages normales | extrait de journal, numéro de ligne | probablement pertinent |
| heure propre | système de fichiers | nouveau fichier PHP dans le dossier d'upload | copie avec somme de contrôle | prouvé, moment incertain |
| heure propre | interne | incident remarqué, direction informée | e-mail, note d'entretien | prouvé |
| heure propre | interne | mise à jour appliquée, tous les workers redémarrés | journal des paquets, liste des processus | prouvé |
La colonne Évaluation est la partie la plus importante. Elle sépare ce qui est démontré, ce qui paraît plausible et ce qui reste ouvert. Les lecteurs ultérieurs voient ainsi immédiatement où la chronologie est solide et où il y a des lacunes.
Chronologie d'un incident informatique : rassembler les sources
Les entrées proviennent de nombreuses sources, qui ont chacune leurs formats et fuseaux horaires. Procédez dans cet ordre :
- Fixer le fuseau horaire : tout tenir en UTC. Le passage à l'heure d'hiver le 25 octobre 2026 décale d'une heure les heures locales allemandes au milieu de la période. Qui mélange des heures locales décale des événements sans s'en apercevoir.
- Vérifier les horloges : l'horloge du serveur était-elle à l'heure ? Une comparaison avec un événement connu, par exemple votre propre connexion, révèle les écarts.
- Sources externes d'abord : les journaux du CDN, du WAF, de l'hébergeur ou du pare-feu se trouvent en dehors du serveur et sont difficiles à manipuler. Ils forment l'ossature.
- Compléter avec les journaux du serveur : serveur web, PHP-FPM, connexions, journal système. La méthode est décrite dans Analyser les journaux du serveur web après une attaque.
- Situer le système de fichiers : ajouter comme indices les horodatages des fichiers nouveaux et modifiés.
- Inscrire les événements internes : quand quelque chose a-t-il été remarqué, qui a été informé, quelle décision a été prise et quand ?
Ce que révèlent les horodatages de fichiers et ce qu'ils ne révèlent pas
Linux enregistre pour chaque fichier plusieurs instants, notamment la dernière modification du contenu (mtime) et la dernière modification des métadonnées (ctime). Les deux peuvent être affichés en lecture seule, ici sous forme de liste des fichiers PHP modifiés depuis une date butoir, triée par heure en UTC :
# Modifications de contenu depuis le 17.10.2026, triées, en UTC
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Tous les horodatages d'un fichier donné
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Travaillez pour cela uniquement sur une copie ou sur une image sécurisée, comme décrit dans Sécuriser les preuves avant de réinstaller. Gardez deux limites à l'esprit. Premièrement, un attaquant peut réinitialiser la date de modification d'un fichier avec des moyens simples ; un mtime discret n'est pas un acquittement. Deuxièmement, les opérations de copie et certains outils modifient les horodatages. C'est pourquoi la règle est la suivante : les heures de fichiers sont des indices, les entrées de journaux venant de l'extérieur sont des preuves.
Inscrivez le moment où votre entreprise a pris connaissance d'une possible violation de données. Selon l'art. 33 RGPD, le délai de 72 heures pour une notification court en principe à partir de la prise de connaissance. L'évaluation relève de votre délégué à la protection des données ou d'un avocat.
Erreurs typiques et comment les éviter
Les erreurs les plus fréquentes n'ont rien de spectaculaire. La chronologie n'est reconstituée de mémoire qu'à la fin, au lieu d'être tenue au fil de l'eau. Les entrées contiennent des conclusions au lieu d'observations, par exemple « l'attaquant est passé par le formulaire » au lieu de « requête POST sur le formulaire, puis nouveau fichier ». Et les preuves manquent, parce que personne n'a noté de quel fichier journal et de quelle ligne provient une entrée.
Désignez donc une personne qui tient la chronologie et inscrivez les événements dès qu'ils se produisent. Les conclusions ont leur place dans une colonne séparée ou dans le rapport, pas dans l'observation.
Traitez en outre la chronologie comme un document confidentiel. Elle contient souvent des adresses IP, des noms d'utilisateur et des indications sur des vulnérabilités. Définissez qui peut la lire et la modifier, et conservez les versions antérieures. Si une appréciation change, par exemple parce qu'un nouvel extrait de journal apparaît, l'ancienne ligne n'est pas écrasée, mais complétée. On peut ainsi retracer ce qui était connu à quel moment et sur quelle base les décisions ont été prises.
Comment PHP SOS aide-t-il concrètement ?
- Nous tenons la chronologie au fil de l'eau dès le premier contact, en UTC, avec source et preuve pour chaque entrée.
- Nous analysons ensemble journaux externes, journaux du serveur et système de fichiers et qualifions chaque affirmation de prouvée, probable ou inconnue.
- Si nécessaire, nous assurons avec des partenaires spécialisés l'analyse forensique informatique pour une exploitation recevable en justice.
- Nous remettons la chronologie dans le cadre d'un rapport destiné à la direction, à la protection des données et à l'assurance.
Questions fréquentes
À quoi me sert une chronologie après un incident de sécurité ?
Elle ordonne toutes les observations dans une séquence et montre quand l'attaquant était dans le système, ce qu'il a pu atteindre et quand vous l'avez appris. Le délégué à la protection des données, les assureurs, les autorités et la direction ont besoin de ces informations pour leurs décisions.
Dans quel fuseau horaire tenir la chronologie ?
De façon uniforme en UTC. Les serveurs, les services et les notifications utilisent des fuseaux horaires différents, et le passage à l'heure d'hiver fin octobre décale en outre les heures locales. Qui convertit tout en UTC et n'ajoute l'heure locale qu'à titre complémentaire évite les erreurs de rapprochement.
Puis-je me fier aux horodatages des fichiers ?
Seulement de façon limitée. La date de modification d'un fichier peut être falsifiée avec des moyens simples. Les entrées de journaux sont plus fiables, surtout les journaux situés en dehors du serveur concerné. Les horodatages de fichiers sont des indices qu'il convient de confirmer par d'autres sources.
Qu'est-ce qui doit figurer dans la chronologie en dehors des événements techniques ?
Aussi les décisions et la communication : quand l'incident a été remarqué, qui a été informé, quand le serveur a été déconnecté du réseau, quand le correctif a été appliqué. Le moment de la prise de connaissance est particulièrement important pour les délais de notification.