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

La réponse à incident et l'investigation numérique (Digital Forensics and Incident Response, DFIR) constituent aujourd'hui des disciplines fondamentales de la cybersécurité opérationnelle. Face à la sophistication croissante des attaques, à la multiplication des vecteurs de compromission et à la complexité des environnements hybrides, les organisations doivent disposer de capacités DFIR matures pour détecter rapidement les intrusions, collecter les preuves numériques, éradiquer les menaces et restaurer les systèmes compromis. Ce livre blanc de référence vous guide à travers chaque phase du processus DFIR, des méthodologies éprouvées aux techniques d'analyse forensique avancée sur Windows, Linux et les environnements cloud. Ce livre blanc de plus de 7 000 mots detaille chaque etape de la reponse a incident, de la preparation initiale a l'analyse post-mortem. Destine aux analystes forensic, incident responders et responsables SOC, il propose une approche structuree et actionnable, illustree par des cas concrets, des commandes pratiques et des methodologies eprouvees sur le terrain.

Chapitre 1 : Introduction au DFIR – Enjeux et cadre méthodologique

Vos guides de bonnes pratiques sont-ils lus et appliqués par les équipes opérationnelles ?

1.1 Définition et périmètre du DFIR

Le DFIR (Digital Forensics and Incident Response) englobe deux disciplines complémentaires mais distinctes. Le Digital Forensics désigne l'ensemble des techniques d'acquisition, de préservation et d'analyse des preuves numériques dans le respect de procédures garantissant leur intégrité et leur recevabilité juridique. L'Incident Response couvre quant à elle les processus organisationnels et techniques permettant de détecter, contenir, éradiquer et récupérer d'un incident de sécurité informatique.

La convergence de ces deux disciplines s'est accélérée au cours de la dernière décennie. Les équipes SOC (Security Operations Center) et les équipes CSIRT (Computer Security Incident Response Team) travaillent désormais main dans la main pour assurer une couverture complète du cycle de vie d'un incident. Selon le rapport Verizon DBIR 2024, le délai médian de détection d'une intrusion est passé de 207 jours en 2019 à environ 73 jours en 2024, une amélioration significative mais encore insuffisante face aux attaquants modernes.

1.2 Évolution historique de la discipline

Le forensics numérique est né dans les années 1980 avec les premières investigations sur des disquettes et disques durs dans le cadre d'affaires judiciaires. La création du CERT/CC (Computer Emergency Response Team Coordination Center) à Carnegie Mellon en 1988, suite au ver Morris, marque le début officiel de la réponse à incident organisée. Au fil des décennies, la discipline a considérablement évolué :

1.3 Cadres méthodologiques de référence

Plusieurs cadres méthodologiques structurent la pratique du DFIR. Le modèle PICERL (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned), issu du NIST SP 800-61, est le plus largement adopté. Il fournit une approche cyclique et itérative permettant d'améliorer continuellement les capacités de réponse.

Le standard NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response) détaille spécifiquement l'intégration des techniques forensiques dans le processus de réponse à incident. Il définit quatre phases : collecte, examen, analyse et rapport. La norme ISO/IEC 27037 (Guidelines for identification, collection, acquisition and preservation of digital evidence) complète ce cadre en définissant les bonnes pratiques de manipulation des preuves numériques.

Comment mesurez-vous concrètement l'efficacité de votre programme de sécurité ?

1.4 Les rôles clés en DFIR

Une équipe DFIR efficace repose sur des rôles spécialisés et complémentaires. L'Incident Handler coordonne l'ensemble de la réponse et gère la communication avec les parties prenantes. Le Forensic Analyst réalise l'investigation technique approfondie des systèmes compromis. Le Malware Analyst décortique les échantillons malveillants pour comprendre les TTPs (Tactics, Techniques and Procedures) de l'attaquant. Le Threat Intelligence Analyst contextualise l'incident en le rattachant à des groupes d'attaquants connus et des campagnes précédentes.

Dans les organisations de taille moyenne, ces rôles sont souvent cumulés par un nombre réduit de personnes. La tendance actuelle est à l'automatisation des tâches répétitives via des plateformes SOAR (Security Orchestration, Automation and Response) pour permettre aux analystes de se concentrer sur l'investigation et la prise de décision.

Chapitre 2 : Préparation à la réponse à incident

2.1 Politique et gouvernance de réponse à incident

La préparation est la phase la plus critique du cycle PICERL, car elle détermine la capacité de l'organisation à réagir efficacement lorsqu'un incident survient. Une politique de réponse à incident formalisée doit définir clairement les rôles et responsabilités, les critères de classification des incidents, la matrice d'escalade, les procédures de communication et les obligations réglementaires de notification. En France, le RGPD impose une notification à la CNIL dans les 72 heures suivant la découverte d'une violation de données personnelles. La directive NIS 2, applicable depuis 2024, étend ces obligations à un plus grand nombre d'entités.

La classification des incidents constitue un élément fondamental de la gouvernance. Un système de classification à plusieurs niveaux permet d'adapter la réponse à la sévérité de l'incident :

2.2 Playbooks de réponse à incident

Les playbooks sont des guides procéduraux détaillés qui décrivent les actions à mener pour chaque type d'incident. Un playbook efficace contient les étapes de détection et validation, les actions de containment immédiates, les procédures de collecte de preuves, les étapes d'éradication, le plan de recovery et les points de communication. Voici les playbooks essentiels que toute organisation devrait maintenir :

Playbook Ransomware : Déconnexion immédiate des systèmes affectés du réseau (mais NE PAS éteindre pour préserver la mémoire), identification de la souche via les notes de rançon et les extensions de fichiers chiffrés, vérification de l'intégrité des sauvegardes, évaluation de l'étendue du chiffrement, collecte des IOC pour détecter d'autres systèmes compromis. Selon le rapport IBM Cost of a Data Breach 2024, le coût moyen d'un incident ransomware atteint 5,13 millions de dollars.

Playbook Compromission de compte : Réinitialisation immédiate du mot de passe, révocation des sessions actives et tokens OAuth, analyse des journaux d'authentification (Event IDs 4624, 4625, 4648, 4672 sur Windows), vérification des règles de transfert email, audit des accès aux ressources sensibles, recherche de mouvement latéral.

Playbook Phishing : Extraction des entêtes email (Return-Path, Received, X-Originating-IP), analyse des URLs et pièces jointes en sandbox, identification de tous les destinataires, recherche de clics dans les logs proxy, vérification des compromissions secondaires, blocage des IOC au niveau du pare-feu et du proxy.

2.3 Constitution du kit forensique

Le kit forensique (ou "jump bag") doit être prêt en permanence et contenir les outils matériels et logiciels nécessaires à une intervention rapide. Côté matériel : bloqueurs d'écriture (Tableau T35689iu, CRU WiebeTech), disques durs de grande capacité pour l'imagerie, câbles réseau croisés, adaptateurs divers (SATA/USB, M.2/USB, IDE/USB), clés USB bootables avec les distributions forensiques (SANS SIFT, CAINE, Tsurugi), et un ordinateur portable dédié à l'analyse.

Côté logiciel, la boîte à outils forensique moderne comprend :

2.4 Exercices et tests de préparation

La préparation ne se limite pas à la rédaction de documents et à l'acquisition d'outils. Des exercices réguliers sont indispensables pour valider l'efficacité des procédures et la compétence des équipes. Les exercices de simulation sur table (tabletop exercises) permettent de tester les processus décisionnels sans impact technique. Les exercices techniques (red team/purple team) testent les capacités réelles de détection et de réponse. Pour approfondir ces méthodologies, consultez notre livre blanc Red Team vs Blue Team.

Chapitre 3 : Détection et qualification des incidents

3.1 Sources de détection et alertes

La détection des incidents repose sur de multiples sources complémentaires. Le SIEM (Security Information and Event Management) agrège et corrèle les journaux d'événements provenant de l'ensemble de l'infrastructure. Les solutions EDR (Endpoint Detection and Response) surveillent le comportement des endpoints en temps réel, détectant les exécutions suspectes, les injections de processus et les mouvements latéraux. Les solutions NDR (Network Detection and Response) analysent le trafic réseau pour identifier les communications malveillantes, les exfiltrations de données et les tunnels de commande et contrôle.

Les règles de détection Sigma permettent de définir des signatures de détection indépendantes du SIEM. Le format YARA est utilisé pour la détection de malware sur les fichiers et en mémoire. Les règles Suricata/Snort couvrent la détection réseau. L'outil SysmonEventCorrelator facilite la corrélation des événements Sysmon pour une détection comportementale avancée.

3.2 Processus de triage

Le triage est l'étape initiale d'évaluation d'une alerte. Son objectif est de déterminer rapidement si l'alerte correspond à un véritable incident de sécurité ou à un faux positif. Le processus de triage suit généralement ces étapes :

1. Contexte de l'alerte : Quelle règle a déclenché ? Sur quel système ? À quelle heure ? Quel utilisateur ?
2. Enrichissement : Vérification des IoC dans les bases de threat intelligence (VirusTotal, AbuseIPDB, OTX, MISP). L'enrichissement automatique via curl -s "https://www.virustotal.com/api/v3/files/{hash}" ou via l'API MISP permet d'accélérer le processus.
3. Corrélation : Recherche d'alertes connexes dans le SIEM (même source IP, même utilisateur, même technique). La requête type dans Splunk : index=security sourcetype=sysmon EventCode=1 ParentImage=*cmd.exe* | stats count by Image, CommandLine
4. Vérification : Validation avec le propriétaire du système ou l'utilisateur concerné si nécessaire
5. Décision : Faux positif (clôture), incident confirmé (escalade selon la sévérité)

3.3 Qualification avec MITRE ATT&CK

Le framework MITRE ATT&CK fournit une taxonomie standardisée des techniques d'attaque qui permet de qualifier précisément les incidents. Chaque alerte ou observation doit être mappée sur la matrice ATT&CK pour identifier les tactiques et techniques de l'attaquant. Cette cartographie facilite la compréhension de la progression de l'attaque et permet d'anticiper les prochaines étapes probables.

Les principales tactiques à surveiller lors du triage :

3.4 Établissement du scope initial

Une fois l'incident qualifié, il est essentiel d'établir rapidement un scope initial, c'est-à-dire identifier l'ensemble des systèmes potentiellement affectés. Cette étape utilise les IoC déjà identifiés pour rechercher des traces de compromission sur d'autres endpoints. Les outils EDR permettent de lancer des recherches ("threat hunting") à l'échelle de l'ensemble du parc. La commande type sur Velociraptor : velociraptor artifact collect Generic.Client.Info --target=all suivi de velociraptor query "SELECT * FROM hunt_results() WHERE ..."

Le scope initial détermine la stratégie de containment. Si seul un poste de travail est affecté, une isolation réseau ciblée suffit. Si le contrôleur de domaine Active Directory est compromis, la situation est beaucoup plus critique et nécessite une réponse à l'échelle de tout le domaine. Consultez notre guide de sécurité Active Directory pour les scénarios de compromission AD.

Chapitre 4 : Collecte de preuves et chaîne de custody

4.1 Principe d'ordre de volatilité

La RFC 3227 (Guidelines for Evidence Collection and Archiving) établit le principe fondamental de l'ordre de volatilité : les preuves les plus volatiles doivent être collectées en premier. La mémoire vive, qui s'évanouit à l'extinction du système, est la première priorité. Viennent ensuite l'état réseau, les processus en cours, les fichiers temporaires, puis le système de fichiers complet. Ne jamais éteindre une machine suspecte avant d'avoir collecté la mémoire vive est une règle d'or du forensics.

4.2 Acquisition de la mémoire vive

L'acquisition de la mémoire vive (RAM dump) doit être réalisée avec des outils fiables et validés. Les principaux outils d'acquisition mémoire sont :

Windows : winpmem_mini_x64.exe mem.raw est l'outil standard open source. DumpIt (Comae/Magnet) propose une interface simplifiée. FTK Imager permet également l'acquisition mémoire via son interface graphique. Pour les environnements d'entreprise, Velociraptor permet l'acquisition à distance : velociraptor artifact collect Windows.Memory.Acquisition --target=workstation01

Linux : Le module kernel LiME (Linux Memory Extractor) est la référence : insmod lime.ko "path=/evidence/mem.lime format=lime". Pour les environnements containerisés, /proc/kcore peut être utilisé avec prudence, mais un module LiME compilé pour le noyau exact est préférable.

macOS : Depuis macOS 11, les protections SIP et KEXT rendent l'acquisition mémoire plus complexe. L'outil osxpmem nécessite une désactivation temporaire de SIP. Les Mac avec puce Apple Silicon (M1/M2/M3) nécessitent des approches spécifiques.

4.3 Imagerie disque forensique

L'imagerie disque forensique crée une copie bit-à-bit exacte du support de stockage, incluant les espaces non alloués, les fichiers supprimés et les données résiduelles. L'utilisation d'un bloqueur d'écriture matériel est obligatoire pour garantir l'intégrité du support source.

Les formats d'image forensique principaux :

Commandes d'acquisition courantes :

Avec dc3dd : dc3dd if=/dev/sda of=/evidence/disk.raw hash=sha256 log=/evidence/disk.log

Avec ewfacquire (format E01) : ewfacquire /dev/sda -t /evidence/disk -c deflate:best -S 2GiB

Vérification d'intégrité : sha256sum /evidence/disk.raw et comparaison avec le hash calculé lors de l'acquisition.

4.4 Chaîne de custody et documentation

La chaîne de custody (ou chaîne de traitement) est un document qui trace chaque manipulation d'une preuve numérique depuis sa collecte jusqu'à sa présentation éventuelle devant un tribunal. Elle doit enregistrer : qui a collecté la preuve, quand (date et heure précises), où (localisation physique et logique), comment (outil utilisé, version, paramètres), les hash d'intégrité (SHA-256 minimum), et chaque transfert ou accès ultérieur à la preuve.

4.5 Collecte à distance avec les outils de triage

Dans les environnements d'entreprise, la collecte à distance est souvent nécessaire, notamment pour les sites distants ou les systèmes cloud. Les outils de triage permettent de collecter rapidement les artefacts clés sans nécessiter une image complète du disque.

KAPE (Kroll Artifact Parser and Extractor) est l'outil de triage de référence sur Windows. Il collecte et parse les artefacts en une seule opération : kape.exe --tsource C: --tdest /evidence/kape --target KapeTriage --module !EZParser. Cette commande collecte les journaux d'événements, le registre, les fichiers Prefetch, l'Amcache, les navigateurs web et parse immédiatement les résultats.

Velociraptor permet la collecte d'artefacts à l'échelle du parc entier. Un agent déployé sur chaque endpoint permet de lancer des "hunts" ciblant des artefacts spécifiques. Par exemple, pour collecter les journaux d'événements de sécurité sur tous les serveurs : velociraptor artifact collect Windows.EventLogs.Hayabusa --target=servers

Chapitre 5 : Analyse forensique Windows

5.1 Analyse du registre Windows

Le registre Windows est une mine d'informations forensiques. Chaque ruche contient des artefacts spécifiques permettant de reconstituer l'activité sur le système. La ruche NTUSER.DAT (par utilisateur, dans C:Users{user}NTUSER.DAT) contient les clés SoftwareMicrosoftWindowsCurrentVersionExplorerRecentDocs (fichiers récemment ouverts), SoftwareMicrosoftWindowsCurrentVersionExplorerTypedPaths (chemins saisis dans l'explorateur), et les UserAssist qui enregistrent chaque programme exécuté via l'interface graphique avec un compteur d'exécution et un timestamp.

L'outil UserAssistDecoder facilite le décodage des entrées UserAssist encodées en ROT13. L'analyse se fait avec : UserAssistDecoder.exe --hive NTUSER.DAT --output results.csv

La ruche SAM contient les comptes utilisateurs locaux et leurs hashes de mot de passe. La ruche SECURITY stocke les politiques de sécurité et les secrets LSA. La ruche SYSTEM contient la configuration matérielle, les services installés et la clé SelectCurrent qui indique le ControlSet actif. La ruche SOFTWARE liste les logiciels installés et leurs configurations.

5.2 Artefacts d'exécution : Prefetch, Shimcache, Amcache, BAM/DAM

Les artefacts d'exécution permettent de prouver qu'un programme a été exécuté sur le système, même après sa suppression.

Prefetch (C:WindowsPrefetch*.pf) : Créé par le préchargeur Windows pour accélérer le lancement des applications. Contient le nom de l'exécutable, le nombre d'exécutions, le dernier timestamp d'exécution (et les 7 précédents sous Windows 10+), ainsi que les fichiers et répertoires accédés. Analyse avec PECmd.exe -f "C:WindowsPrefetchMIMIKATZ.EXE-A234B5C6.pf" --csv output

Shimcache (AppCompatCache, dans la ruche SYSTEM) : Enregistre les chemins des fichiers exécutables avec un timestamp de dernière modification. Attention : la présence dans le Shimcache n'implique pas nécessairement une exécution, elle prouve seulement que le fichier a été "connu" du système. Extraction avec AppCompatCacheParser.exe -f SYSTEM --csv output

Amcache (C:WindowsappcompatProgramsAmcache.hve) : Ruche de registre dédiée enregistrant les programmes installés et exécutés avec leur hash SHA1, leur taille et leur timestamp de première exécution. L'outil AmcacheForensics automatise l'extraction et l'analyse : AmcacheForensics.exe --hive Amcache.hve --output results.json

BAM/DAM (Background Activity Moderator / Desktop Activity Moderator) : Présents depuis Windows 10, ces artefacts enregistrent le chemin complet de l'exécutable et le timestamp d'exécution dans SYSTEMCurrentControlSetServicesamStateUserSettings{SID}. L'outil BamDamForensics parse automatiquement ces entrées : BamDamForensics.exe --hive SYSTEM --output bam_results.csv

5.3 Journaux d'événements Windows

Les journaux d'événements Windows (EVTX) sont des sources forensiques majeures. Le journal Security est le plus riche pour l'investigation. Voici les Event IDs les plus importants à surveiller :

L'outil Hayabusa permet l'analyse rapide de grands volumes de journaux EVTX avec des règles Sigma : hayabusa.exe csv-timeline -d C:WindowsSystem32winevtLogs -o results.csv -p verbose. L'outil SysmonEventCorrelator complète cette analyse en corrélant les événements Sysmon pour reconstituer les chaînes d'attaque.

5.4 Analyse du système de fichiers NTFS

Le système de fichiers NTFS contient des structures internes riches en informations forensiques. La $MFT (Master File Table) est l'index central de tous les fichiers et répertoires. Chaque entrée MFT contient quatre timestamps ($STANDARD_INFORMATION et $FILE_NAME), le nom du fichier, sa taille et ses attributs. L'analyse de la MFT avec MFTECmd.exe -f $MFT --csv output permet de détecter les fichiers supprimés et les manipulations de timestamps (timestomping).

Le $UsnJrnl (Update Sequence Number Journal) enregistre chaque modification de fichier : création, suppression, renommage, modification de contenu. C'est une source précieuse pour reconstituer la chronologie des actions de l'attaquant. Le $LogFile contient le journal transactionnel NTFS et peut révéler des opérations récentes non encore visibles dans la MFT.

Les Alternate Data Streams (ADS) permettent de cacher des données dans des flux alternatifs de fichiers NTFS. L'outil AlternateDataStreamScanner détecte ces flux cachés. Les Volume Shadow Copies (VSS) peuvent contenir des versions antérieures de fichiers, incluant des malwares déjà supprimés ou des données avant chiffrement par un ransomware. L'outil VSSIntegrityWatcher vérifie l'intégrité des shadow copies et détecte les tentatives de suppression.

5.5 Construction de la Super Timeline

La super timeline est la pièce maîtresse de l'analyse forensique Windows. Elle réunit l'ensemble des artefacts dans une chronologie unifiée qui permet de reconstituer précisément les actions de l'attaquant. L'outil log2timeline.py (Plaso) est la référence pour générer une super timeline :

log2timeline.py --storage-file timeline.plaso /evidence/disk_image.E01

psort.py -w timeline.csv timeline.plaso "date > '2024-01-01' AND date < '2024-02-01'"

L'outil SuperTimelineBuilder simplifie ce processus en automatisant la génération et le filtrage de la super timeline avec des profils préconfigurés pour les scénarios d'investigation courants.

Chapitre 6 : Analyse forensique réseau et mémoire

6.1 Analyse mémoire avec Volatility 3

Volatility 3 est l'outil de référence pour l'analyse forensique de la mémoire vive. Il permet d'extraire et d'analyser les structures du noyau pour reconstituer l'état du système au moment de la capture. Les plugins essentiels pour une investigation DFIR :

Liste des processus : vol.py -f mem.raw windows.pslist affiche la liste des processus actifs. vol.py -f mem.raw windows.pstree montre la hiérarchie parent/enfant, essentielle pour détecter les processus suspects (par exemple, svchost.exe lancé par autre chose que services.exe). Le plugin windows.malfind détecte les sections mémoire avec des permissions suspectes (RWX) indiquant une injection de code.

Connexions réseau : vol.py -f mem.raw windows.netscan révèle toutes les connexions réseau actives et récentes, incluant les connexions déjà fermées mais encore présentes en mémoire. Cela permet d'identifier les communications C2 (Command and Control) même si le pare-feu n'a pas capturé le trafic.

Extraction de fichiers et credentials : vol.py -f mem.raw windows.filescan liste les handles de fichiers ouverts. vol.py -f mem.raw windows.hashdump extrait les hashes de mot de passe depuis la mémoire du processus LSASS. vol.py -f mem.raw windows.cachedump extrait les credentials en cache du domaine.

L'outil YaraMemoryScanner complète Volatility en permettant le scan de la mémoire avec des règles YARA personnalisées pour la détection de malware connu et de patterns suspects.

6.2 Détection des techniques d'injection mémoire

Les malwares modernes utilisent massivement l'injection de code en mémoire pour éviter la détection. Les principales techniques à rechercher :

Process hollowing : Le malware crée un processus légitime en état suspendu, remplace son code en mémoire par du code malveillant, puis reprend l'exécution. Détection : comparer le code en mémoire avec le fichier sur disque via vol.py -f mem.raw windows.malfind.

DLL injection : Le malware injecte une DLL malveillante dans un processus légitime via CreateRemoteThread, QueueUserAPC ou SetWindowsHookEx. Détection : vol.py -f mem.raw windows.dlllist pour lister les DLL chargées et identifier les DLL suspectes ou sans chemin sur disque.

Reflective DLL loading : La DLL est chargée directement en mémoire sans passer par l'API LoadLibrary, la rendant invisible dans la liste des DLL standard. Détection : windows.malfind identifie les régions mémoire RWX contenant des headers PE.

6.3 Analyse forensique réseau

L'analyse réseau forensique exploite les captures de paquets (PCAP) et les logs de flux pour identifier les communications malveillantes. Wireshark est l'outil principal pour l'analyse détaillée des captures. Les filtres essentiels :

Détection de beaconing C2 : tshark -r capture.pcap -T fields -e ip.dst -e frame.time_delta_displayed | sort | uniq -c | sort -rn identifie les destinations avec des intervalles réguliers (beaconing). Le DNS tunneling peut être détecté par l'analyse de la longueur et de l'entropie des requêtes DNS : tshark -r capture.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | awk '{print length, $0}' | sort -rn

Zeek (anciennement Bro) génère des logs structurés à partir du trafic réseau. Le fichier conn.log contient toutes les connexions, dns.log les requêtes DNS, http.log les requêtes HTTP, ssl.log les handshakes TLS avec les certificats. L'analyse des JA3/JA3S fingerprints permet d'identifier les applications et les outils d'attaque par leur empreinte TLS.

Chapitre 7 : Analyse forensique Linux et Cloud

7.1 Artefacts forensiques Linux

Le forensics Linux diffère significativement du forensics Windows. Les principales sources de preuves sur un système Linux sont :

Journaux système : /var/log/auth.log (ou /var/log/secure sur Red Hat) enregistre toutes les authentifications, les commandes sudo, les connexions SSH. /var/log/syslog contient les messages système généraux. journalctl sur les systèmes systemd fournit un accès structuré aux journaux : journalctl --since "2024-01-15" --until "2024-01-16" -p err

Historique des commandes : ~/.bash_history, ~/.zsh_history enregistrent les commandes exécutées par chaque utilisateur. Attention : un attaquant expérimenté utilise unset HISTFILE ou export HISTSIZE=0 pour désactiver la journalisation. La variable HISTTIMEFORMAT doit être configurée pour inclure les timestamps.

Fichiers de connexion : /var/log/wtmp (connexions réussies, lu avec last), /var/log/btmp (tentatives échouées, lu avec lastb), /var/log/lastlog (dernière connexion par utilisateur, lu avec lastlog). L'utmp (/var/run/utmp) contient les sessions actives.

Persistance Linux : Crontabs (/etc/crontab, /var/spool/cron/), services systemd (/etc/systemd/system/), scripts d'init (/etc/init.d/), fichiers de profil (~/.bashrc, ~/.profile), clés SSH autorisées (~/.ssh/authorized_keys), modules du noyau (/etc/modules-load.d/, lsmod).

7.2 Forensics des conteneurs Docker et Kubernetes

L'analyse forensique des environnements containerisés présente des défis spécifiques liés à la nature éphémère des conteneurs. Les commandes essentielles pour le forensics Docker : docker inspect {container_id} pour les métadonnées, docker diff {container_id} pour les modifications du filesystem, docker logs {container_id} pour les logs applicatifs, docker export {container_id} > container.tar pour exporter le filesystem complet.

Pour Kubernetes, les audit logs sont la source principale. Ils enregistrent toutes les requêtes API : kubectl logs -n kube-system kube-apiserver-master --since=24h | grep "verb.*create|delete|patch". Les events Kubernetes (kubectl get events --all-namespaces --sort-by='.lastTimestamp') fournissent un historique des opérations. Pour approfondir la sécurité Kubernetes, consultez notre livre blanc Kubernetes.

7.3 Forensics Cloud : AWS, Azure, GCP

Le forensics cloud nécessite des approches spécifiques à chaque fournisseur :

AWS : CloudTrail enregistre tous les appels API. Requête Athena pour rechercher les accès suspects : SELECT eventTime, eventName, sourceIPAddress, userIdentity.arn FROM cloudtrail_logs WHERE eventTime BETWEEN '2024-01-15' AND '2024-01-16' AND errorCode IS NOT NULL. Les VPC Flow Logs capturent le trafic réseau. GuardDuty fournit des alertes de sécurité automatisées. Pour les instances EC2, créez un snapshot EBS avant toute investigation : aws ec2 create-snapshot --volume-id vol-xxx --description "Forensic snapshot"

Azure : Azure Activity Log trace les opérations sur les ressources. Azure AD Sign-in Logs enregistre les authentifications. Requête KQL dans Log Analytics : SigninLogs | where TimeGenerated > ago(24h) | where ResultType != 0 | summarize count() by UserPrincipalName, IPAddress, ResultDescription. Pour approfondir, consultez notre guide Microsoft 365.

GCP : Cloud Audit Logs (Admin Activity et Data Access) via BigQuery ou Cloud Logging. Les VPC Flow Logs et les findings de Security Command Center complètent la détection. Consultez notre guide Pentest Cloud pour les méthodologies d'audit.

Chapitre 8 : Containment, éradication et recovery

8.1 Stratégies de containment

Le containment vise à limiter l'impact de l'incident en empêchant l'attaquant d'étendre sa compromission. Deux approches principales existent : le containment à court terme (actions immédiates pour stopper l'hémorragie) et le containment à long terme (mesures durables en attendant l'éradication complète).

Le containment à court terme inclut l'isolation réseau des systèmes compromis (via VLAN, ACL, ou EDR), le blocage des IP et domaines C2 identifiés au niveau du pare-feu et du proxy, la désactivation des comptes utilisateurs compromis et la révocation de leurs sessions actives.

8.2 Procédures d'éradication

L'éradication consiste à supprimer complètement la présence de l'attaquant. Pour les APT, l'éradication doit être planifiée et exécutée de manière coordonnée sur tous les systèmes compromis simultanément (appelé "coordinated remediation" ou "D-Day"). Les actions d'éradication incluent :

1. Suppression des malwares : Nettoyage ou reconstruction des systèmes compromis
2. Suppression de la persistance : Tâches planifiées malveillantes, services, clés de registre, comptes backdoor, clés SSH non autorisées
3. Réinitialisation des credentials : Mot de passe du compte KRBTGT (deux fois pour invalider les Golden Tickets), tous les comptes de service, les comptes administrateurs, les comptes machine
4. Patch des vulnérabilités : Corriger les vecteurs d'entrée initiale et les vulnérabilités exploitées pour le mouvement latéral
5. Durcissement : Appliquer les mesures de sécurité manquantes identifiées pendant l'investigation

8.3 Plan de recovery et validation

La phase de recovery restaure les systèmes et services dans un état opérationnel sécurisé. La reconstruction complète ("nuke and pave") est préférable au nettoyage pour les systèmes critiques, car elle garantit l'absence de malware résiduel. La restauration depuis des sauvegardes vérifiées (testées, datées d'avant la compromission, hashées) est la méthode la plus fiable.

Après la restauration, un monitoring renforcé doit être mis en place pendant au minimum 30 jours pour détecter toute tentative de ré-intrusion. Les IoC identifiés pendant l'investigation alimentent de nouvelles règles de détection dans le SIEM et l'EDR.

Chapitre 9 : Post-incident – Lessons learned et rapport forensique

9.1 Rédaction du rapport forensique

Le rapport forensique est le livrable principal de l'investigation. Il doit être rédigé de manière à être compréhensible par différents publics : la direction générale, l'équipe juridique, l'équipe technique et éventuellement les autorités judiciaires. La structure recommandée :

1. Résumé exécutif : Synthèse de l'incident en une page maximum, impact, actions menées et recommandations principales
2. Chronologie de l'incident : Timeline complète depuis la compromission initiale jusqu'à la remédiation, avec sources des preuves
3. Analyse technique : Détail de chaque phase de l'attaque, techniques utilisées (mapping MITRE ATT&CK), artefacts analysés
4. Impact : Données accédées ou exfiltrées, systèmes affectés, durée de la compromission
5. Preuves : Liste des preuves collectées avec hash, chaîne de custody
6. Recommandations : Actions correctives et préventives priorisées (court terme, moyen terme, long terme)

9.2 Réunion post-mortem et amélioration continue

La réunion post-mortem (ou "lessons learned") doit être organisée dans les deux semaines suivant la clôture de l'incident, lorsque les détails sont encore frais dans les esprits. Elle doit être conduite dans un esprit "blameless" : l'objectif est d'améliorer les processus, pas de désigner des coupables.

Les thèmes à aborder : efficacité de la détection (délai entre compromission et détection), qualité du triage et de la qualification, pertinence des playbooks utilisés, efficacité du containment, complétude de l'éradication, rapidité du recovery, qualité de la communication interne et externe, et lacunes identifiées dans l'outillage ou les compétences.

9.3 Intégration des leçons dans le cycle DFIR

Les enseignements de chaque incident doivent alimenter directement l'amélioration de la posture de sécurité :

L'utilisation d'une plateforme de gestion des incidents (TheHive, DFIR-IRIS) permet de capitaliser sur chaque investigation et de constituer une base de connaissances interne qui enrichit les futures réponses.

Questions Fréquentes

Outils et Ressources DFIR

Découvrez nos outils open source développés pour les professionnels du DFIR :

Pour approfondir, consultez les ressources de NIST Cybersecurity et de NVD (National Vulnerability Database).

Conclusion et Recommandations

La maîtrise du DFIR est devenue un impératif stratégique pour toute organisation. Face à des attaquants de plus en plus complexes, la capacité à détecter rapidement, investiguer méthodiquement et remédier efficacement fait la différence entre un incident contenu et une catastrophe. La méthodologie PICERL, les outils forensiques éprouvés et l'amélioration continue constituent les fondations d'une posture DFIR mature.

Les organisations qui investissent dans leurs capacités DFIR – formation des équipes, outillage adapté, playbooks testés, exercices réguliers – réduisent significativement l'impact des incidents et accélèrent leur rétablissement. N'attendez pas d'être victime d'une cyberattaque pour vous préparer.