Análisis forense de archivos .lnk: lo que buscan los investigadores

Un .lnk es pequeño, sobrevive independientemente del destino al que apunta y captura una instantánea precisa de la máquina fuente en el momento en que se creó el acceso directo. Tras suficientes casos, dejas de pensar en los accesos directos como desorden de conveniencia del usuario y empiezas a tratarlos como una de las piezas más baratas de evidencia de atribución que produce Windows. Este post es el mapa del profesional sobre qué extraer realmente, mapeado a las secciones binarias definidas por MS-SHLLINK.

Los artefactos titulares

Suelta un .lnk real en el parser y estos son los campos que un analista DFIR comprueba primero.

La lista completa sale de campos estándar documentados en [MS-SHLLINK]. Los mismos parsers que los leen funcionan en archivos .lnk extraídos de archivos compuestos de Jumplist, esos son flujos LNK en un envoltorio MS-CFB.

El TrackerDataBlock en profundidad

El TrackerDataBlock es el artefacto LNK más citado en el trabajo DFIR, y se gana la cita. Su carga útil son dos GUIDs de 16 bytes (Droid y DroidBirth) más un nombre NetBIOS. Cada GUID es un identificador Microsoft Distributed Link Tracking, un UUID v1 generado a partir de:

• una marca temporal de alta resolución (cuándo se escribió por primera vez el enlace), y
• la dirección MAC de la máquina que crea el enlace, los últimos seis bytes del GUID.

Eso significa que un solo .lnk puede filtrar el MAC de la máquina que lo creó. Los investigadores correlacionan GUIDs droid entre miles de accesos directos para:

• Agrupar actividad en un host de origen incluso cuando los nombres de archivo y rutas difieren.
• Identificar la fuente del enlace cuando solo sobrevive el .lnk.
• Pillar errores de atribución, varias atribuciones públicas de actores de amenazas se originaron en archivos .lnk que filtraron la VM de build del atacante. Los informes de Lazarus / APT37 / APT41 son ejemplos públicos.

La aleatorización de MAC, las NICs virtuales y las builds modernas de Windows pueden romper esto en algunos casos. El artefacto sigue apareciendo en la mayoría de muestras del mundo real que he parseado.

Dónde escribe Windows accesos directos por ti

Los accesos directos creados por el usuario en Escritorio y Menú Inicio son obvios. Los interesantes son los accesos directos que Windows escribe automáticamente:

• %APPDATA%\Microsoft\Windows\Recent\, un .lnk por elemento abierto recientemente. Historial de uso casi completo. Empareja con el parser de registro para las claves RecentDocs correspondientes en NTUSER.DAT.
• %APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\, archivos Jumplist AutoDest. Archivos compuestos MS-CFB que contienen flujos LNK numerados más un flujo DestList con marcas temporales de acceso, recuentos y el hostname NetBIOS de origen.
• %APPDATA%\Microsoft\Windows\Recent\CustomDestinations\, Jumplists curados por aplicación. Flujo de bytes plano, LNKs concatenados, terminados por 0xBABFFBAB.
• %APPDATA%\Microsoft\Office\Recent\, el MRU paralelo de Office.
• Los propios medios extraíbles, Windows a menudo escribe accesos directos .lnk de vuelta en las unidades USB cuando se conectan. Esos son recuperables de la unidad mucho después de que el host que los creó haya desaparecido.

Cada uno de estos es una fuente de timeline recuperable incluso cuando el destino está eliminado.

Flujo de trabajo

Una pasada de investigación típica sobre archivos .lnk recopilados:

1. Parsea y normaliza. Convierte cada acceso directo en un registro estructurado con los campos anteriores. LECmd --csv, lnkinfo de libyal o lnkparse3 para integración con Python. Decide el esquema de salida de una herramienta y mantente con él durante todo el caso.
2. Pivote en el GUID droid. Agrupa por MAC fuente. Confirma o descarta actividad por máquina. Un solo droid apareciendo en accesos directos de múltiples perfiles de usuario es una señal de atribución fuerte.
3. Pivote en el serial de volumen. Identifica el linaje del disco. El mismo serial en múltiples enlaces significa la misma unidad a lo largo del tiempo. Seriales diferentes con la misma letra de unidad significan medios extraíbles.
4. Construye una línea de tiempo. Los FILETIMEs de cabecera son la instantánea del enlace de los metadatos del destino. Combina con el propio registro MFT del enlace para el tiempo de escritura del enlace y el diario USN para eventos de creación/eliminación en el propio enlace.
5. Referencia cruzada. Prefetch, ShimCache, AmCache, filas DestList de Jumplist, MRUs de Office, historial del navegador. Las afirmaciones más fuertes tienen al menos dos fuentes.

Lo que expone el parser

El parser de este sitio decodifica cada campo anterior. La inspección se ejecuta localmente en WebAssembly, útil cuando necesitas triaje rápido en un archivo que alguien acaba de enviarte por email y no quieres que el nombre NetBIOS, el GUID derivado del MAC y la ruta de destino salgan de la máquina. La salida agrupa los datos por sección, cabecera, LinkTargetIDList, LinkInfo, StringData, cada bloque ExtraData, por lo que la lectura coincide con el orden de la especificación.

Lecturas adicionales

• La especificación [MS-SHLLINK] de Microsoft, la referencia a nivel de byte.
• Eric Zimmerman, LECmd, la herramienta offline y esquema de salida de facto.
• libyal, liblnk, parser Linux/macOS.
• El parser Jumplist para flujos LNK dentro de archivos .automaticDestinations-ms y .customDestinations-ms.
• Para corroboración: parser MFT, parser USN, parser Prefetch, parser de registro, parser AmCache.