Where does LinkDate come from?

From the PE binary's IMAGE_FILE_HEADER.TimeDateStamp field, set by the linker at link time. Amcache reads this field at inventory time and stores it as a string.

Can attackers control LinkDate?

Yes — completely. The TimeDateStamp is whatever the linker writes; attackers can set it to any value, zero it (reproducible builds), or backdate it. LinkDate is one of the most attacker-controllable timestamps in Windows DFIR.

Should I use LinkDate as 'when the file appeared on this host'?

No. LinkDate is build-side, not host-side. For host-side first-appearance, use KeyLastWriteTimestamp (the appraiser write time) — and even that is an upper bound, not exact.

What is LinkDate useful for?

Clustering binaries that share a build campaign. Sort suspicious binaries by LinkDate and look for tight clusters — attackers often compile their toolkit in one sitting, and link timestamps within hours of each other are a strong campaign signal.

Is LinkDate ever zero?

Yes. Reproducible builds (and some go binaries) deliberately zero the TimeDateStamp. A zero LinkDate is not suspicious by itself but does mean LinkDate carries no information for that binary.

What is LinkDate in Amcache? (glossary)

LinkDate is the PE header's TimeDateStamp — the value the linker stamped into the binary at build time. Amcache reads it from every PE it inventories and stores it as a string in the entry.

It is not a host-side timestamp. It is the closest thing Windows DFIR has to a "binary fingerprint timestamp", and it is attacker-controllable.

How it differs from KeyLastWriteTimestamp#

	KeyLastWriteTimestamp	LinkDate
Where it comes from	Registry metadata, written by appraiser	PE header, written by linker
Attacker-controllable	No (host-side)	Yes (build-side)
Answers	"When did Amcache record this?"	"When was this binary built?"
Useful for	Host-side first-seen approximations	Build-campaign clustering
Resolution	Second-precision	Second-precision

Confusing these two is the single most common Amcache mistake. See Amcache timestamps explained for the full reference.

What LinkDate is useful for#

Build-campaign clustering#

Sort suspicious binaries by LinkDate:

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

Tight clusters — 3 to 10 binaries with LinkDate values within the same day or hour — are characteristic of a single attacker campaign. Attackers frequently compile their full toolkit in one sitting, and the build timestamps cluster.

Driver-age red flags#

For BYOVD (Bring-Your-Own-Vulnerable-Driver) investigations, sort *_DriverBinaries.csv by DriverTimeStamp (the driver-side LinkDate equivalent). Old-but-signed drivers (compiled 2014, but appearing in Amcache today) are a strong BYOVD indicator.

Internal-build verification#

"Our internal tool builds always linkdate on Mondays at 03:00 UTC. This one is Tuesday at 14:00 — investigate." Useful for catching internal build-process drift.

What LinkDate is NOT useful for#

First-seen-on-host time. Use KeyLastWriteTimestamp.
Order of arrival. Two binaries with the same LinkDate did not necessarily arrive on the host at the same time.
Cryptographic identity. Many binaries share LinkDate values.

KeyLastWriteTimestamp — the timestamp it is most often confused with.
FileId — the cryptographic identity.
InventoryApplicationFile — where LinkDate is stored.