Les Jump Lists côté attaquant : reconnaissance, usurpation, nettoyage

La majorité des écrits sur les Jump Lists sont défensifs, ce qui laisse un vide : si vous ne lisez jamais l'artefact qu'en enquêteur, vous ratez ce que fait quelqu'un de l'autre côté. Voici la vue offensive, écrite pour les défenseurs et les testeurs autorisés. Connaître les gestes, c'est ainsi qu'on les reconnaît, et deux d'entre eux sont plus discrets que la littérature ne le laisse entendre.

Tout ici est détectable. Je dirai où, parce que le but n'est pas "regardez comme c'est rusé", c'est "voici le résidu".

Les lire est la reconnaissance la moins chère qui soit

Avant que quiconque supprime quoi que ce soit, la première valeur pour l'attaquant, c'est juste la lecture. Le dossier AutomaticDestinations d'un utilisateur est une carte annotée de ce sur quoi il travaille. Les documents récemment ouverts par nom et chemin. Le champ nom d'hôte du DestList livre les noms des serveurs de fichiers et des partages montés depuis eux. Les étiquettes et GUID de volume signalent les supports amovibles qui ont été branchés. Les Jump Lists d'Office et de l'Explorateur en particulier tendent à pointer droit vers les partages sensibles qu'un opérateur veut trouver.

Rien de tout cela ne nécessite d'élévation. Les fichiers vivent dans le profil de l'utilisateur lui-même et sont lisibles en tant que cet utilisateur. Donc un attaquant qui a atterri en tant qu'utilisateur normal, sans encore d'élévation de privilèges, peut lire les Jump Lists et apprendre où vivent les données intéressantes et vers quels serveurs pivoter. C'est de la découverte en mode living-off-the-land sans outillage, sans LOLBins, rien qui allume l'arbre de processus d'un EDR.

Cela correspond à ATT&CK T1083 File and Directory Discovery, et du côté défensif c'est gênant, parce que lire un fichier dans son propre profil n'est pas un événement sur lequel la plupart des stacks alertent. La détection réaliste est en aval : l'accès aux partages cibles que l'attaquant a appris, pas la lecture de la Jump List elle-même.

Usurpation et plantation

Le format est documenté, le fichier n'est ni signé ni authentifié, et l'AppID n'est qu'un hachage CRC-64 utilisé comme nom de fichier (l'article sur l'AppID explique pourquoi cela compte). Donc le contenu peut être falsifié.

Deux saveurs. L'attaquant édite une vraie Jump List pour insérer des entrées qui pointent quelque part de trompeur : un chemin planté impliquant un autre utilisateur ou un autre hôte, un nom d'hôte fabriqué dans une ligne DestList pour égarer une enquête sur le mouvement latéral. Ou il dépose tout un fichier nommé d'après une application bénigne, pré-rempli, pour fabriquer un historique qui n'a jamais eu lieu. Parce que le shell ne valide l'AppID contre rien, un fichier nommé d'après Notepad n'a pas à venir de Notepad.

C'est réel, et c'est aussi là que les attaquants se font prendre, parce qu'éditer la structure binaire à la main est facile à rater subtilement. Chaque entrée DestList porte une valeur d'intégrité que la plupart des scripts improvisés ne recalculent pas. L'en-tête conserve un compteur d'ID d'entrée monotone qui doit rester cohérent avec les lignes. Éditez les horodatages sans comprendre l'ordre MRU et l'ordre des horodatages contredit l'ordre des ID d'entrée. Chacun de ces points est un indice, et c'est exactement ce que l'article sur la chronologie et l'anti-forensique vous apprend à chercher. Le contenu planté peut tout de même berner un analyste qui prend le fichier au pied de la lettre sous la pression du temps, ce qui est tout le pari de l'attaquant.

La persistance : surtout surestimée

Vous verrez de temps en temps les Jump Lists listées aux côtés des mécanismes de persistance. Soyez sceptique. Une Jump List n'est pas un emplacement de démarrage automatique. Windows n'exécute rien dans AutomaticDestinations au boot ou à l'ouverture de session. Il n'y a pas de comportement de clé Run ici.

Le grain de vérité est dans CustomDestinations. Ce sont les entrées épinglées et de tâches qu'une application définit, et une entrée épinglée est un raccourci qui pointe vers une cible que l'utilisateur pourrait cliquer. Un attaquant capable d'écrire dans le CustomDestinations d'un utilisateur pourrait épingler une entrée dont la cible est une charge utile malveillante ou un chemin UNC, posée dans la Jump List en attente d'un clic. C'est un vecteur d'ingénierie sociale, pas de la persistance au sens propre. Cela ne survit pas comme exécution de code, cela dépend entièrement du clic de l'utilisateur, et il existe une douzaine de façons plus fiables de mettre un raccourci malveillant devant un utilisateur. Si vous bâtissez un programme de détection, ne dépensez pas de budget de chasse à la persistance ici. Dépensez-le sur les emplacements de démarrage automatique qui exécutent réellement.

Le nettoyage, et pourquoi il fonctionne rarement proprement

Le dernier geste de l'attaquant est le retrait, et le guide pour vider ou supprimer couvre la mécanique côté utilisateur. Opérationnellement, l'attaquant a les mêmes options grossières que n'importe qui : basculer le réglage des éléments récents, supprimer les fichiers par AppID, ou lancer un nettoyeur. ATT&CK classe cela sous T1070 Indicator Removal.

Cela fonctionne rarement proprement, et un testeur devrait savoir pourquoi afin de conseiller à la blue team où chercher. Supprimer le fichier n'efface pas tant l'historique qu'il ne déplace la preuve : la date de création MFT récente du fichier recréé trahit quand l'ancien est mort, l'écriture passe par le journal USN avec un horodatage, et le Volume Shadow Copy a très probablement pris un instantané de l'original hors de portée. La chirurgie sélective sur une seule entrée laisse des incohérences structurelles : une ligne DestList pointant vers un flux qui n'existe plus, ou un flux orphelin sans ligne. Le nettoyage qui paraît complet sur le volume actif est en général celui qui a laissé le plus de traces corroborantes quelque part où l'attaquant n'a pas pensé à nettoyer.

Le point à retenir pour le défenseur

Lisez les gestes offensifs à l'envers et ils deviennent une liste de détection. Surveillez l'accès aux partages et fichiers que les Jump Lists d'un hôte nomment, parce que c'est la reconnaissance qui paie. Traitez une Jump List sur un hôte que vous soupçonnez déjà comme une affirmation à vérifier contre des artefacts indépendants, pas comme une vérité de terrain, car elle a pu être plantée. Ne gaspillez pas d'effort de chasse à la persistance sur AutomaticDestinations. Et quand une Jump List paraît suspectement propre, allez d'abord aux clichés instantanés et au journal USN, car c'est là que la chose que l'attaquant a tenté de retirer est encore posée.