Reconstruire une timeline d’attaque après incident

Une investigation post-incident ne livre pas une collection d’alertes, elle doit livrer une chronologie défendable des actions adverses. La timeline d’attaque relie les traces techniques, expose les ruptures de visibilité et permet de distinguer un accès isolé d’une compromission étendue.

→ Lire l’explication complète de la marmotte

La timeline comme livrable d’investigation

La timeline est le livrable central : une suite d’événements horodatés, sourcés, normalisés et qualifiés par un niveau de confiance. Elle doit répondre à quatre questions opérationnelles : quel accès initial est confirmé, quels actifs ont été touchés, quelles actions ont permis la progression, et quelles données ou capacités restent exposées.

Le compromis est net. Une timeline exhaustive coûte du temps, nécessite de préserver des sources fragiles et impose de résoudre des contradictions. Une timeline rapide permet de contenir plus tôt, mais risque de figer une hypothèse séduisante avant d’avoir les preuves. La bonne décision consiste à publier une timeline provisoire dès que les mesures de confinement en dépendent, puis à la versionner. Attendre une certitude totale revient souvent à attendre l’expiration des journaux. C’est une stratégie de conservation étonnamment populaire pour quelque chose qui s’appelle une investigation.

Chaque ligne doit contenir au minimum :

l’horodatage brut tel qu’observé ;
l’horodatage normalisé en temps universel coordonné (UTC) ;
la source, l’identifiant de l’événement et l’actif émetteur ;
le fait observé, séparé de son interprétation ;
le niveau de confiance : confirmé, probable, possible ou inconnu ;
le lien vers la preuve conservée et son empreinte cryptographique ;
la technique MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) éventuellement associée.

Ne pas mélanger fait et hypothèse. « Une connexion VPN a été acceptée pour le compte X depuis l’adresse Y » est un fait si le journal VPN l’établit. « L’attaquant a utilisé le compte X » reste une interprétation tant que l’attribution de l’adresse, du jeton ou du poste n’est pas corroborée. Cette séparation évite qu’une phrase écrite à 3 h 12 devienne une vérité architecturale gravée dans le marbre.

Les principes de réponse aux menaces s’appliquent ici : le confinement prime sur l’élégance du récit. En revanche, modifier un poste compromis pour obtenir un détail esthétique de plus dégrade parfois la seule preuve qui comptait.

Normalisation des horodatages et dérive d’horloge

Une heure sans fuseau horaire est une donnée incomplète. Les journaux applicatifs affichent souvent une heure locale, les équipements réseau utilisent UTC, les exports d’Endpoint Detection and Response (EDR) affichent l’heure du navigateur, et les pare-feu peuvent conserver l’heure reçue d’un serveur Network Time Protocol (NTP) défaillant. Additionner ces dates dans un tableur sans modéliser leur origine produit une fiction chronologique avec des couleurs conditionnelles.

Conserver trois champs distincts : timestamp_raw, timezone_observed et timestamp_utc. Ne jamais écraser la valeur brute. La valeur normalisée est une dérivation révisable, pas l’original. Pour chaque source, documenter le fuseau configuré, le serveur NTP attendu, l’écart constaté et la méthode utilisée pour l’estimer.

La dérive se mesure par corrélation avec un événement connu sur plusieurs sources. Une authentification réussie visible à la fois dans le Virtual Private Network (VPN), l’annuaire et l’EDR fournit un point d’ancrage. Si le VPN inscrit 10:00:00 UTC, l’annuaire 10:00:07 UTC et l’EDR 09:59:43 UTC, les offsets estimés sont respectivement 0, +7 et -17 secondes. Il faut ensuite exprimer l’incertitude, par exemple ± 5 s ou ± 2 min, selon la qualité de l’ancrage et la stabilité de l’horloge.

Une dérive constante se corrige. Une horloge qui saute après un redémarrage, une virtualisation suspendue ou une perte de synchronisation ne se corrige pas par une constante. Elle impose des segments temporels distincts. Un hyperviseur qui rend l’heure de la veille avec l’assurance d’un réveil difficile n’est pas une source temporelle fiable.

Les prérequis de plateforme sont donc non négociables :

synchronisation NTP supervisée sur serveurs, postes, équipements réseau et collecteurs ;
journalisation contenant le fuseau ou une référence UTC ;
identifiants d’événement stables entre export et conservation ;
accès en lecture aux journaux applicatifs, pare-feu, VPN, annuaire et EDR ;
rétention supérieure au délai maximal de détection et d’investigation ;
stockage immuable ou à accès strictement contrôlé pour les exports d’origine.

L’observabilité réseau décrite dans la section réseaux complète la timeline, mais ne remplace pas les journaux d’identité et d’hôte. Un flux chiffré prouve une communication, rarement l’intention ou le contenu.

Corrélation des sources disparates

La corrélation robuste repose sur des pivots, pas sur une adresse IP seule. Une adresse peut être partagée par traduction d’adresse, réattribuée par Dynamic Host Configuration Protocol (DHCP), masquée derrière un proxy ou utilisée par un relais VPN. Croire qu’elle identifie une personne est le genre de raccourci qui tient très bien sur une slide et beaucoup moins bien devant un incident majeur.

Les pivots utiles sont le compte, l’identifiant de session, l’identifiant de processus, le nom d’hôte, l’adresse Media Access Control (MAC), le hachage de fichier, le certificat client, l’identifiant de requête applicative et le couple source-destination-port. Un pivot n’est acceptable que si sa portée est comprise : un identifiant de session réutilisable dans un proxy ne démontre pas l’identité humaine derrière la session.

Assembler en couches :

établir les événements d’accès : authentifications, connexions VPN, réinitialisations de mot de passe, élévations de privilèges ;
relier les exécutions observées par l’EDR aux comptes et aux hôtes ;
superposer les flux pare-feu, proxy et Domain Name System (DNS) pour identifier les communications de commande ou de transfert ;
confronter les journaux applicatifs aux actions système ;
ajouter les trous de visibilité comme des événements négatifs explicitement datés.

Une absence de journal n’est pas une absence d’activité. Elle peut provenir d’une rétention expirée, d’un agent arrêté, d’une règle de collecte restrictive ou d’un export tronqué. La différence est décisive. « Aucune preuve d’exfiltration dans les journaux proxy conservés » est défendable. « Aucune exfiltration » ne l’est pas si les journaux de sortie sont absents pendant six heures.

Exemple de normalisation reproductible

L’exemple suivant convertit un export CSV minimal vers UTC, conserve la valeur brute et applique un offset documenté. Il nécessite Python 3.11 ou supérieur et aucun paquet externe.

# Entrée attendue : source,timestamp_raw,timezone,offset_seconds,event
# Exemple : vpn,2026-09-18 10:00:00,UTC,0,login_success

import csv
from datetime import datetime, timedelta, timezone

with open("events.csv", newline="", encoding="utf-8") as source:
    reader = csv.DictReader(source)
    for row in reader:
        # Le fuseau doit être explicite : UTC ou un décalage comme +02:00.
        raw = datetime.fromisoformat(
            row["timestamp_raw"].replace(" ", "T") + row["timezone"]
        )
        corrected = raw - timedelta(seconds=int(row["offset_seconds"]))
        timestamp_utc = corrected.astimezone(timezone.utc)

        print({
            "source": row["source"],
            "timestamp_raw": row["timestamp_raw"],
            "timestamp_utc": timestamp_utc.isoformat(),
            "event": row["event"],
            "offset_seconds": row["offset_seconds"],
        })

Cet exemple n’est valable que si l’offset est constant pour la période considérée. Sinon, ajouter une table de segments de validité avec début, fin, offset et méthode de mesure. Un script qui corrige tout l’historique avec +3600 secondes est rapide, reproductible et faux avec une efficacité presque industrielle.

Cartographie MITRE ATT&CK et communication de l’ampleur

MITRE ATT&CK sert à classer les comportements, non à prouver qu’ils ont eu lieu. Une technique doit être associée à une ligne de preuve ou à une hypothèse explicitement marquée. Mapper une alerte de détection à quinze techniques parce qu’un produit a coché des cases transforme le référentiel en horoscope pour centre opérationnel de sécurité.

Pour une direction non technique, présenter la progression par objectifs :

Phase	Éléments à communiquer	Preuve attendue
Accès initial	Point d’entrée et population exposée	Connexion, courriel, exploit ou jeton observé
Exécution	Code ou commande déclenchée	Processus, tâche, journal applicatif
Persistance	Mécanisme survivant à une session	Service, compte, tâche planifiée, règle
Mouvement latéral	Actifs atteints depuis le point initial	Authentification, flux, exécution distante
Exfiltration	Données préparées ou sorties	Archive, transfert, volume, destination

Le message dirigeant doit distinguer trois périmètres : confirmé, probablement atteint, non déterminable. Cette dernière catégorie n’est pas une faiblesse rédactionnelle. C’est la frontière exacte de la capacité de preuve. Elle permet de décider des investigations complémentaires, des rotations d’identifiants et des notifications internes sans vendre une reconstruction totale sortie d’un chapeau.

Une compromission de compte ne garantit pas la compromission du poste associé. Une exécution distante ne garantit pas l’accès aux données. Une connexion sortante vers Internet ne garantit pas l’exfiltration. Chaque transition de la kill chain doit porter sa preuve propre.

Incertitude, surface d’attaque et exploitation durable

Le rapport doit comporter une section d’incertitude avec, pour chaque zone aveugle, la période, la cause, l’effet sur les conclusions et la mesure corrective. Exemples : « Journaux VPN indisponibles entre 01:00 et 05:00, rétention expirée, impossibilité de borner les connexions initiales » ; « Agent EDR absent sur trois serveurs, exécution locale non observable ».

La surface d’attaque de la reconstruction comprend les journaux eux-mêmes. Un adversaire peut effacer des traces, altérer l’heure système, désactiver un agent EDR, injecter des événements trompeurs ou utiliser des comptes de service légitimes. Les contre-mesures sont la collecte centralisée, le contrôle d’accès séparé, l’immutabilité, l’alerte sur arrêt d’agent, la surveillance de dérive NTP et la comparaison de sources indépendantes. Le journal local administré par le même compte compromis n’est pas une preuve autonome.

La timeline ne garantit ni l’attribution à une personne, ni l’absence d’activité hors rétention, ni l’intégrité d’une source déjà compromise. Le reste doit venir de la conservation de preuve, de l’analyse des systèmes, des sauvegardes, des journaux externes et des décisions de réponse au risque.

En exploitation, préserver les exports bruts, chiffrer les archives, limiter les accès et conserver les clés de chiffrement dans un processus distinct des données. Tester régulièrement la restauration des journaux et la disponibilité des index. Une sauvegarde de logs non restaurable est un monument discret à l’optimisme opérationnel. Superviser le délai d’ingestion, la perte d’événements, le taux d’agents actifs, la rétention effective et les écarts d’horloge.

🐝 Ce qui arrive si on s’en passe

Sans chronologie sourcée et versionnée, le périmètre de remédiation se décide au jugé : le confinement s’arrête au premier actif découvert, les mécanismes de persistance posés ailleurs survivent, et les rotations d’identifiants ne couvrent que les comptes déjà visibles. Faute de date d’accès initial bornée, la reprise devient un pari : une restauration choisie après la compromission réinjecte les tâches planifiées et les comptes créés par l’adversaire, et l’incident recommence avec le même chemin d’entrée. Les obligations de notification s’appuient alors sur des heures locales non comparables, impossibles à défendre. Enfin, aucune zone aveugle n’étant consignée, les mêmes lacunes de collecte (agent absent, rétention trop courte, horloge dérivante) se retrouvent intactes lors de l’incident suivant, et aucune règle de détection durable n’en sort.

🦫 Explication de la marmotte 🍫

Après une intrusion, il faut établir l’ordre des actions réalisées : entrée dans le système, lancement de programmes, maintien d’un accès, passage vers d’autres machines et éventuelle sortie de données. Pour cela, on collecte les enregistrements produits par les applications, les postes de travail, les connexions distantes et les équipements qui filtrent les communications.

Chaque enregistrement garde son heure d’origine, car cette valeur peut servir plus tard à vérifier le travail. Ensuite, les heures sont converties vers une même référence de temps. Cette conversion dépend du fuseau horaire et de l’écart éventuel de l’horloge de chaque machine. Quand cet écart est inconnu ou change pendant la période étudiée, la date reste approximative et cette limite doit être écrite.

Les événements sont reliés avec des éléments communs : un compte, une machine, une connexion, un programme ou une communication. Une seule trace ne suffit pas toujours. Une connexion acceptée prouve un accès, mais pas toutes les actions réalisées ensuite. Il faut donc chercher une confirmation dans d’autres enregistrements.

Le résultat sépare ce qui est démontré, ce qui est probable et ce qui ne peut pas être déterminé. Si des enregistrements ont disparu ou n’ont jamais été conservés, aucune reconstruction ne peut les remplacer. Cette absence doit apparaître dans le rapport, avec ses conséquences. Cela permet de décider quelles machines examiner, quels accès désactiver et quelles données protéger sans prétendre savoir davantage que les preuves ne le permettent.

Pages voisines

La citent

Reconstruire une timeline d'attaque après incident

Elle cite