Tous les projets

Investigation forensique d'une clé USB

Enquête numérique sur la copie d'une clé USB saisie. J'ai préservé la preuve, retrouvé des partitions cachées et des fichiers effacés, reconstitué la chronologie et déchiffré un volume protégé par mot de passe.

Le problème
Une clé USB saisie semble presque vide : comprendre ce qu'elle a servi à faire, avec des preuves vérifiables.
Ma démarche
Méthode en six phases : preuve préservée par empreintes, chaque commande journalisée, super-timeline, récupération de fichiers, déchiffrement d'un volume.
Le résultat
Partitions cachées et fichiers effacés retrouvés, chronologie reconstituée sur trois jours, volume chiffré ouvert.

En bref

La forensique numérique, c'est l'enquête sur des supports informatiques : retrouver ce qui s'est passé sur une machine ou une clé USB, avec des preuves qui tiennent devant un juge.

Dans ce projet, j'ai reçu la copie d'une clé USB saisie chez un suspect (un scénario de cours). La clé semblait presque vide. En réalité, son utilisateur y avait caché deux partitions, dont un volume chiffré, puis effacé ses traces. J'ai retrouvé ces éléments, reconstitué heure par heure ce qu'il avait fait sur trois jours, et retrouvé le mot de passe du volume chiffré grâce à des indices laissés sur la clé elle-même.

Contexte

Lab de Master 2 à l'UBS Lorient, en septembre 2026. Je reçois une image disque, c'est-à-dire une copie exacte bit à bit de la clé (environ 4 Go), avec ses empreintes de référence. L'enquête suit une méthode professionnelle en six phases : identification, préservation, extraction, analyse, documentation et présentation.

Objectifs

  • Garantir que la preuve n'a jamais été modifiée pendant l'enquête
  • Retrouver tout ce que la clé contient, y compris ce qui a été caché ou effacé
  • Reconstituer la chronologie des actions de son utilisateur
  • Tracer chaque manipulation pour que les résultats soient vérifiables

Stratégie d'enquête

Stratégie : partir des traces les plus accessibles pour aller vers les zones cachées puis chiffrées, chaque couche vérifiant les hypothèses de la précédente
Stratégie : partir des traces les plus accessibles pour aller vers les zones cachées puis chiffrées, chaque couche vérifiant les hypothèses de la précédente
  • Analyse post-mortem en lecture seule : je lis une copie figée de la clé, je n'exécute jamais rien de ce qu'elle contient.
  • Des pistes numérotées : j'ai découpé l'enquête en 21 pistes, des traces les plus faciles à lire (journaux du système, logiciels installés, sessions) aux plus coûteuses (partitions cachées, espace non alloué, chiffrement). Les premières pistes donnent des hypothèses, les suivantes les vérifient.
  • Recouper chaque constat : un fait n'est retenu que s'il est confirmé par au moins deux sources, par exemple un journal système et les dates d'un fichier. Pour la récupération de fichiers, j'ai lancé deux outils différents, PhotoRec et foremost, puis comparé leurs résultats par empreintes.
  • Séparer preuve et contexte : les images du cache du navigateur aident à comprendre, mais je ne les ai pas traitées comme des preuves. La recherche ciblée a porté sur les fichiers que l'utilisateur avait réellement ouverts.
  • Plusieurs options quand une piste bloque : pour retrouver les fichiers effacés, j'ai prévu quatre approches (récupération par signature, recherche de texte dans l'image brute, test des mots de passe trouvés sur les zones chiffrées, récupération de clés).
  • Des procédures rejouables : chaque étape est décrite avec sa commande, son explication et son résultat, pour qu'une autre personne puisse refaire l'enquête et obtenir la même chose.

Démarche

1. Préserver la preuve

Chaîne de préservation : l'image reçue n'est jamais modifiée, toute l'analyse se fait sur une copie de travail vérifiée, et chaque commande est journalisée
Chaîne de préservation : l'image reçue n'est jamais modifiée, toute l'analyse se fait sur une copie de travail vérifiée, et chaque commande est journalisée

Une empreinte (hash) est une sorte d'identifiant unique d'un fichier : si un seul octet change, l'empreinte change. J'ai calculé les empreintes MD5, SHA1 et SHA256 de l'image et je les ai comparées à celles fournies : elles sont identiques, la preuve est donc intacte.

J'ai ensuite créé une copie de référence verrouillée en lecture seule, puis une copie de travail, vérifiée elle aussi. Toute l'analyse se fait sur la copie de travail : l'original n'est jamais touché.

2. Tracer chaque action

Chaque commande est enregistrée au moment où elle est lancée : l'heure, la commande exacte, le résultat complet. L'enquête compte 122 journaux de ce type. Chaque manipulation de la preuve est aussi notée dans une chaîne de traçabilité (chain of custody). Un résultat qui n'est pas prouvé par un journal est écrit « non confirmé », jamais présenté comme acquis.

3. Retrouver ce qui était caché

La table de partitions de la clé, qui indique au système comment la clé est découpée, avait été modifiée pour ne montrer qu'une seule partie. En analysant l'image octet par octet, j'ai retrouvé trois partitions : une en FAT32, une en NTFS et un volume chiffré. Dans la partition FAT32 se cachait aussi un fichier supprimé de sa table, qui contenait un système de fichiers ext2 : la mémoire d'un Ubuntu démarré depuis la clé.

4. Récupérer ce qui avait été effacé

Un fichier supprimé ne disparaît pas tout de suite : ses données restent sur le support tant qu'elles ne sont pas écrasées. J'ai récupéré des fichiers dans cet espace libre avec PhotoRec, et j'ai repéré les traces du nettoyage lui-même : installation d'un outil d'effacement sécurisé (wipe), historique de commandes vidé, table de partitions modifiée à la main.

5. Reconstituer la chronologie

Chaque fichier garde des dates de création, de modification et d'accès. J'ai fusionné ces dates, pour les trois systèmes de fichiers (FAT32, NTFS et ext2), dans une chronologie unique (super-timeline, avec mactime). Je l'ai croisée avec les journaux du système et l'historique du navigateur. Un piège : les journaux sont en heure UTC et les fichiers s'affichent en heure locale, deux heures d'écart en été. Chaque rapprochement en tient compte.

6. Déchiffrer le volume protégé

Une partie de la clé était un volume chiffré TrueCrypt, illisible sans mot de passe. Le navigateur de l'utilisateur avait enregistré ses mots de passe dans un trousseau non protégé. Je l'ai déchiffré, et c'est à partir de ces mots de passe que j'ai retrouvé celui du volume. J'ai ensuite déchiffré le volume dans une image séparée, que j'ai analysée comme le reste, sans jamais modifier la copie de travail.

Résultats

  • Preuve intacte du début à la fin, vérifiée par empreintes
  • Trois partitions retrouvées là où la clé n'en montrait qu'une, plus un système de fichiers caché dans la première
  • Fichiers effacés récupérés et traces d'effacement identifiées
  • Chronologie des actions reconstituée heure par heure sur trois jours
  • Volume chiffré déchiffré, et son contenu analysé

Limites

  • Les deux premières copies de l'image ont été faites avant la mise en place de la traçabilité : leur méthode n'est pas tracée. Les empreintes prouvent quand même qu'elles sont identiques à la source.
  • Les journaux ne sont pas protégés un par un au fil de l'eau : une empreinte unique de tout le dossier est calculée à la fin.
  • Certains fichiers ont été détruits par l'outil d'effacement et ne sont pas récupérables.
  • Le rapport final est en cours de rédaction.

Outils utilisés

OutilCe que c'estÀ quoi il m'a servi
md5sum, sha1sum, sha256sumCalcul d'empreintesProuver que la preuve n'a jamais changé
The Sleuth Kit 4.15 (fsstat, fls, istat, icat, ils, blkls)Boîte à outils d'analyse de systèmes de fichiers en ligne de commandeLister les fichiers, y compris supprimés, lire leurs dates, extraire leur contenu sans monter la clé
AutopsyInterface graphique au-dessus de The Sleuth KitAvoir une vue d'ensemble du cas
mactimeGénérateur de chronologie de The Sleuth KitConstruire la super-timeline des trois systèmes de fichiers
PhotoRec 7.1 et foremost 1.5.7Récupération de fichiers par signature (carving)Retrouver des fichiers dans l'espace libre, avec deux outils pour recouper
exiftool 12.76Lecture des métadonnées d'imagesDater et trier les images récupérées
xxd, dd, strings, binwalkLecture et découpage d'octets brutsLire la table de partitions, repérer les zones cachées et chiffrées
utmpdump, grep, awkLecture de journauxSessions, connexions, installations et montages de périphériques
Python (sqlite3)Langage de scriptLire l'historique du navigateur stocké en base SQLite, sur une copie
NSS (libnss3)Bibliothèque de sécurité de FirefoxDéchiffrer le trousseau de mots de passe du navigateur
cryptsetupOutil de chiffrement de disques sous LinuxTester les mots de passe candidats sur le volume TrueCrypt (tcryptDump)

Pièges rencontrés

PiègeConséquenceCe que j'ai fait
Heures en UTC dans les journaux, en heure locale sur les fichiersDeux heures de décalage en été, fausses correspondancesNoter le fuseau de chaque heure et convertir avant de comparer
Ouvrir une base SQLite extraite peut la modifierAltérer un élément de preuveToujours travailler sur une copie de la base
Supposer le format d'un fichierExtraction qui échoue (fichier compressé en gzip et non en lzma)Vérifier le format avec file avant de le traiter
Chercher un mot avec strings -t d | grepgrep trouve aussi des chiffres dans la position affichée : faux résultatsRetirer la position avant de chercher
Zone de données qui semble presque videJ'ai d'abord cru que ce n'était pas le volume chiffréLe déchiffrement a montré le contraire : un volume peu rempli contient surtout des zéros

Projets proches

Systèmes embarquésCybersécurité

Analyse et injection sur bus CAN automobile

Reverse engineering des trames CAN d'une maquette véhicule, cartographie des bus, décodage des signaux moteur/éclairage/confort, base DBC et DLL d'injection en C simulant un système ADAS.

2026Bus CANReverse EngineeringAutomotiveMuxTrace

DevSecOpsCybersécurité

Indian Food : pipeline DevSecOps pour un site vitrine

Site vitrine statique d'un restaurant, déployé sur Oracle Cloud ARM64 derrière une chaîne DevSecOps : analyse statique, scan de dépendances, tests dynamiques et déploiement automatisé.

2026DevSecOpsDockerNginxCI/CD

Cybersécurité

Reverse engineering d'un programme inconnu

Analyse d'un binaire sans code source pour comprendre son fonctionnement et évaluer sa sécurité. Analyse statique avec Ghidra, analyse dynamique, modèle de menace, recensement des vulnérabilités et corrections à plusieurs niveaux.

2026GhidraReverse engineeringAnalyse statiqueAnalyse dynamique