¿De dónde viene LinkDate?

Del campo IMAGE_FILE_HEADER.TimeDateStamp del binario PE, establecido por el linker en tiempo de link. Amcache lee este campo en el momento del inventario y lo almacena como una cadena.

¿Pueden los atacantes controlar LinkDate?

Sí — completamente. El TimeDateStamp es lo que el linker escriba; los atacantes pueden establecerlo en cualquier valor, ponerlo a cero (builds reproducibles) o retrocederlo. LinkDate es una de las marcas de tiempo más controlables por el atacante en Windows DFIR.

¿Debo usar LinkDate como 'cuándo apareció el archivo en este host'?

No. LinkDate es del lado del build, no del host. Para la primera aparición del lado del host, usa KeyLastWriteTimestamp (la hora de escritura del appraiser) — e incluso esa es una cota superior, no exacta.

¿Es LinkDate alguna vez cero?

Sí. Los builds reproducibles (y algunos binarios go) deliberadamente ponen TimeDateStamp a cero. Un LinkDate cero no es sospechoso por sí mismo pero sí significa que LinkDate no aporta información para ese binario.

¿Qué es LinkDate en Amcache? (glosario)

Q: ¿Para qué es útil LinkDate?

Para agrupar binarios que comparten una campaña de build. Ordena los binarios sospechosos por LinkDate y busca clústeres apretados — los atacantes a menudo compilan su toolkit en una sentada, y marcas de tiempo de link a pocas horas entre sí son una señal fuerte de campaña.

LinkDate es el TimeDateStamp de la cabecera PE — el valor que el linker estampó en el binario en tiempo de build. Amcache lo lee de cada PE que inventaria y lo almacena como una cadena en la entrada.

No es una marca de tiempo del lado del host. Es lo más cercano que tiene Windows DFIR a una "marca de tiempo huella del binario", y es controlable por el atacante.

Cómo se diferencia de KeyLastWriteTimestamp#

	KeyLastWriteTimestamp	LinkDate
De dónde viene	Metadatos del registro, escritos por el appraiser	Cabecera PE, escrita por el linker
Controlable por el atacante	No (lado del host)	Sí (lado del build)
Responde	"¿Cuándo registró Amcache esto?"	"¿Cuándo se construyó este binario?"
Útil para	Aproximaciones de primer visto del lado del host	Agrupación de campañas de build
Resolución	Precisión de segundo	Precisión de segundo

Confundir estas dos es el error más común de Amcache. Ver Marcas de tiempo de Amcache explicadas para la referencia completa.

Para qué es útil LinkDate#

Agrupación de campañas de build#

Ordena los binarios sospechosos por LinkDate:

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

Clústeres apretados — 3 a 10 binarios con valores de LinkDate dentro del mismo día u hora — son característicos de una sola campaña de atacante. Los atacantes frecuentemente compilan su toolkit completo en una sentada, y las marcas de tiempo de build se agrupan.

Señales rojas de edad de driver#

Para investigaciones BYOVD (Bring-Your-Own-Vulnerable-Driver), ordena *_DriverBinaries.csv por DriverTimeStamp (el equivalente de LinkDate del lado del driver). Drivers antiguos pero firmados (compilados en 2014, pero apareciendo en Amcache hoy) son un indicador fuerte de BYOVD.

Verificación de build interno#

"Nuestros builds de herramientas internas siempre llevan linkdate los lunes a las 03:00 UTC. Este es martes a las 14:00 — investigar." Útil para detectar deriva en el proceso interno de build.

Para qué LinkDate NO es útil#

Hora de primer visto en host. Usa KeyLastWriteTimestamp.
Orden de llegada. Dos binarios con el mismo LinkDate no necesariamente llegaron al host al mismo tiempo.
Identidad criptográfica. Muchos binarios comparten valores de LinkDate.

Términos relacionados#

KeyLastWriteTimestamp — la marca de tiempo con la que más a menudo se confunde.
FileId — la identidad criptográfica.
InventoryApplicationFile — donde se almacena LinkDate.