Jump List Parser
← Retour au blog

Forensique des Jump Lists : un guide pratique DFIR

2026-05-256 min de lecture

Les Jump Lists répondent à une question que d'autres artefacts contournent : quelle application a ouvert quel fichier, sur quel hôte, à quel moment. Après suffisamment de cas, vous cessez de vous tourner vers les ShellBags ou Prefetch comme premier mouvement sur une question "qu'a touché cet utilisateur ?" et commencez par AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\. Les champs qui vous intéressent sont à l'intérieur, à chaque fois, sur chaque version de Windows depuis 7. C'est le flux de travail que j'exécute.

Ce que l'artefact vous donne réellement

Par entrée, après parsing :

  • Chemin cible complet de l'élément ouvert, local, UNC ou amovible.
  • Horodatage du dernier accès (FILETIME, UTC) et un compteur d'accès par entrée. Le compteur est un float ; les entrées épinglées stockent une sentinelle à la place.
  • Nom NetBIOS de la machine enregistré au moment de l'accès. C'est le champ qui compte pour le mouvement latéral.
  • État épinglé. Épinglé signifie que l'utilisateur a activement cliqué sur "Épingler à cette liste".
  • AppID, qui mappe de manière déterministe à l'application qui lance (CRC64 tronqué sur le chemin de l'exécutable).
  • ID de volume et étiquette de volume du LNK incorporé. Utile pour la corrélation des médias amovibles.
  • Trois FILETIMEs de l'en-tête LNK, temps de création, accès, écriture de la cible vus lorsque le LNK a été écrit. Ils prennent un instantané du moment, puis ne se mettent jamais à jour.
  • Arguments de ligne de commande et répertoire de travail lorsqu'ils sont présents.

Un flux DFIR en 5 étapes

  1. Acquérir. Tirez %AppData%\Microsoft\Windows\Recent\AutomaticDestinations\ et le dossier frère CustomDestinations\ pour chaque profil utilisateur. Les fichiers en direct sont généralement verrouillés par explorer.exe, alors travaillez à partir d'une image forensique, d'un snapshot VSS, ou d'un outil qui gère correctement le verrou. KAPE a une cible pour cela ; sinon robocopy /b depuis une shadow copy montée fonctionne. Ne copiez pas en direct avec un simple xcopy.

  2. Triage par AppID. Listez les AppIDs (noms de fichiers moins l'extension) et mappez-les aux applications. La liste d'AppID livrée avec JLECmd est la référence de facto. Tout ce qui n'est pas mappé vaut un regard plus attentif, les apps personnalisées et portables génèrent leurs propres AppIDs, et il en va de même pour les outils d'attaquants qui s'enregistrent comme conscients de la shell. Une AppID inconnue avec une ligne DestList récente est une piste.

  3. Analyser. Extrayez chaque flux LNK numéroté et les lignes de DestList. JLECmd produit du CSV ou du JSON pour le travail par lots. JumpListExplorer (le frère GUI d'Eric Zimmerman) est le bon outil pour la revue interactive. Plaso / log2timeline émet des événements de timeline. Autopsy les fait remonter comme résultats d'ingestion. Pour une revue ponctuelle sans déplacer l'artefact de la station de travail de l'analyste, le parser dans le navigateur de ce site exécute la même logique côté client et ne téléverse jamais rien.

  4. Corréler. Alignez les horodatages d'accès DestList avec la timeline de session interactive de l'utilisateur. Les pivots qui fonctionnent vraiment :

    • Security.evtx 4624 / 4634 / 4647 pour les fenêtres de connexion et de déconnexion (voir le parser EVTX).
    • La clé UserAssist dans NTUSER.DAT pour les lancements GUI (voir le parser de registre).
    • Les hits Prefetch pour l'exécution de processus.
    • Le journal USN pour les événements de création/accès sur le fichier cible.
    • AmCache et ShimCache pour l'exécutable lui-même.
    • SRUM pour l'utilisation réseau et CPU de l'application lanceuse.
    • Un dump RAM via Volatility si vous en avez un, pour confirmer que l'application était résidente à ce moment.

  5. Rapporter. Citez chaque constatation par fichier source, numéro de flux et ID d'entrée DestList, par exemple, 1b4dd67f29cb1962.automaticDestinations-ms, flux 7, entrée DestList 0x12. La reproductibilité est ce qui fait tenir la constatation sous la revue. "La Jump List l'a montré" n'est pas une citation.

Le champ hostname, et pourquoi il gagne sa place

Chaque ligne de DestList porte le nom NetBIOS enregistré lorsque la cible a été ouverte. Sur une station de travail qui monte des partages depuis plusieurs serveurs, ce champ révèle quel serveur hébergeait chaque document ouvert, sans nécessiter les propres journaux du serveur. Dans les enquêtes de mouvement latéral, une Jump List sur un hôte compromis contient fréquemment le nom du serveur de staging de l'attaquant longtemps après que le partage a été démonté et le serveur ré-imagé.

J'ai clos des affaires sur ce seul champ. Un utilisateur ayant sauté par RDP ouvre un fichier depuis un hôte de staging, l'attaquant démantèle l'hôte de staging, le SOC n'a rien. L'automaticDestinations-ms de l'endpoint compromis pour Notepad a encore le nom NetBIOS et le GUID de volume six semaines plus tard.

Pièges courants

  • Mathématiques FILETIME. Intervalles de 100 nanosecondes depuis 1601-01-01 UTC. Convertir avec unix_seconds = (filetime / 10_000_000) - 11_644_473_600. Les erreurs d'un jour ici sont la source la plus courante de mauvaises timelines que je revois.
  • Décalage de version DestList. Win7 écrivait la version 1. Win10 et Win11 émettent couramment v3 ou v4. Les tailles de ligne et offsets de champs varient. Les anciens parsers qui codent en dur la disposition v1 se désaligneront silencieusement sur les hôtes modernes et vous passerez une heure à vous demander pourquoi les noms d'hôtes ressemblent à du charabia.
  • Les entrées épinglées gonflent les compteurs. Certaines applications (Office, Explorer) épinglent les éléments de manière agressive et augmentent les compteurs d'accès lors de l'indexation en arrière-plan. Un compteur élevé n'est pas en soi la preuve d'une interaction utilisateur répétée. Croisez avec Prefetch et UserAssist.
  • Bouton "Afficher les éléments récemment ouverts". Le désactiver sous Paramètres → Personnalisation → Accueil tronque les fichiers par AppID. Les fichiers sont recréés à la prochaine utilisation, donc des DestLists étonnamment courtes avec tous les horodatages regroupés autour de la même date récente sont un indicateur que l'utilisateur (ou quelque chose qui se fait passer pour l'utilisateur) a actionné le bouton.
  • Les entrées épinglées de customDestinations-ms survivent aux réinitialisations. Utile, un chemin UNC épinglé est une intention. Notez-les séparément des preuves MRU dans le rapport.
  • Les collisions d'AppID sont rares mais réelles. Deux installations du même exécutable au même chemin produisent la même AppID. Si vous travaillez dans un environnement Citrix multi-locataire ou VDI, attendez-vous à un chevauchement ; appuyez-vous sur le champ hostname et le TrackerDataBlock du LNK pour désambiguïser.

Un pivot final

Une fois que vous avez une liste d'entrées suspectes, prenez le GUID droid du TrackerDataBlock du LNK et pivotez à travers tous les autres LNK sur l'hôte (Bureau, Menu Démarrer, Recent\, les deux dossiers Destinations). Même droid signifie même machine source. Droid différent dans la même Jump List signifie que le fichier a été ouvert sur plus d'un hôte et Windows a préservé les deux versions. Ce second cas est inhabituel et presque toujours intéressant.

Déposez un fichier sur la page d'accueil pour voir tout cela sans envoyer de données ailleurs. Pour la référence au niveau octet, le post sur le format de fichier automaticDestinations est la prochaine lecture.

Pour aller plus loin

  • Eric Zimmerman, JLECmd et JumpListExplorer, les outils hors ligne canoniques.
  • Yogesh Khatri et Mike Stevens, "Jumping into the Past", rétro-ingénierie originale de DestList.
  • Kacos2000, Jumplist-Browser, visualiseur PowerShell pour l'inspection des flux bruts.
  • MITRE ATT&CK T1083 File and Directory Discovery et T1021 Remote Services, pour le contexte sur ce que la piste Jump List tend à corroborer.