DFIR : Réponse à Incident et Forensics | Guide Expert

Le DFIR (Digital Forensics and Incident Response) est la discipline qui permet à une organisation de comprendre ce qui s'est passé lors d'un incident de sécurité, d'en limiter l'impact et d'éviter qu'il ne se reproduise. Face à des groupes APT qui opèrent pendant des semaines sans être détectés — le temps moyen de résidence d'un attaquant dans un réseau d'entreprise reste supérieur à 16 jours selon le Panorama de la cybermenace 2025 du CERTFR (CERTFR-2026-CTI-002) — la capacité à reconstituer une timeline d'attaque précise est devenue un impératif. En 2026, les équipes DFIR font face à des défis inédits : volumes de logs exponentiels avec le passage au cloud, chiffrement des communications de commande et contrôle, malwares fileless qui n'écrivent rien sur le disque, et groupes comme Lazarus ou APT28 qui effacent méthodiquement leurs traces. Cet article présente la méthodologie complète — de la préservation des preuves à la reconstruction de la chaîne de compromission — avec les outils de référence : Volatility 3 pour la mémoire, Autopsy et FTK Imager pour le disque, Zeek et Wireshark pour le réseau, et Plaso pour la super-timeline. Chaque section inclut des commandes concrètes applicables immédiatement en conditions réelles. Pour aller plus loin, consultez nos articles dédiés sur la memory forensics et détection de malwares en mémoire et le guide complet de forensics Windows.

La méthodologie PICERL : le cadre structurant du DFIR

La réponse à incident sans méthode, c'est la panique organisée. Le cycle PICERL — issu du NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide) — structure l'intervention en 6 phases séquentielles.

La Préparation est la phase la plus déterminante — et la plus négligée. Elle comprend la constitution d'une équipe DFIR identifiée avec des rôles clairs (IR lead, analyste forensique, communicant), la préparation de kits forensiques (write-blockers Tableau T8u, clés USB bootables Kali/SIFT, licences logicielles), et la rédaction de playbooks par type d'incident. Un playbook ransomware n'est pas un playbook compromission de compte. Ils doivent exister séparément, testés au moins une fois par an via des exercices tabletop.

L'Identification répond à la question : "Est-ce un vrai incident ?" Les faux positifs coûtent cher. Un analyste qui déclare l'état d'urgence sur une anomalie bénigne désorganise l'équipe pour rien. À l'inverse, un incident non qualifié laisse l'attaquant progresser. La corrélation des alertes EDR, SIEM et des logs authentification — avec les indicateurs de compromission (IOC) des rapports ANSSI et CERTFR — permet une qualification rapide.

Le Confinement a deux modes : confinement court terme (isoler le système infecté du réseau en maintenant l'alimentation pour préserver la mémoire) et confinement long terme (couper les accès compromis, bloquer les C2 identifiés au pare-feu, invalider les credentials exposés). Couper l'alimentation d'un système infecté, c'est perdre la mémoire RAM — et souvent les clés de chiffrement des ransomwares ou la configuration des malwares fileless. Cette erreur, commise par réflexe, rend l'analyse forensique incomplète et peut compromettre toute la chaîne de custody.

L'Éradication est la phase la plus sous-estimée. 35% des réinfections post-incident résultent d'une éradication incomplète — l'attaquant avait laissé une backdoor secondaire non détectée. L'Éradication systématique vérifie tous les mécanismes de persistence : scheduled tasks, registry run keys, services installés, comptes de service créés, clés SSH autorisées. La Récupération — restauration depuis des sauvegardes saines et vérifiées — ne doit démarrer qu'après certification complète de l'éradication. Enfin, les Lessons Learned (REX post-incident) documentent la chronologie, les détections manquées, les améliorations à apporter aux playbooks et les investissements de sécurité prioritaires. Sans ce REX, le prochain incident est identique.

Memory forensics avec Volatility 3 : trouver ce que le disque ne révèle pas

Les malwares modernes sont de plus en plus fileless : ils s'exécutent entièrement en mémoire, sans jamais écrire d'exécutable sur le disque. Volatility 3 est l'outil de référence pour analyser les dumps mémoire RAM et extraire processus, connexions réseau, clés de registre chargées et shellcodes.

# Installation Volatility 3
git clone https://github.com/volatilityfoundation/volatility3.git
cd volatility3 && pip3 install -r requirements.txt

# Lister les processus du dump mémoire
python3 vol.py -f /forensics/dump.mem windows.pslist.PsList

# Détecter les processus cachés (comparaison EPROCESS vs PEB)
python3 vol.py -f /forensics/dump.mem windows.psscan.PsScan

# Lister les connexions réseau actives au moment de l'acquisition
python3 vol.py -f /forensics/dump.mem windows.netstat.NetStat

# Dumper un processus suspect (ex: PID 1337)
python3 vol.py -f /forensics/dump.mem -o /forensics/extracted/ windows.dumpfiles.DumpFiles --pid 1337

# Détecter les injections de code (process hollowing, injection DLL)
python3 vol.py -f /forensics/dump.mem windows.malfind.Malfind

# Extraire la ruche HKLM\SOFTWARE chargée en mémoire
python3 vol.py -f /forensics/dump.mem windows.registry.hivelist.HiveList
python3 vol.py -f /forensics/dump.mem windows.registry.printkey.PrintKey --key "Software\Microsoft\Windows\CurrentVersion\Run"

La commande windows.malfind identifie les régions mémoire avec des permissions RWX (Read-Write-Execute) — signature d'une injection de shellcode. Sur un incident que j'ai analysé en 2025, malfind a révélé un COBALT STRIKE Beacon injecté dans svchost.exe, invisible depuis le disque et contournant parfaitement l'EDR configuré en mode audit. La mémoire ne ment pas.

Disk forensics : Autopsy et FTK Imager pour l'analyse statique

FTK Imager (Forensic Toolkit Imager, AccessData) est le standard pour l'acquisition d'images disque forensiques. Il génère des images .E01 (EWF) ou .dd avec hashes MD5 et SHA-256 intégrés, garantissant l'intégrité de la preuve pour la chaîne de custody.

# Acquisition avec FTK Imager (CLI - Windows)
ftkimager.exe \.\PhysicalDrive0 /forensics/image/disk01 --e01 --compress 1 --verify

# Montage d'une image .E01 en lecture seule avec libewf (Linux)
sudo apt install libewf-dev ewf-tools
ewfmount /forensics/disk01.E01 /mnt/ewf
sudo mount -o ro,norecovery,loop /mnt/ewf/ewf1 /mnt/case

# Analyse avec Autopsy (CLI Sleuth Kit)
# Lister les partitions
mmls /mnt/case/disk01.E01

# Rechercher les fichiers supprimés
fls -r -d /mnt/case/disk01.E01 | grep -i "\.exe\|\.dll\|\.ps1"

# Extraire les artefacts Windows (prefetch, LNK, NTFS MFT)
icat /mnt/case/disk01.E01 0 | strings | grep -i "malware\|c2\|beacon"

Autopsy (TSK/Sleuth Kit) offre une interface graphique pour l'analyse approfondie : timeline NTFS, extraction de métadonnées EXIF, récupération de fichiers supprimés, analyse de la MFT (Master File Table), et modules Ingests automatisés pour les artefacts Windows (Recent Activity, Hash Lookup, Keyword Search). Son intégration avec SANS Investigative Forensic Toolkit (SIFT) — disponible en machine virtuelle gratuite SANS SIFT Workstation — constitue l'environnement de référence pour les forensics Windows.

Network forensics : Wireshark et Zeek pour capturer l'activité réseau

Wireshark permet l'analyse interactive des captures PCAP. Zeek (anciennement Bro) va plus loin : il transforme les captures réseau en logs structurés JSON exploitables par un SIEM ou des scripts d'analyse. Sur un incident ransomware, Zeek permet de reconstituer en minutes les connexions vers les serveurs C2, les transferts DNS suspects et les tentatives de mouvement latéral SMB.

# Zeek : analyse d'une capture PCAP existante
zeek -r /forensics/capture.pcap

# Logs générés automatiquement :
# conn.log       - toutes les connexions TCP/UDP/ICMP
# dns.log        - requêtes et réponses DNS (DGA detection)
# http.log       - requêtes HTTP avec User-Agent, URI, referrer
# ssl.log        - handshakes TLS avec JA3/JA3S fingerprints
# files.log      - fichiers transférés (hash MD5/SHA1/SHA256)
# notice.log     - alertes Zeek (scans, bruteforce, tunnels)

# Filtrer les connexions vers un C2 suspect
grep "185.220.101" conn.log | zeek-cut id.orig_h id.resp_h id.resp_p duration orig_bytes

# Détecter les DGA (Domain Generation Algorithm) via entropie élevée
cat dns.log | zeek-cut query | awk '{print length($0), $0}' | sort -rn | head -20

# Wireshark : extraire les fichiers transférés via HTTP
tshark -r /forensics/capture.pcap --export-objects http,/forensics/extracted_files/

# Filtrer le trafic C2 Cobalt Strike (Beacon default port 443)
tshark -r /forensics/capture.pcap -Y "ssl.handshake.extensions_server_name" -T fields -e ssl.handshake.extensions_server_name | sort -u

Comment analyser les logs Windows EVTX pour reconstituer une attaque ?

Les journaux d'événements Windows (EVTX) sont la source d'artefacts la plus riche pour reconstituer une attaque. Les Event IDs critiques à connaître :

• 4624/4625 : Connexion réussie/échouée (logon type 3 = réseau, type 10 = RDP distant)
• 4720/4728/4732 : Création de compte, ajout à un groupe de sécurité, ajout au groupe Administrateurs
• 7045 : Installation d'un nouveau service (persistence classique)
• 1102 : Effacement du journal d'événements Security (Red flag immédiat)
• 4688 : Création de processus avec command line (nécessite l'audit Process Tracking)
• Sysmon Event ID 1, 3, 7, 10, 11 : Process creation, connexions réseau, chargement de modules, ProcessAccess, FileCreate

#!/usr/bin/env python3
# Analyse EVTX avec python-evtx (pip install python-evtx)
import Evtx.Evtx as evtx
import Evtx.Views as e_views
import xml.etree.ElementTree as ET
from datetime import datetime

def extract_critical_events(evtx_path, event_ids=[4624, 4625, 4688, 7045, 1102]):
    """Extrait les événements critiques d'un fichier EVTX Windows."""
    results = []
    with evtx.Evtx(evtx_path) as log:
        for record in log.records():
            try:
                xml_str = record.xml()
                root = ET.fromstring(xml_str)
                ns = {'e': 'http://schemas.microsoft.com/win/2004/08/events/event'}
                event_id = int(root.find('.//e:EventID', ns).text)
                if event_id in event_ids:
                    timestamp = root.find('.//e:TimeCreated', ns).get('SystemTime')
                    data = {d.get('Name'): d.text for d in root.findall('.//e:Data', ns)}
                    results.append({'id': event_id, 'time': timestamp, 'data': data})
            except Exception:
                pass
    return sorted(results, key=lambda x: x['time'])

events = extract_critical_events('/forensics/Security.evtx')
for e in events:
    print(f"[{e['time']}] Event {e['id']}: {e['data'].get('TargetUserName', '')} from {e['data'].get('IpAddress', '')}")

Timeline reconstruction avec Plaso : la super-timeline forensique

Plaso (Plaso Langar Að Safna Öllu — "to collect all" en islandais) est l'outil de référence pour la super-timeline forensique. Développé par des anciens du projet log2timeline, il agrège des dizaines de sources d'artefacts (NTFS MFT, prefetch, LNK, EVTX, browser history, shellbags, USB, registry hives) en une timeline unifiée triable et filtrable.

# Installation Plaso (SIFT Workstation l'inclut nativement)
pip3 install plaso

# Étape 1 : Extraction des artefacts (peut prendre 30-60 min sur 500GB)
log2timeline.py --storage-file /forensics/timeline.plaso   --parsers "win_prefetch,winevtx,mft,lnk,winreg,chrome_history,firefox_history"   /mnt/case/

# Étape 2 : Filtrage et export en CSV lisible
psort.py -o csv -w /forensics/timeline.csv   --slice "2026-03-15T00:00:00" --slice_size 1440   /forensics/timeline.plaso

# Filtrer sur un compte utilisateur spécifique
psort.py -o csv -w /forensics/timeline_user.csv   --filter "username contains 'jdupont'"   /forensics/timeline.plaso

# Timeline en JSON pour ingestion SIEM/ELK
psort.py -o json -w /forensics/timeline.json /forensics/timeline.plaso

La super-timeline permet de corréler des événements apparemment sans lien : un fichier Prefetch créé à 14h32 pour MIMIKATZ.EXE, suivi 3 minutes plus tard par un Event ID 4728 (ajout au groupe Administrateurs), et 12 minutes après par une connexion SMB vers un serveur de fichiers — ça raconte une histoire. Plaso permet de reconstituer cette chaîne causale sur des mois de logs, ce qu'aucun analyste ne peut faire manuellement.

Comment utiliser MITRE ATT&CK pour guider l'investigation DFIR ?

Le framework MITRE ATT&CK est l'outil de référence pour cartographier les TTPs (Tactics, Techniques, Procedures) des attaquants observés lors d'une investigation. Chaque artefact découvert peut être mappé sur une technique ATT&CK, permettant de :

• Comprendre la sophistication de l'attaquant et son niveau (script kiddie vs APT étatique)
• Prédire les phases suivantes de l'attaque (si T1078 Valid Accounts observé → chercher T1021 Remote Services)
• Orienter la recherche vers des artefacts complémentaires non encore trouvés
• Produire un rapport structuré pour la direction et les équipes cyber

Outils de collecte des preuves : garantir la chaîne de custody

La qualité d'une investigation DFIR dépend de la rigueur de la collecte initiale. Un artefact mal collecté (sans hash, sans documentation du contexte) peut être contesté en cas de procédure judiciaire ou invalider les conclusions d'un rapport d'assurance cyber.

# Acquisition mémoire en live (Windows) avec WinPmem
winpmem_mini_x64_rc2.exe /forensics/memory_$(date +%Y%m%d_%H%M%S).raw

# Hash SHA-256 immédiat après acquisition
certutil -hashfile /forensics/memory_20260315_143022.raw SHA256

# Acquisition rapide des artefacts volatiles avec KAPE (Kroll Artifact Parser and Extractor)
# KAPE collecte les artefacts les plus critiques en <5 minutes
kape.exe --tsource C: --tdest /forensics/artifacts --target KapeTriage --tflush

# Copie forensique Linux avec dc3dd (write-blocker logiciel)
dc3dd if=/dev/sda of=/forensics/disk.dd hash=sha256 log=/forensics/acquisition.log

# Verification integrity après copie
sha256sum /forensics/disk.dd > /forensics/disk.dd.sha256
diff <(sha256sum /forensics/disk.dd) /forensics/disk.dd.sha256

Ressources et certifications DFIR de référence en 2026

La profession DFIR se structure autour de certifications reconnues par le marché. GCFE (GIAC Certified Forensic Examiner) et GCIH (GIAC Certified Incident Handler) de SANS Institute sont les références pour les praticiens. L'ENISA publie régulièrement des guides sur la réponse à incident pour les entités NIS 2, incluant des recommandations sur les playbooks et les obligations de notification.

Les guides de l'ANSSI sur la reconstruction après un sinistre cyber sont incontournables pour les organisations françaises soumises à NIS 2. Ils définissent les étapes de remédiation, les obligations de notification à l'ANSSI (délai de 72h pour les entités essentielles), et les critères d'évaluation des prestataires PRIS (Prestataires de Réponse à Incident de Sécurité) qualifiés ANSSI.

Pour approfondir la forensique mémoire, le site Volatility Foundation maintient la documentation officielle et les plugins communautaires. L'écosystème Memory Forensics Wiki de Volatility référence des centaines de cas d'usage, des profils pour les nouvelles versions de Windows et des techniques avancées pour l'analyse de malwares obfusqués. Consultez également notre article dédié sur les artefacts NTFS et méthodologie forensique avancée, la forensique du registre Windows et les techniques anti-forensics utilisées par les APT.

Questions fréquentes sur le DFIR en 2026

Quelle est la différence entre DFIR et forensics numérique classique ?

Le forensics numérique classique se concentre sur la collecte et l'analyse de preuves numériques, souvent dans un contexte judiciaire ou post-incident. Le DFIR (Digital Forensics and Incident Response) y ajoute la dimension de réponse à incident en temps réel : il combine investigation forensique (reconstituir ce qui s'est passé) et actions de remédiation actives (confinement, éradication, récupération). En pratique, une équipe DFIR est mobilisée pendant l'incident pour limiter la propagation tout en préservant les preuves — deux objectifs parfois en tension, ce qui nécessite une expertise et une méthode éprouvées.

Comment Volatility 3 se compare-t-il à la version 2 ?

Volatility 3 — sorti en 2019 et activement maintenu — apporte deux avantages majeurs sur la v2 : l'abandon des profils système au profit d'un système de symboles automatique (plus besoin de créer un profil pour chaque version de Windows ou Linux) et une architecture en plugins modulaires en Python 3. La migration vers Volatility 3 est recommandée pour tous les labs DFIR. La commande python3 vol.py -f dump.mem banners.Banners identifie automatiquement le système d'exploitation du dump pour charger les bons symboles.

Pourquoi utiliser Zeek plutôt que Wireshark seul pour l'analyse réseau ?

Wireshark est idéal pour l'analyse interactive d'une capture ciblée (décodage de protocoles, filtres précis). Zeek complémente en produisant des logs structurés JSON exploitables à grande échelle : un flux réseau de 100 Go devient exploitable en minutes avec zeek-cut et des requêtes simples. Sur un incident avec plusieurs jours de captures réseau, Wireshark seul est impraticable. Zeek permet aussi d'intégrer les logs directement dans Elastic/Splunk pour une corrélation automatisée avec les alertes EDR et SIEM.

Quelles sont les obligations de notification en France pour un incident cyber majeur ?

Depuis la transposition de NIS 2 en droit français (décret d'application 2024), les entités essentielles et importantes ont l'obligation de notifier l'ANSSI dans un délai de 24h pour une alerte préliminaire et 72h pour la notification initiale complète. Le rapport final doit parvenir à l'ANSSI dans le mois suivant l'incident. Ces délais s'ajoutent aux obligations RGPD (notification CNIL en 72h pour les violations de données personnelles). Les prestataires PRIS qualifiés ANSSI disposent de la capacité de notifier en votre nom dans ces délais contraints.

Comment intégrer le MITRE ATT&CK dans les rapports d'investigation DFIR ?

Le navigator ATT&CK (attack.mitre.org/resources/attack-navigator/) permet de créer des heat maps visuelles des techniques observées lors d'une investigation. Ces visuels — intégrés dans les rapports d'incident — communiquent efficacement la sophistication de l'attaquant à la direction et aux équipes techniques. Chaque technique documentée avec ses artefacts associés (logs, hash, timestamps) constitue la base factuelle du rapport. Le mapping ATT&CK permet aussi de générer automatiquement des recommandations de détection ciblées pour le SOC (règles SIEM, alertes EDR) sur les TTPs précisément observés plutôt que sur des patterns génériques.

Intégration DFIR avec les plateformes SIEM et SOAR

Une investigation DFIR isolée des outils d'entreprise manque d'efficacité. L'intégration des artefacts collectés — logs Zeek, super-timeline Plaso, dumps Volatility — dans les plateformes SIEM (Elastic Security, Splunk, Microsoft Sentinel) et SOAR (Cortex XSOAR, TheHive, Shuffle) multiplie la vitesse d'investigation. TheHive + Cortex constituent la stack open source de référence pour les équipes DFIR : TheHive gère les cas d'incident avec leur timeline, pièces jointes et observables ; Cortex automatise l'enrichissement via des analyseurs (VirusTotal, Shodan, AbuseIPDB, CIRCL MISP). Pour les investigations à grande échelle, l'ingestion des logs Plaso/JSON dans Elastic avec le dashboard SIFT + ELK permet de visualiser la super-timeline et de corréler rapidement avec les alertes réseau Zeek. Consultez notre article sur les meilleures solutions EDR/XDR 2025 et le guide de conformité SOC 2 pour les aspects organisationnels de la sécurité opérationnelle.