Pourquoi les fichiers .lnk sont-ils une source forensique aussi riche ?

Parce qu'ils enregistrent non seulement où se trouvait une cible, mais aussi où le lien lui-même a été créé. Un seul .lnk préserve le nom NetBIOS de la machine d'origine, un GUID droid dérivé de la MAC, le numéro de série de volume du disque sur lequel il résidait, le chemin local complet de la cible et trois horodatages FILETIME capturés à la création du lien. Tout cela survit longtemps après la suppression du fichier cible.

Où Windows crée-t-il automatiquement des fichiers .lnk ?

À plusieurs endroits : jumplists AutoDest dans %APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations, custom destinations dans le dossier frère CustomDestinations, le dossier Recent lui-même (un .lnk par élément récemment ouvert), raccourcis du menu Démarrer et du Bureau, et listes MRU d'Office. Chacun d'eux est de bonne prise dans une enquête.

Qu'est-ce qu'un GUID droid et pourquoi est-il important ?

Le GUID droid vit dans le TrackerDataBlock et est généré à partir de l'adresse MAC de la machine qui crée le lien en utilisant un schéma UUID version 1. Deux GUIDs droid créés sur la même machine en quelques secondes partagent la plupart des bits, y compris la MAC. Les enquêteurs corrèlent les droids entre les fichiers .lnk pour regrouper l'activité sur une seule machine source, même si le compte utilisateur ou le chemin diffère.

Les horodatages des .lnk se mettent-ils à jour au fil du temps ?

Non. Les trois FILETIMEs dans le ShellLinkHeader sont un instantané des temps de création, d'accès et d'écriture de la cible au moment de la création du lien. Ils ne suivent pas la cible par la suite. Un raccourci dont les horodatages diffèrent de la cible actuelle vous dit quand le lien lui-même a été écrit pour la première fois, souvent plus utile que les métadonnées de la cible en direct.

Pourquoi les fichiers .lnk sont-ils une source forensique aussi riche ?

Parce qu'ils enregistrent non seulement où se trouvait une cible, mais aussi où le lien lui-même a été créé. Un seul .lnk préserve le nom NetBIOS de la machine d'origine, un GUID droid dérivé de la MAC, le numéro de série de volume du disque sur lequel il résidait, le chemin local complet de la cible et trois horodatages FILETIME capturés à la création du lien. Tout cela survit longtemps après la suppression du fichier cible.

Où Windows crée-t-il automatiquement des fichiers .lnk ?

À plusieurs endroits : jumplists AutoDest dans %APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations, custom destinations dans le dossier frère CustomDestinations, le dossier Recent lui-même (un .lnk par élément récemment ouvert), raccourcis du menu Démarrer et du Bureau, et listes MRU d'Office. Chacun d'eux est de bonne prise dans une enquête.

Qu'est-ce qu'un GUID droid et pourquoi est-il important ?

Le GUID droid vit dans le TrackerDataBlock et est généré à partir de l'adresse MAC de la machine qui crée le lien en utilisant un schéma UUID version 1. Deux GUIDs droid créés sur la même machine en quelques secondes partagent la plupart des bits, y compris la MAC. Les enquêteurs corrèlent les droids entre les fichiers .lnk pour regrouper l'activité sur une seule machine source, même si le compte utilisateur ou le chemin diffère.

Les horodatages des .lnk se mettent-ils à jour au fil du temps ?

Non. Les trois FILETIMEs dans le ShellLinkHeader sont un instantané des temps de création, d'accès et d'écriture de la cible au moment de la création du lien. Ils ne suivent pas la cible par la suite. Un raccourci dont les horodatages diffèrent de la cible actuelle vous dit quand le lien lui-même a été écrit pour la première fois, souvent plus utile que les métadonnées de la cible en direct.

Analyse forensique des fichiers .lnk : ce que recherchent les enquêteurs

Un .lnk est petit, il survit indépendamment de la cible vers laquelle il pointe, et il capture un instantané précis de la machine source au moment de la création du raccourci. Après suffisamment de cas, vous cessez de penser aux raccourcis comme à du fouillis de commodité utilisateur et commencez à les traiter comme l'une des pièces les moins chères de preuves d'attribution que produit Windows. Ce post est la carte du praticien sur ce qu'il faut réellement extraire, mappée aux sections binaires définies par MS-SHLLINK.

Les artefacts en tête d'affiche

Déposez un vrai .lnk dans le parser et voici les champs qu'un analyste DFIR vérifie en premier.

Artefact	Vit dans	Pourquoi c'est important
LocalBasePath	LinkInfo	Chemin complet sur la machine d'origine ; le nom d'utilisateur est généralement en ligne.
VolumeID (serial, label, type)	LinkInfo → VolumeID	Identifie le disque. Même serial sur plusieurs liens signifie le même lecteur.
CreationTime / AccessTime / WriteTime	ShellLinkHeader	FILETIMEs de la cible capturés à la création du lien. Survit à la suppression de la cible.
Nom NetBIOS de la machine	ExtraData → TrackerDataBlock	Hostname de la machine qui a écrit le lien.
GUIDs Droid et DroidBirth	TrackerDataBlock	UUIDs version 1 dont les six derniers octets sont la MAC de la machine source.
Arguments de ligne de commande	StringData (COMMAND_LINE_ARGUMENTS)	Avec quoi la cible était censée s'exécuter. Indicateur de phishing.
Répertoire de travail	StringData (WORKING_DIR)	Révèle souvent des lettres USB ou des dossiers de staging.
Chemin de partage réseau	LinkInfo → CommonNetworkRelativeLink	Chemin UNC. Préserve les partages disparus.
ShowCommand / IconLocation	ShellLinkHeader / StringData	Fenêtre cachée plus icône usurpée équivaut à un fort signal de malware.
LinkTargetIDList	Après l'en-tête	Parcours du namespace shell ; résout parfois quand LinkInfo ne le fait pas.

La liste complète sort de champs standard documentés dans [MS-SHLLINK]. Les mêmes parsers qui les lisent fonctionnent sur les fichiers .lnk extraits des fichiers composés Jumplist, ce sont des flux LNK dans un wrapper MS-CFB.

Le TrackerDataBlock en profondeur

Le TrackerDataBlock est l'artefact LNK le plus cité dans le travail DFIR, et il mérite la citation. Sa charge utile est deux GUIDs de 16 octets (Droid et DroidBirth) plus un nom NetBIOS. Chaque GUID est un identifiant Microsoft Distributed Link Tracking, un UUID v1 généré à partir de :

un horodatage haute résolution (quand le lien a été écrit pour la première fois), et
l'adresse MAC de la machine qui crée le lien, les six derniers octets du GUID.

Cela signifie qu'un seul .lnk peut divulguer la MAC de la machine qui l'a créé. Les enquêteurs corrèlent les GUIDs droid à travers des milliers de raccourcis pour :

Regrouper l'activité sur un hôte d'origine même quand les noms de fichiers et chemins diffèrent.
Identifier la source du lien quand seul le .lnk survit.
Attraper les erreurs d'attribution, plusieurs attributions publiques d'acteurs de menaces sont issues de fichiers .lnk qui ont divulgué la VM de build de l'attaquant. Les rapports Lazarus / APT37 / APT41 sont des exemples publics.

La randomisation MAC, les NICs virtuels et les builds Windows modernes peuvent casser cela dans certains cas. L'artefact apparaît encore dans la majorité des échantillons du monde réel que j'ai parsés.

Où Windows écrit des raccourcis pour vous

Les raccourcis créés par l'utilisateur sur Bureau et Menu Démarrer sont évidents. Les intéressants sont les raccourcis que Windows écrit automatiquement :

%APPDATA%\Microsoft\Windows\Recent\, un .lnk par élément récemment ouvert. Historique d'utilisation quasi complet. Jumelez avec le parser de registre pour les clés RecentDocs correspondantes dans NTUSER.DAT.
%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\, fichiers Jumplist AutoDest. Fichiers composés MS-CFB contenant des flux LNK numérotés plus un flux DestList avec horodatages d'accès, compteurs, et le hostname NetBIOS d'origine.
%APPDATA%\Microsoft\Windows\Recent\CustomDestinations\, Jumplists curés par les applications. Flux d'octets plat, LNKs concaténés, terminés par 0xBABFFBAB.
%APPDATA%\Microsoft\Office\Recent\, le MRU parallèle d'Office.
Les médias amovibles eux-mêmes, Windows écrit souvent des raccourcis .lnk sur les clés USB lorsqu'elles sont branchées. Ceux-ci sont récupérables depuis la clé longtemps après que l'hôte qui les a créés a disparu.

Chacune de ces sources est une source de timeline récupérable même quand la cible est supprimée.

Flux de travail

Une passe d'enquête typique sur des fichiers .lnk collectés :

Parser et normaliser. Convertissez chaque raccourci en un enregistrement structuré avec les champs ci-dessus. LECmd --csv, lnkinfo de libyal, ou lnkparse3 pour l'intégration Python. Décidez du schéma de sortie d'un outil et tenez-vous-y sur tout le cas.
Pivot sur le GUID droid. Regroupez par MAC source. Confirmez ou éliminez l'activité par machine. Un seul droid apparaissant sur des raccourcis de plusieurs profils utilisateurs est un fort signal d'attribution.
Pivot sur le serial de volume. Identifiez la lignée du disque. Même serial sur plusieurs liens signifie le même lecteur dans le temps. Serials différents avec la même lettre de lecteur signifie des médias amovibles.
Construisez une timeline. Les FILETIMEs d'en-tête sont l'instantané du lien des métadonnées de la cible. Combinez avec la propre entrée MFT du lien pour le temps d'écriture du lien et le journal USN pour les événements de création/suppression sur le lien lui-même.
Recoupez. Prefetch, ShimCache, AmCache, lignes DestList de Jumplist, MRUs Office, historique du navigateur. Les revendications les plus fortes ont au moins deux sources.

Ce que le parser expose

Le parser sur ce site décode chaque champ ci-dessus. L'inspection s'exécute localement en WebAssembly, utile quand vous avez besoin d'un triage rapide sur un fichier que quelqu'un vient de vous envoyer par email et que vous ne voulez pas que le nom NetBIOS, le GUID dérivé MAC et le chemin cible quittent la machine. La sortie groupe les données par section, en-tête, LinkTargetIDList, LinkInfo, StringData, chaque bloc ExtraData, donc la lecture correspond à l'ordre de la spec.

Pour aller plus loin

La spécification [MS-SHLLINK] de Microsoft, la référence au niveau octet.
Eric Zimmerman, LECmd, l'outil hors ligne et schéma de sortie de facto.
libyal, liblnk, parser Linux/macOS.
Le parser Jumplist pour les flux LNK à l'intérieur des fichiers .automaticDestinations-ms et .customDestinations-ms.
Pour corroboration : parser MFT, parser USN, parser Prefetch, parser de registre, parser AmCache.