D'où vient LinkDate ?

Du champ IMAGE_FILE_HEADER.TimeDateStamp du binaire PE, défini par le linker au moment du link. Amcache lit ce champ au moment de l'inventaire et le stocke comme chaîne.

Les attaquants peuvent-ils contrôler LinkDate ?

Oui — complètement. Le TimeDateStamp est ce que le linker écrit ; les attaquants peuvent le définir à n'importe quelle valeur, le mettre à zéro (builds reproductibles), ou le rétrodater. LinkDate est l'un des horodatages les plus contrôlables par l'attaquant en DFIR Windows.

Dois-je utiliser LinkDate comme « quand le fichier est apparu sur cet hôte » ?

Non. LinkDate est côté build, pas côté hôte. Pour la première apparition côté hôte, utilisez KeyLastWriteTimestamp (l'heure d'écriture de l'appraiser) — et même cela est une borne supérieure, pas exacte.

LinkDate est-il parfois nul ?

Oui. Les builds reproductibles (et certains binaires go) mettent délibérément le TimeDateStamp à zéro. Un LinkDate à zéro n'est pas suspect en soi, mais cela signifie que LinkDate ne porte aucune information pour ce binaire.

Qu'est-ce que LinkDate dans Amcache ? (glossaire)

Q: À quoi sert LinkDate ?

À regrouper des binaires qui partagent une campagne de build. Triez les binaires suspects par LinkDate et recherchez des clusters serrés — les attaquants compilent souvent leur kit d'outils en une seule séance, et des horodatages de link à quelques heures d'écart sont un signal fort de campagne.

LinkDate est le TimeDateStamp de l'en-tête PE — la valeur que le linker a estampillée dans le binaire au moment du build. Amcache la lit à partir de chaque PE qu'il inventorie et la stocke comme chaîne dans l'entrée.

Ce n'est pas un horodatage côté hôte. C'est ce qui se rapproche le plus, en DFIR Windows, d'un « horodatage d'empreinte de binaire », et c'est contrôlable par l'attaquant.

En quoi il diffère de KeyLastWriteTimestamp#

	KeyLastWriteTimestamp	LinkDate
D'où il vient	Métadonnées de registre, écrites par l'appraiser	En-tête PE, écrit par le linker
Contrôlable par l'attaquant	Non (côté hôte)	Oui (côté build)
Répond	« Quand Amcache a-t-il enregistré ceci ? »	« Quand ce binaire a-t-il été buildé ? »
Utile pour	Approximations de première vue côté hôte	Regroupement de campagnes de build
Résolution	Précision à la seconde	Précision à la seconde

Confondre ces deux-là est l'erreur Amcache la plus courante. Voir Horodatages Amcache expliqués pour la référence complète.

À quoi sert LinkDate#

Regroupement de campagnes de build#

Triez les binaires suspects par LinkDate :

Import-Csv .\HOST_amcache_UnassociatedFileEntries.csv |
  Where-Object { $_.IsPeFile -eq 'True' -and -not $_.Publisher } |
  Sort-Object LinkDate |
  Select-Object LinkDate, Hash, FullPath

Des clusters serrés — 3 à 10 binaires avec des valeurs LinkDate dans le même jour ou la même heure — sont caractéristiques d'une seule campagne d'attaquant. Les attaquants compilent fréquemment leur kit d'outils complet en une seule séance, et les horodatages de build se regroupent.

Drapeaux rouges d'âge de pilote#

Pour les investigations BYOVD (Bring-Your-Own-Vulnerable-Driver), triez *_DriverBinaries.csv par DriverTimeStamp (l'équivalent LinkDate côté pilote). Les pilotes anciens mais signés (compilés en 2014, mais apparaissant dans Amcache aujourd'hui) sont un fort indicateur BYOVD.

Vérification de build interne#

« Nos builds d'outils internes ont toujours un linkdate les lundis à 03:00 UTC. Celui-ci est mardi à 14:00 — à investiguer. » Utile pour détecter une dérive du processus de build interne.

À quoi LinkDate NE sert PAS#

Heure de premier vu sur l'hôte. Utilisez KeyLastWriteTimestamp.
Ordre d'arrivée. Deux binaires avec le même LinkDate ne sont pas nécessairement arrivés sur l'hôte en même temps.
Identité cryptographique. Beaucoup de binaires partagent des valeurs LinkDate.

Termes apparentés#

KeyLastWriteTimestamp — l'horodatage avec lequel il est le plus souvent confondu.
FileId — l'identité cryptographique.
InventoryApplicationFile — où LinkDate est stocké.