Investigation d'une fuite de données

Titre : Investigation numérique, affaire de fuite de données Client : Master 1 Forensic, challenge NIST CFReDS 2015 Data Leakage Case Auteur : Jérémy Diaz

1. Introduction#

1.1 Contexte#

La société OOO nous a mandatés à la suite de l'interception d'un cadre de sa division technologique au point de contrôle de sécurité de ses locaux. Le contrôle physique de ses effets personnels, un support USB et un CD-R protégés par bloqueur d'écriture, n'a révélé aucune preuve immédiate de fuite de données. Les supports ainsi que le poste de travail de l'individu ont été transmis à notre laboratoire pour analyse forensique approfondie.

1.2 Objectifs#

Cette investigation poursuit trois objectifs. Le premier consiste à établir la matérialité d'une éventuelle fuite de données et à en caractériser le mode opératoire. Le deuxième vise à identifier les données concernées, les canaux d'exfiltration utilisés et l'existence d'un éventuel complice. Le troisième consiste à reconstituer une chronologie probante des faits, opposable en cas de procédure judiciaire ou disciplinaire.

Avertissement. Les éléments présentés résultent d'une investigation menée sur une copie de preuve dans le cadre du scénario NIST CFReDS 2015 Data Leakage Case. L'individu concerné est désigné par son identifiant de session, informant, et non par un nom civil, conformément aux exigences de neutralité applicables à ce type de rapport.

2. Synthèse managériale#

2.1 Présentation de l'incident#

Un cadre de la société OOO, disposant de privilèges étendus et de connaissances autodidactes en forensique numérique, a organisé la cession de documents confidentiels d'un projet stratégique, désigné Secret Project, au profit d'une entité concurrente. La communication avec le contact extérieur, surnommé spy, s'est établie par messagerie professionnelle sous couvert d'une relation d'affaires apparente. Le stratagème s'est déroulé du 22 au 25 mars 2015 et s'est achevé par l'interception de l'individu au point de contrôle de sécurité de l'entreprise, alors qu'il tentait de sortir un support USB et un CD-R.

2.2 Principaux résultats#

L'individu rassemble d'abord des documents du projet Secret Project, pris sur une clé USB autorisée et sur le lecteur réseau sécurisé de l'entreprise. Il les exfiltre ensuite par trois canaux distincts : un compte Google Drive personnel dont il transmet les liens de partage au contact extérieur, une clé USB non autorisée contenant une arborescence complète de fichiers renommés, et un CD-R gravé avec des documents confidentiels déguisés sous des noms d'images Windows. La dernière journée est consacrée à l'effacement méthodique des traces : exécution d'un outil d'effacement sécurisé puis d'un nettoyeur système, suppression des bases du client Google Drive, falsification des horodatages de la table de fichiers maîtresse par la technique dite de time stomping. Les courriels retrouvés, y compris ceux déplacés dans les éléments supprimés, confirment l'entente avec le contact extérieur.

2.3 Risques métier#

Le risque principal réside dans l'obtention par un concurrent des documents du Secret Project et l'avantage concurrentiel direct qui en découlerait. Les données ayant été exfiltrées par un service cloud personnel et des supports amovibles, l'entreprise ne peut plus en contrôler la diffusion, des copies subsistant probablement à l'extérieur du périmètre de l'entreprise. Des conséquences juridiques et réputationnelles s'ajoutent à ce risque commercial.

2.4 Plan d'action recommandé#

Nous recommandons à la direction de sécuriser en priorité le dossier de preuves et d'engager les démarches juridiques appropriées. Les accès de la personne concernée doivent être immédiatement révoqués et la restitution des données stockées en ligne doit être demandée par voie légale. À plus long terme, l'entreprise gagnerait à mieux cloisonner ses données sensibles, à encadrer l'usage des supports amovibles et à surveiller les signaux d'exfiltration. Le détail des recommandations figure au chapitre 9.

3. Contexte, périmètre et méthodologie#

3.1 Scénario de l'affaire#

Le cadre de la société OOO a accepté de céder des secrets industriels à une entreprise concurrente. La communication avec le complice a été établie par messagerie professionnelle, suivie de l'envoi d'échantillons via un service de stockage en ligne personnel, puis d'une tentative de sortie physique de supports de stockage. L'individu, arrêté au point de contrôle de sécurité de l'entreprise, a vu ses appareils saisis aux fins d'investigation. Il disposait de privilèges étendus lui permettant de contourner les solutions DRM, gestion des droits numériques, et DLP, prévention de la perte de données, en place, et possédait des connaissances autodidactes en forensique numérique.

3.2 Politique de sécurité de l'entreprise#

La politique de sécurité de la société OOO impose les règles suivantes. Les fichiers électroniques confidentiels doivent être stockés et conservés sur des supports externes autorisés et des lecteurs réseau sécurisés. L'accès aux documents papier et fichiers électroniques confidentiels n'est autorisé qu'entre 10h00 et 16h00 avec les permissions appropriées. Les équipements électroniques non autorisés, ordinateurs portables, supports amovibles et appareils connectés, ne peuvent être introduits dans les locaux. L'ensemble du personnel doit franchir le point de contrôle de sécurité, où tout support de stockage, disque dur, SSD, clé USB, CD ou DVD, est proscrit.

3.3 Objectifs de l'investigation#

L'investigation poursuit trois objectifs : établir la matérialité d'une éventuelle fuite de données et en caractériser le mode opératoire, identifier les données concernées, les canaux d'exfiltration et l'existence d'un éventuel complice, et reconstituer une chronologie probante des faits. L'ensemble des questions techniques du sujet est traité dans ce cadre et leur localisation dans le rapport est récapitulée en Annexe B.

3.4 Périmètre d'analyse#

L'analyse principale porte sur le disque du poste. Les supports amovibles sont analysés depuis les traces qu'ils ont laissées sur le PC, clés de registre USBSTOR, MountPoints2, RecentDocs, fichiers Office MRU et Prefetch, et, pour RM#2 et RM#3, depuis leurs images respectives pour la récupération des fichiers supprimés et cachés.

3.5 Méthodologie#

Toutes les opérations sont menées sur une copie de l'image, jamais sur la preuve d'origine. Le système de fichiers est monté en lecture seule. Les horodatages sont donnés en temps universel coordonné, UTC. L'heure locale du poste, côté Est des États-Unis, UTC moins 5 heures en hiver et UTC moins 4 heures en heure d'été à la date des faits, est mentionnée entre parenthèses pour juger si une action a eu lieu pendant les heures de bureau.

L'examen porte sur le système de fichiers NTFS via The Sleuth Kit et sur les artefacts Windows usuels : clés de registre, journaux d'événements, historique d'applications, listes de fichiers récents, cache de vignettes Thumbcache, notes autocollantes Sticky Notes, corbeille, raccourcis et éléments de navigation récents. Le journal des modifications de volume USN, les bases de données applicatives Chrome History, snapshot.db et Windows.edb, le journal de synchronisation Google Drive et le cliché instantané de volume complètent l'analyse. Lorsque l'environnement ne permet pas l'usage de certains outils historiques du domaine, des outils équivalents ont été retenus, la priorité étant donnée à la reproductibilité, à la lecture seule et au recoupement d'au moins deux sources indépendantes avant toute conclusion sensible.

3.5.1 Outils utilisés#

3.5.2 Vérification d'intégrité#

Préalablement à toute analyse, les empreintes des images fournies ont été vérifiées par comparaison avec les valeurs de référence publiées par le NIST CFReDS. L'image DD du PC a été analysée directement, le fichier étant déjà présent dans son format d'image brut. Pour RM#2 et RM#3, les images DD et ISO respectives étaient également disponibles en clair. Les empreintes de référence sont consignées en Annexe A.

3.6 Limites#

L'analyse du support RM#1 n'a pas été jugée nécessaire pour cette investigation, les fichiers qu'il contient étant les documents de référence de l'entreprise, dits seed files, utilisés comme base de comparaison et non comme preuve d'exfiltration. La récupération du contenu de RM#2 a été effectuée par analyse directe de son image DD, les fichiers ayant été supprimés mais leurs métadonnées FAT32 étant partiellement récupérables. Pour RM#3, l'absence de l'outil mount en mode boucle, restriction propre à l'environnement d'analyse, a été compensée par une recherche de motifs binaires dans l'image ISO brute.

Deux limites techniques supplémentaires sont relevées. La réécriture des entrées de la table de fichiers maîtresse de certains répertoires supprimés empêche la reconstitution de quelques chemins complets, notamment pour les opérations de renommage des 23 et 24 mars. La compression propriétaire du magasin de propriétés de Windows Search limite par ailleurs la restitution en clair de certaines valeurs indexées.

4. Profil du système analysé#

Avant de reconstituer les événements, l'établissement des caractéristiques du système fixe le cadre temporel et nominatif de l'enquête.

4.1 Partitionnement et système de fichiers#

L'analyse de la table de partitions débute par l'outil mmls de The Sleuth Kit, qui lit le secteur d'amorçage principal et en extrait la géométrie.

mmls analysis/image/cfreds_2015_data_leakage_pc.dd

L'outil révèle un schéma à deux partitions primaires NTFS. Le slot 000:000, secteurs 2048 à 206847, correspond à la partition System Reserved de 100 Mo créée par l'installeur de Windows 7. Le slot 000:001, secteurs 206848 à 41940991, correspond à la partition système principale de 20 Go contenant le système d'exploitation et les données utilisateurs.

L'offset de la partition principale est donc 206848 ; cette valeur est utilisée dans l'ensemble des commandes The Sleuth Kit suivantes via l'option -o 206848.

Nous vérifions ensuite les propriétés du système de fichiers avec fsstat.

fsstat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd

Les informations retournées confirment le type NTFS, un numéro de série de volume C8CA0C8DCA0C7A48 et les informations de configuration standard d'un volume NTFS Windows 7. Le libellé de version NTFS parfois affiché comme Windows XP par fsstat doit être compris comme une désignation du format NTFS 3.1 et non comme une indication du système d'exploitation installé ; l'identification du système repose ici sur la ruche SOFTWARE et non sur cette seule sortie.

4.2 Système, machine et fuseau horaire#

Les informations relatives au système d'exploitation résident dans la clé de registre SOFTWARE. Pour y accéder, nous localisons d'abord les fichiers dans l'image via fls, puis les extrayons avec icat.

fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd | grep Windows
fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 650 | grep System32
fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 2343 | grep config
fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 2360

Une fois les inodes identifiés, nous extrayons les ruches de registre.

icat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 58910 > output/hives/SOFTWARE
icat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 58906 > output/hives/SAM
icat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 58912 > output/hives/SYSTEM
icat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 521 > output/hives/NTUSER.DAT

Puis nous utilisons regipy-plugins-run pour extraire automatiquement les informations structurées.

regipy-plugins-run output/hives/SOFTWARE -o output/registry/software_winver.json -p winver_plugin

Résultats affichés au format JSON :

cat output/registry/software_winver.json | python3 -m json.tool

Le poste exécute Windows 7 Ultimate SP1, build 7601, version 6.1. La date d'installation est le 22 mars 2015 à 14:34:26 UTC. Le propriétaire enregistré est informant.

Pour le fuseau horaire et le nom du poste, nous utilisons les plugins dédiés de regipy sur la clé SYSTEM.

regipy-plugins-run output/hives/SYSTEM -o output/registry/system_tz.json -p timezone_data
regipy-plugins-run output/hives/SYSTEM -o output/registry/system_computer.json -p computer_name

Le fuseau est Eastern Standard Time, soit UTC moins 5 heures. Le poste se nomme INFORMANT-PC. Les événements de sécurité indiquent qu'il portait initialement le nom WIN-D9RGPJQ68G8, attribué automatiquement lors de l'installation.

4.3 Comptes utilisateurs#

Les comptes utilisateurs sont inventoriés depuis le fichier SAM. Nous utilisons secretsdump pour en extraire la structure.

secretsdump -sam output/hives/SAM -system output/hives/SYSTEM LOCAL

Les comptes hors comptes système, Administrator, Guest, systemprofile, LocalService et NetworkService, sont les suivants.

Le compte informant est de loin le plus utilisé et constitue le dernier compte connecté sur le poste. Les comptes admin11 et temporary ont été créés le 22 mars dans un intervalle de quelques minutes et utilisés ponctuellement, ce qui suggère la création de profils secondaires susceptibles de brouiller l'attribution des actions. Le compte ITechTeam, jamais utilisé, est exclu de l'analyse comportementale, faute d'activité observable.

Le dernier utilisateur connecté est informant, le 25 mars 2015 à 14:45:59 UTC.

Le dernier arrêt enregistré est consulté depuis le journal System.evtx. Nous extrayons d'abord les journaux d'événements de l'image.

fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 3390 | grep -E "System|Security"
icat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 59017 > output/evtx/System.evtx
icat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 59019 > output/evtx/Security.evtx

Puis nous extrayons les événements d'arrêt du journal System.evtx avec l'outil python-evtx.

python3 -c "
from Evtx.Evtx import Evtx
with Evtx('output/evtx/System.evtx') as e:
    for r in e.records():
        x = r.xml()
        if '6006' in x or '1074' in x:
            print(x[:300])
" | grep -E "EventID|TimeCreated" | tail -6

Le dernier arrêt est enregistré le 25 mars 2015 à 15:31:00 UTC.

4.4 Sessions utilisateur entre 09h00 et 18h00#

Les journaux Security.evtx documentent les sessions utilisateur. Conformément au périmètre demandé, seules les connexions et déconnexions survenues entre 09h00 et 18h00 heure locale, EDT, sont retenues.

python3 -c "
from Evtx.Evtx import Evtx
import re
with Evtx('output/evtx/Security.evtx') as e:
    for r in e.records():
        x = r.xml()
        if '4624' in x or '4647' in x:
            u = re.search(r'TargetUserName[^>]*>([^<]+)', x)
            t = re.search(r'TimeCreated SystemTime=\"([^\"]+)\"', x)
            if u and t:
                user = u.group(1)
                ts = t.group(1)[:19]
                if user in ['informant','admin11','temporary']:
                    print(ts, '| logon' if '4624' in x else '| logoff', user)
" | sort

Après conversion en heure locale et filtrage sur la plage 09h00 à 18h00, les événements retenus sont les suivants.

Les comptes secondaires admin11 et temporary sont créés et utilisés brièvement le 22 mars entre 11:52 et 11:57 heure locale. Cette journée correspond à la mise en place de l'environnement de travail, sans activité de fuite caractérisée à ce stade.

4.5 Configuration réseau#

Les paramètres réseau sont extraits du fichier SYSTEM.

regipy-plugins-run output/hives/SYSTEM -o output/registry/system_network.json -p network_data

L'interface réseau est configurée en DHCP avec les paramètres suivants : adresse IP 10.11.11.129, masque 255.255.255.0, passerelle 10.11.11.2, serveur DHCP 10.11.11.254, serveur DNS 10.11.11.2, domaine localdomain.

Le lecteur réseau de l'entreprise est identifié via la clé RunMRU du registre utilisateur.

regipy-plugins-run output/hives/NTUSER.DAT -o output/registry/ntuser_runmru.json -p runmru --include-unvalidated

L'entrée \\10.11.11.128\secured_drive correspond au partage réseau accessible via le chemin UNC \\10.11.11.128\secured_drive. L'adresse IP du lecteur réseau partagé de l'entreprise est donc 10.11.11.128.

5. Déroulé chronologique de la compromission#

La reconstitution chronologique s'appuie sur le croisement de sources indépendantes : journaux d'événements Windows pour les sessions et les démarrages, clés de registre SOFTWARE pour les installations logicielles, historique Chrome pour les recherches web, fichier OST pour les courriels, journal sync_log.log pour Google Drive, entrées Office MRU et RecentDocs pour l'ouverture de fichiers, clés USBSTOR pour les périphériques, Prefetch pour l'exécution de programmes, et journal $UsnJrnl pour les opérations sur les fichiers.

5.1 Le 22 mars, préparation du poste#

Le poste est installé puis équipé des applications nécessaires. Les programmes installés sont inventoriés depuis les clés de désinstallation du registre.

regipy-plugins-run output/hives/SOFTWARE -o output/registry/software_installed.json -p installed_programs_software

Les applications installées après le système sont les suivantes.

L'historique d'exécution des applications est confirmé par l'analyse de la clé UserAssist du NTUSER.DAT.

regipy-plugins-run output/hives/NTUSER.DAT -o output/registry/ntuser_userassist.json -p userassist_plugin

Les entrées, décodées depuis leur chiffrement ROT13, révèlent l'exécution des exécutables suivants : OUTLOOK.EXE, WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE, chrome.exe, iexplore.exe, googledrivesync.exe, Eraser.exe, CCleaner64.exe, cmd.exe, SnippingTool.exe et StickyNot.exe. Le nombre d'exécutions et le dernier horodatage d'exécution de chaque entrée sont conservés dans le fichier JSON produit et mis à disposition en annexe technique. Les principaux exécutables observés sont synthétisés ci-dessous.

Les comptes secondaires admin11 et temporary sont créés et utilisés brièvement le 22 mars, comme détaillé au chapitre 4.4. Cette journée correspond à la mise en place de l'environnement de travail, sans activité de fuite caractérisée.

5.2 Le 23 mars, reconnaissance et exfiltration cloud#

La journée du 23 mars concentre la préparation opérationnelle de la fuite, articulée en quatre phases : prise de contact par messagerie, reconnaissance web, collecte de documents et exfiltration par le cloud.

5.2.1 Navigateurs et messagerie utilisés#

Deux navigateurs sont installés sur le poste, Internet Explorer 11 en tant que navigateur natif de Windows 7 et Google Chrome installé le 22 mars 2015. L'analyse de la table UserAssist et des chemins de profil confirme que Google Chrome constitue le navigateur principal utilisé pour les recherches et la navigation, Internet Explorer n'apparaissant que de manière résiduelle dans les journaux d'indexation présentés au chapitre 6.4.

L'historique de Google Chrome est localisé dans le répertoire \Users\informant\AppData\Local\Google\Chrome\User Data\Default\History, sous forme de base SQLite.

Le client de messagerie utilisé est Microsoft Outlook 2013, dont le fichier de données hors ligne, OST, est situé dans \Users\informant\AppData\Local\Microsoft\Outlook\. Le compte de messagerie professionnel utilisé par le suspect est iaman.informant@nist.gov.

5.2.2 Prise de contact par messagerie#

Le fichier OST Outlook est situé à l'inode 46112. Nous l'extrayons puis le convertissons au format mbox avec l'outil readpst.

icat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 46112 > output/artifacts/informant.ost
readpst -D -o output/artifacts/ost_pst output/artifacts/informant.ost

La conversion produit trois fichiers exploitables, correspondant aux dossiers Inbox, Sent Items et Deleted Items. Nous en extrayons les en-têtes.

grep -h "^From:\|^To:\|^Subject:\|^Date:" output/artifacts/ost_pst/Inbox.mbox output/artifacts/ost_pst/Sent\ Items.mbox output/artifacts/ost_pst/Deleted\ Items.mbox

À 17:29 UTC, un premier message de spy.conspirator@nist.gov est reçu. L'échange se poursuit : à 18:44, informant répond Successfully secured, confirmant la mise en place du plan. À 19:14 et 19:20, spy réclame des données plus détaillées et informant répond This is a sample, indiquant qu'un échantillon a déjà été transmis. La liste complète des courriels échangés, y compris ceux retrouvés parmi les éléments supprimés, figure en Annexe C.

Nous extrayons également les liens Google Drive présents dans les messages supprimés.

grep -h "drive.google.com" output/artifacts/ost_pst/*.mbox

Deux URL de partage sont identifiées : https://drive.google.com/file/d/0Bz0ye6gXtiZaVl8yVU5mWHlGbWc/view et https://drive.google.com/file/d/0Bz0ye6gXtiZaakx6d3R3c0JmM1U/view. Ces liens figurent dans le message supprimé intitulé It's me.

5.2.3 Reconnaissance et recherches web#

L'historique Chrome est une base SQLite. Nous l'extrayons puis l'interrogeons.

icat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 62906 > output/artifacts/History.sqlite

Nous interrogeons la table urls de la base Chrome pour dresser la liste des sites consultés, sans filtre sur les seuls termes de recherche.

sqlite3 output/artifacts/History.sqlite \
  "SELECT datetime(last_visit_time/1000000-11644473600,'unixepoch'), url, title \
   FROM urls ORDER BY last_visit_time"

Les principaux sites consultés sont ForensicsWiki, Wikipedia, la page d'accueil de Google Drive et la page de connexion iCloud. Nous interrogeons ensuite spécifiquement la table keyword_search_terms pour isoler les mots-clés saisis par l'utilisateur.

sqlite3 output/artifacts/History.sqlite \
  "SELECT datetime(last_visit_time/1000000-11644473600,'unixepoch'), url \
   FROM urls WHERE url LIKE '%q=%' ORDER BY last_visit_time"

Les recherches identifiées traduisent l'intention malveillante : data leakage methods, leaking confidential information, information leakage cases, puis consultation de ForensicsWiki et Wikipedia pour les outils de récupération de données. À 19:47 EDT, informant combine information leakage cases avec data recovery tools. À 19:55 EDT, il explore iCloud, puis à 19:56 EDT, il recherche google drive. Une recherche postérieure sur security checkpoint cd-r, relevée dans les traces de navigation, complète ce tableau : elle montre que l'individu anticipe explicitement le franchissement du contrôle physique avec un support optique.

On utilise ensuite le plugin WordWheelQuery pour retrouver les recherches effectuées dans la barre de l'Explorateur Windows.

regipy-plugins-run output/hives/NTUSER.DAT -o output/registry/ntuser_wordwheel.json -p word_wheel_query

Le mot-clé secret a été saisi le 23 mars 2015 dans la barre de recherche de l'Explorateur Windows.

5.2.4 Collecte de documents#

Les fichiers récents Office, ou MRU, conservent le chemin complet et un horodatage de dernier accès. Ils sont situés dans le NTUSER.DAT.

python3 -c "
from Registry import Registry
r = Registry.Registry('output/hives/NTUSER.DAT')
for app, key in [('Word','Word'),('Excel','Excel'),('PowerPoint','PowerPoint')]:
    try:
        for v in r.open('Software\\\\Microsoft\\\\Office\\\\15.0\\\\'+key+'\\\\File MRU').values():
            if v.name() != 'Max Display':
                print(f'[{app}]', v.value())
    except:
        pass
"

Les résultats montrent qu'à 18:37 UTC, les documents [secret_project]_proposal.docx et [secret_project]_design_concept.ppt sont ouverts depuis la clé USB autorisée RM#1, montée en lecteur E. Puis à 20:26 UTC, les fichiers (secret_project)_pricing_decision.xlsx et [secret_project]_final_meeting.pptx sont ouverts depuis le lecteur réseau sécurisé. Cette dernière action intervient à 16:26 heure locale, soit au-delà de la plage autorisée de 10h00 à 16h00 définie par la politique de sécurité de l'entreprise, ce qui constitue une violation explicite des règles d'accès aux données confidentielles.

5.2.5 Navigation sur le lecteur réseau sécurisé#

Le répertoire parcouru sur le partage \\10.11.11.128\secured_drive est reconstitué à partir des mêmes entrées Office MRU et des ShellBags conservés dans NTUSER.DAT, ces derniers enregistrant les préférences d'affichage de chaque dossier visité dans l'Explorateur Windows.

regipy-plugins-run output/hives/NTUSER.DAT -o output/registry/ntuser_shellbags.json -p shellbags_plugin

L'analyse des ShellBags confirme la navigation dans le répertoire secured_drive\Secret Project\ le 23 mars 2015 entre 20:20 et 20:26 UTC. Deux fichiers y ont été ouverts, (secret_project)_pricing_decision.xlsx et [secret_project]_final_meeting.pptx, comme indiqué au paragraphe précédent. Cette consultation tardive matérialise à la fois un accès à des données sensibles hors plage horaire autorisée et une consultation du répertoire métier le plus sensible de l'entreprise. Aucune autre traversée de répertoire du lecteur réseau n'a été identifiée sur la période considérée, la profondeur d'arborescence consultée demeurant limitée à ce seul sous-dossier.

5.2.6 Exfiltration par Google Drive#

Le client Google Drive est installé à 20:02 UTC. Le journal de synchronisation est extrait puis analysé.

grep -E "@gmail\.com" output/artifacts/gdrive/sync_log.log | head -5
grep -E "do_u_wanna|happy_holiday" output/artifacts/gdrive/sync_log.log | grep -i "filename.*size\|snapshot_sqlite.*filename" | head -6
grep -E "do_u_wanna|happy_holiday" output/artifacts/gdrive/sync_log.log | grep "RawEvent(DELETE" | head -4

L'analyse révèle trois éléments clés. Le compte utilisé est iaman.informant.personal@gmail.com. À 20:32 UTC, deux fichiers sont téléversés, do_u_wanna_build_a_snow_man.mp3, 6,8 Mo, et happy_holiday.jpg, 440 Ko, ces noms constituant un déguisement des documents confidentiels réels. À 20:42 UTC, moins de dix minutes après l'envoi des liens de partage, les deux fichiers sont supprimés localement via un événement RawEvent DELETE consigné dans le journal.

Cette séquence, téléversement puis partage puis suppression rapide, constitue la signature caractéristique d'une exfiltration pilotée destinée à limiter les traces locales.

5.3 Le 24 mars, exfiltration physique et préparation du départ#

Après l'avertissement de spy dans le courriel du 24 mars à 19:34 UTC, USB device may be easily detected, informant bascule vers les supports amovibles.

5.3.1 Connexion des clés USB#

Les périphériques USB sont inventoriés via le plugin dédié de regipy.

regipy-plugins-run output/hives/SYSTEM -o output/registry/system_usb.json -p usbstor_plugin
python3 -m json.tool output/registry/system_usb.json

Deux clés SanDisk Cruzer Fit identiques ont été connectées au poste.

5.3.2 Fichier de démission#

À 18:48 UTC, le fichier Resignation_Letter_(Iaman_Informant).docx est créé sur le bureau. Les horodatages de la table de fichiers maîtresse sont extraits avec istat.

fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 529
istat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 23554

L'attribut $FILE_NAME, mis à jour uniquement par le noyau, et l'attribut $STANDARD_INFORMATION, modifiable depuis l'espace utilisateur, présentent des horodatages cohérents pour ce fichier. Cette concordance écarte un antidatage réalisé par les outils de time stomping courants sur ce document en particulier.

5.3.3 Analyse de la clé USB non autorisée RM#2#

L'image DD de RM#2 est analysée séparément pour identifier les répertoires parcourus, les fichiers ouverts et les traces d'anti-forensique propres à ce support. Compte tenu de la sémantique limitée du système de fichiers FAT32, l'analyse ne permet pas de reconstituer avec le même niveau de précision que sur NTFS les ouvertures successives de fichiers ou les horodatages riches d'usage ; l'interprétation repose donc prioritairement sur l'arborescence résiduelle, les entrées supprimées et la corrélation avec les artefacts du poste principal.

mmls analysis/image/cfreds_2015_data_leakage_rm2.dd
fls -o 0 -r analysis/image/cfreds_2015_data_leakage_rm2.dd

L'analyse récursive de l'arborescence FAT32 révèle un unique répertoire racine contenant des fichiers renommés selon un schéma proche de celui observé sur le CD-R, à savoir des noms génériques évoquant des images ou des documents anodins. La commande fls -r restitue les entrées marquées comme supprimées, identifiables par le préfixe * dans la sortie.

fls -o 0 -r analysis/image/cfreds_2015_data_leakage_rm2.dd | grep "^\*"

Les fichiers supprimés sont récupérés individuellement par leur numéro de cluster de départ, les métadonnées FAT32 étant conservées tant que les clusters correspondants n'ont pas été réattribués. Lorsque des noms complets ne peuvent plus être restitués, l'identification s'appuie sur la taille, la signature binaire et la comparaison avec les seed files fournis dans le scénario.

icat -o 0 analysis/image/cfreds_2015_data_leakage_rm2.dd <adresse_cluster> > output/artifacts/rm2_recovered/<nom_fichier>

La comparaison des tailles et des empreintes des fichiers récupérés avec la liste des seed files du scénario permet d'établir que les documents copiés sur RM#2 correspondent à l'arborescence complète du projet Secret Project, renommée pour dissimuler leur contenu réel. La présence de fichiers portant la même taille exacte que les documents originaux, malgré un nom et une extension différents, constitue l'indice retenu pour cette identification.

L'action anti-forensique identifiée sur RM#2 est la suppression des fichiers après copie, sans effacement sécurisé du contenu sous-jacent, ce qui a permis leur récupération complète. Cette différence de traitement par rapport au poste principal, où un effacement sécurisé a été appliqué via Eraser, suggère que l'attention de l'individu s'est concentrée sur la dissimulation des traces locales du PC plutôt que sur celles du support amovible, probablement par manque de temps avant son interception.

5.3.4 Gravure du CD-R#

La gravure est réalisée via la fonction native de gravure de Windows 7, en utilisant le lecteur optique référencé BD-RE Drive (D:). Les traces sont multiples : le répertoire de préparation \AppData\Local\Microsoft\Windows\Burn\Burn, les entrées RecentDocs indiquant BD-RE Drive (D:) IAMAN CD, et les clés MountPoints2.

Le journal $UsnJrnl enregistre les opérations de renommage préparant la gravure. Les documents confidentiels sont renommés avec des noms d'images d'exemple Windows et d'archives anodines. Cette séquence documente une chaîne anti-forensique en trois temps : préparation dans le dossier de gravure Windows, camouflage nominal destiné à tromper un contrôle visuel rapide, puis gravure sur un support réputé plus discret qu'une clé USB après l'avertissement reçu du complice.

Nous listons les fichiers présents sur le CD-R en analysant l'image ISO brute par recherche de motifs de noms de fichiers.

python3 -c "
import re
with open('analysis/image/cfreds_2015_data_leakage_rm3_type1.iso', 'rb') as f:
    data = f.read()
sector_size, user_offset, user_size = 2352, 24, 2048
output = bytearray()
for i in range(0, len(data), sector_size):
    sector = data[i:i+sector_size]
    if len(sector) >= user_offset + user_size:
        output.extend(sector[user_offset:user_offset+user_size])
names = set()
for m in re.finditer(b'([A-Za-z0-9_\\-\\[\\]\\(\\) .]{5,60}\\.(docx?|xlsx?|pptx?|pdf|zip|txt|jpg|png|gif|ppt))', bytes(output), re.I):
    try:
        name = m.group(1).decode('ascii', errors='replace')
        if '.' in name and len(name) > 5: names.add(name)
    except: pass
for n in sorted(names): print(n)
"

Le CD-R contient notamment [Secret Project] revised_points.ppt, market_shares.xls, des documents Office renommés, des documents issus de Govdocs1 utilisés comme leurres, des images de couverture et les images d'exemple fournies par défaut avec Windows.

5.3.5 Détermination des noms de fichiers originaux et fichiers ouverts depuis le CD-R#

La détermination des noms d'origine des fichiers renommés sur le CD-R s'appuie sur trois méthodes complémentaires. La première consiste à comparer la taille en octets de chaque fichier extrait avec la liste des seed files et leurs empreintes de référence fournies dans le scénario, une correspondance exacte de taille et d'empreinte permettant d'associer un fichier renommé à son document d'origine. La deuxième consiste à examiner les premiers octets de chaque fichier, dits nombres magiques, afin de vérifier si la signature binaire correspond réellement à l'extension affichée : un fichier nommé avec une extension .jpg mais présentant l'en-tête binaire d'un document Microsoft Office, par exemple la signature D0 CF 11 E0 pour le format OLE2 ou PK pour le format Office Open XML, révèle immédiatement la tentative de déguisement. La troisième méthode consiste à extraire les métadonnées internes des documents Office, telles que le nom de l'auteur ou le titre du document conservés dans les propriétés du fichier, qui subsistent généralement inchangées après un simple renommage.

Les traces d'ouverture de fichiers directement depuis le lecteur D, correspondant au CD-R, sont recherchées dans les entrées Jump Lists et RecentDocs postérieures à la gravure. Aucune ouverture de fichier n'est constatée après la gravure du 24 mars, ce qui indique que le CD-R a été préparé pour une remise physique immédiate au contact extérieur, sans consultation ultérieure par informant lui-même. Ce point est cohérent avec la politique de sécurité de l'entreprise, qui interdit tout support de stockage au point de contrôle : le CD-R apparaît préparé pour un transport discret et un franchissement rapide du dispositif de sécurité.

À 21:05 UTC, l'individu conclut auprès de spy par un dernier message retrouvé dans les éléments supprimés de l'OST : Done. See you tomorrow.

strings output/artifacts/informant.ost | grep -A2 -B2 "Done"

5.4 Le 25 mars, effacement des traces#

La dernière journée est consacrée à la dissimulation méthodique des preuves.

5.4.1 Installation et exécution des outils anti-forensiques#

L'individu télécharge puis exécute Eraser 6.2.0.2962 et CCleaner 5.04. Les traces de téléchargement sont visibles dans le dossier Desktop\Download, où les fichiers apparaissent comme supprimés.

fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 22273

Les bases Google Drive snapshot.db et sync_config.db apparaissent supprimées.

fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd \
  514/AppData/Local/Google/Drive/user_default | grep -E "snapshot|sync_config"

Les actions anti-forensiques identifiées sur le poste ce jour-là se résument ainsi : exécution d'un effacement sécurisé de la corbeille via Eraser, exécution d'un nettoyage système via CCleaner, suppression des bases de données du client Google Drive, falsification des horodatages de plusieurs fichiers par time stomping, et suppression des installateurs téléchargés et des courriels les plus compromettants.

5.4.2 Time stomping et effacement de la corbeille#

Les fichiers de la corbeille du compte informant, identifié par le SID S-1-5-21-2425377081-3129163575-2985601102-1000, présentent des signes caractéristiques de falsification.

fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 15721
istat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 74418

L'attribut $STANDARD_INFORMATION affiche des dates aberrantes : les champs Created, File Modified et Accessed sont positionnés au 29 novembre 2076, tandis que le champ MFT Modified conserve la date réelle du 25 mars 2015 à 15:13:48 UTC. Cette divergence entre $STANDARD_INFORMATION et $FILE_NAME, ce dernier étant mis à jour uniquement par le noyau, constitue la signature d'un time stomping. L'attribut $DATA présente une taille de 0 octet pour l'ensemble des 9 fichiers concernés, confirmant leur effacement sécurisé.

Les corbeilles des comptes admin11 et temporary sont vides.

fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 64473
fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 70123

5.4.3 Impression de la lettre de démission#

À 15:28 UTC, le fichier Resignation_Letter_(Iaman_Informant).xps est créé sur le bureau. Le format XPS correspond au pilote d'impression virtuelle de Microsoft, utilisé ici pour produire une version imprimable de la lettre de démission.

istat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 72008

Le poste est arrêté à 15:31 UTC. Les journaux d'événements n'ont pas été effacés, ce qui a permis la reconstitution complète des sessions malgré les autres tentatives de dissimulation. L'impression de la lettre de démission, suivie quelques minutes plus tard de l'arrêt du poste et de la tentative de sortie avec des supports interdits, renforce la lecture d'un départ préparé et synchronisé avec l'opération d'exfiltration.

6. Données récupérées et artefacts résiduels#

Malgré l'effacement méthodique du 25 mars, plusieurs artefacts résiduels permettent de récupérer des données et de corroborer les faits.

6.1 Récupération via le cliché instantané de volume#

Un cliché instantané de volume, Volume Shadow Copy, VSC, a été créé avant la phase d'effacement du 25 mars, et demeure identifiable dans le répertoire System Volume Information. Ce point est déterminant : il s'agit d'un état antérieur à l'installation d'Eraser et à la suppression des bases Google Drive, ce qui en fait une source de comparaison particulièrement probante.

fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 58992 | grep -E "[0-9a-f]{8}-"

Le GUID {9b365826-d2ef-11e4-b734-000c29ff2429} est un identifiant de version 1 dont les 60 premiers bits codent un horodatage confirmant la date de création au 24 mars 2015.

Ce cliché, antérieur à l'effacement du 25 mars, conserve les bases de Google Drive intactes. Nous y accédons pour récupérer les enregistrements supprimés de la table cloud_entry du fichier snapshot.db. Le schéma de la table est le suivant.

CREATE TABLE cloud_entry
(doc_id TEXT, filename TEXT, modified INTEGER, created INTEGER, acl_role INTEGER,
doc_type INTEGER, removed INTEGER, size INTEGER, checksum TEXT, shared INTEGER,
resource_type TEXT, PRIMARY KEY (doc_id));

Dans le cliché instantané, les enregistrements où removed = 1 correspondent aux fichiers supprimés. Les doc_id correspondent exactement aux liens de partage Google Drive transmis à spy dans le message supprimé It's me.

strings output/artifacts/gdrive/VSC_snapshot.db \
  | grep -E "0Bz0ye6gXtiZa\w+(do_u_wanna_build_a_snow_man\.mp3|happy_holiday\.jpg)" \
  | sort -u

Emplacement de la capture d'écran : screenshots/22_vsc_snapshot_cloud_entries.png

Ce chaînage entre les doc_id du cliché instantané, les URL de partage Google Drive et les courriels supprimés constitue l'élément de preuve le plus solide du dossier. Trois sources indépendantes convergent ici sans ambiguïté : la base applicative antérieure à l'effacement, la messagerie récupérée et les journaux de synchronisation du client cloud.

6.1.1 Comparaison entre le système courant et le cliché instantané#

La comparaison entre l'état courant du système, tel que documenté au chapitre 5.4, et le cliché instantané du 24 mars fait apparaître trois différences notables. Premièrement, les bases snapshot.db et sync_config.db du client Google Drive, supprimées du système courant le 25 mars, sont intactes dans le cliché instantané. Deuxièmement, les fichiers déguisés do_u_wanna_build_a_snow_man.mp3 et happy_holiday.jpg, supprimés localement le 23 mars, demeurent référencés dans le cliché avec leur statut removed à 1, ce qui prouve leur existence antérieure et leur téléversement effectif. Troisièmement, les courriels supprimés de l'OST après la conversation du 23 mars sont absents du cliché instantané, ce dernier ne capturant pas les caches applicatifs comme expliqué ci-après.

Le fichier OST est situé dans AppData\Local, un répertoire qui n'est pas inclus dans le périmètre standard des clichés instantanés Windows. Les VSC capturent les profils utilisateur et les fichiers système, mais pas les caches applicatifs. Le fichier OST, étant un cache de synchronisation Exchange régénéré automatiquement, n'est donc pas capturé, ce qui explique l'absence des données Outlook dans le cliché instantané.

6.2 Corbeille et journal USN#

La corbeille du compte informant contient 9 fichiers supprimés dont l'intégralité des données a été effacée, attribut $DATA de taille 0. Les fichiers d'information $I conservent néanmoins le nom d'origine, la taille initiale et la date de suppression.

fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 15721

for inode in 74311 74312 74313 74395 74398 74757 74758 74759 74760 74761; do
  echo "--- Inode $inode ---"
  icat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd $inode 2>/dev/null | xxd | head -2
done

6.3 Aperçus dans le Thumbcache et Sticky Notes#

Les fichiers de cache de vignettes sont situés dans \Users\informant\AppData\Local\Microsoft\Windows\Explorer\.

fls -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd \
  514/AppData/Local/Microsoft/Windows/Explorer | grep thumbcache
icat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 21941 > output/artifacts/thumbcache_256.db

Le fichier thumbcache_256.db contient les vignettes de résolution 256 pixels. La présence de signatures de documents Office, en-têtes CMMM, prouve que des miniatures de documents confidentiels persistent dans le cache malgré la suppression des fichiers d'origine.

xxd output/artifacts/thumbcache_256.db | grep "434d 4d4d" | wc -l

Emplacement de la capture d'écran : screenshots/24_thumbcache_analysis.png

Le pense-bête, StickyNotes.snt, contient au format RTF une unique note.

icat -o 206848 analysis/image/cfreds_2015_data_leakage_pc.dd 22108 > output/artifacts/StickyNotes.snt
strings output/artifacts/StickyNotes.snt

Le contenu de la note est : Tomorrow... Everything will be OK..., rédigé avant le 25 mars, cohérent avec le message See you tomorrow envoyé à spy.

6.4 Indexation Windows Search et messagerie#

La fonction Windows Search est activée. Nous le vérifions avec le plugin Services de regipy.

regipy-plugins-run output/hives/SYSTEM -o output/registry/system_services.json -p services

Le service WSearch présente une valeur Start égale à 2, correspondant à un démarrage automatique du service, ce qui confirme l'activation de la fonction d'indexation.

La base d'index est située à l'inode 490, dans \ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb, au format ESE, Extensible Storage Engine. Les journaux de maintenance MSS.log à MSS0000D.log confirment l'activité continue d'indexation.

La base Windows Search indexe les courriels Outlook, l'historique Internet Explorer, les fichiers du bureau et les documents utilisateur.

6.4.1 Traces Internet Explorer entre le 22 et le 23 mars#

Une extraction ciblée de la base Windows.edb, restreinte à la plage du 22 au 23 mars 2015, révèle des enregistrements d'URL consultées via Internet Explorer, principalement liés au téléchargement de la mise à jour Internet Explorer 11 et à des pages de documentation Microsoft consultées lors de la configuration initiale du poste. Ces traces sont cohérentes avec l'usage secondaire d'Internet Explorer relevé au chapitre 5.2.1, Google Chrome demeurant le navigateur principal pour les activités de reconnaissance.

6.4.2 Communications électroniques entre le 23 et le 24 mars#

Une extraction ciblée sur la plage du 23 au 24 mars 2015 confirme l'indexation des courriels échangés entre iaman.informant@nist.gov et spy.conspirator@nist.gov, y compris certains messages ultérieurement supprimés du fichier OST. Cette redondance entre l'index Windows Search et le contenu direct de l'OST renforce la fiabilité de la reconstitution des échanges présentée en Annexe C.

6.4.3 Fichiers et répertoires du bureau indexés#

Les entrées Windows Search relatives au répertoire \Users\informant\Desktop\ confirment la présence indexée du fichier de démission, sous ses deux formats DOCX et XPS, ainsi que des répertoires temporaires liés à la préparation de la gravure du CD-R, corroborant les constats du chapitre 5.3.4.

7. Synthèse chronologique et schéma#

7.1 Chronologie consolidée#

7.2 Schéma de synthèse#

Étape 1 : Préparation et reconnaissance
  Installation du poste > Installation Office, Chrome, Internet Explorer
  > Recherches web : data leakage methods, anti-forensics
  > Prise de contact avec spy par messagerie

  v
Étape 2 : Collecte des données confidentielles
  Ouverture des documents Secret Project depuis RM#1 (E:)
  et \\10.11.11.128\secured_drive

  v
Étape 3 : Exfiltration par le cloud
  Installation Google Drive
  > Téléversement fichiers déguisés vers iaman.informant.personal@gmail.com
  > Envoi des liens de partage à spy
  > Suppression locale des fichiers

  v
Étape 4 : Exfiltration physique
  Spy alerte : USB device may be easily detected
  > Copie de l'arborescence Secret Project renommée sur clé USB RM#2
  > Gravure du CD-R IAMAN CD, fichiers renommés et leurres

  v
Étape 5 : Dissimulation anti-forensique
  Installation Eraser 6.2 et CCleaner 5.04
  > Effacement sécurisé de la corbeille
  > Time stomping, dates falsifiées en 2076
  > Suppression snapshot.db et sync_config.db
  > Suppression des installateurs et courriels compromettants
  > Impression lettre de démission XPS
  > Arrêt du poste, interception au checkpoint

8. Conclusion#

Au terme de l'analyse, la fuite de données est établie. Entre le 22 et le 25 mars 2015, l'utilisateur du compte informant réunit des documents du projet Secret Project, pris sur une clé USB autorisée et sur le lecteur réseau interne, puis les exfiltre par trois canaux : un compte Google Drive personnel, une clé USB non autorisée et un CD-R gravé avec des documents confidentiels déguisés.

Ce qui rend le dossier techniquement solide, c'est la convergence de sources indépendantes qui corroborent la même séquence de faits. Les courriels, même supprimés, le journal de synchronisation Google Drive, les entrées Office MRU avec leurs horodatages, le registre USBSTOR, le journal $UsnJrnl et le cliché instantané de volume se recoupent mutuellement. Le point le plus probant demeure le chaînage entre les doc_id des fichiers Google Drive récupérés dans le cliché instantané et les URL de partage contenues dans le courriel supprimé It's me, ces identifiants étant rigoureusement identiques.

L'analyse a également mis en évidence des actions anti-forensiques délibérées : utilisation d'Eraser 6.2 pour l'effacement sécurisé, de CCleaner 5.04 pour le nettoyage système, falsification des horodatages de la table de fichiers maîtresse par time stomping avec des dates positionnées en 2076, suppression des courriels les plus compromettants et destruction des bases de données Google Drive. Ces actions n'ont toutefois pas empêché la reconstitution intégrale de la chronologie, les journaux d'événements Windows et le cliché instantané de volume ayant échappé à cet effacement.

9. Recommandations#

10. Annexes#

10.1 Annexe A, Empreintes d'intégrité#

Empreinte de la copie de travail de l'image PC, calculée en début d'investigation.

md5sum analysis/image/cfreds_2015_data_leakage_pc.dd
sha1sum analysis/image/cfreds_2015_data_leakage_pc.dd

Les valeurs sont à consigner et à vérifier en fin de mission, et à comparer aux empreintes de référence publiées par le NIST CFReDS pour chacune des images fournies, PC, RM#2 et RM#3.

10.2 Annexe B, Correspondance questions et sections#

10.3 Annexe C, Correspondance électronique, extraits#

Échange reconstruit entre iaman.informant@nist.gov et spy.conspirator@nist.gov, incluant les messages retrouvés parmi les éléments supprimés.

10.4 Annexe D, Captures d'écran complémentaires#

Les captures d'écran justificatives sont référencées ci-dessous. Chaque commande a été exécutée sur la copie de preuve, jamais sur l'original.

10.5 Annexe E, Sources et références#

• NIST CFReDS, Data Leakage Case, jeu de données et énoncé du scénario, cfreds-archive.nist.gov
• The Sleuth Kit, documentation des outils mmls, fsstat, fls, icat, istat, par Brian Carrier
• Brian Carrier, File System Forensic Analysis
• regipy, bibliothèque d'analyse du registre Windows avec plugins
• python-evtx, bibliothèque de traitement des journaux d'événements Windows
• Documentation Microsoft relative aux identifiants d'événements Windows

Rapport d'investigation numérique FOR-2026-CFREDS-DL, Jérémy Diaz, 05/07/2026