Las Jump Lists desde el lado del atacante: reconocimiento, suplantación, limpieza

La mayoría de lo escrito sobre Jump Lists es defensivo, lo que deja un hueco: si solo lees el artefacto como investigador, te pierdes lo que hace alguien del otro lado. Esta es la vista ofensiva, escrita para defensores y testers autorizados. Conocer los movimientos es como se reconocen, y un par de ellos son más silenciosos de lo que sugiere la literatura.

Todo lo de aquí es detectable. Diré dónde, porque el objetivo no es "mira qué astuto", es "aquí está el residuo".

Leerlas es el reconocimiento más barato que hay

Antes de que nadie borre nada, el primer valor para el atacante es simplemente leer. La carpeta AutomaticDestinations de un usuario es un mapa anotado de aquello en lo que trabaja. Documentos abiertos recientemente por nombre y ruta. El campo nombre de host de la DestList entrega los nombres de los servidores de archivos y los recursos compartidos montados desde ellos. Las etiquetas y GUID de volumen señalan los medios extraíbles que se han conectado. Las Jump Lists de Office y del Explorador en particular tienden a apuntar directo a los recursos compartidos sensibles que un operador quiere encontrar.

Nada de esto requiere elevación. Los archivos viven en el perfil del propio usuario y son legibles como ese usuario. Así que un atacante que ha aterrizado como usuario normal, sin escalada de privilegios todavía, puede leer las Jump Lists y aprender dónde viven los datos interesantes y hacia qué servidores pivotar. Es descubrimiento en modo living-off-the-land sin herramientas, sin LOLBins, nada que encienda el árbol de procesos de un EDR.

Esto se corresponde con ATT&CK T1083 File and Directory Discovery, y desde el lado defensivo es incómodo, porque leer un archivo en el propio perfil no es un evento sobre el que la mayoría de los stacks alerten. La detección realista está aguas abajo: el acceso a los recursos compartidos objetivo que el atacante aprendió, no la lectura de la Jump List en sí.

Suplantación y plantado

El formato está documentado, el archivo no está firmado ni autenticado, y el AppID es solo un hash CRC-64 usado como nombre de archivo (el artículo sobre el AppID explica por qué importa). Así que el contenido puede falsificarse.

Dos sabores. El atacante edita una Jump List real para insertar entradas que apunten a algún sitio engañoso: una ruta plantada que implique a otro usuario u otro host, un nombre de host fabricado en una fila de DestList para desviar una investigación de movimiento lateral. O deja caer un archivo entero con el nombre de una aplicación benigna, prerrellenado, para fabricar un historial que nunca ocurrió. Como la shell no valida el AppID contra nada, un archivo con el nombre de Notepad no tiene por qué proceder de Notepad.

Esto es real, y es también donde a los atacantes los pillan, porque editar la estructura binaria a mano es fácil de hacer sutilmente mal. Cada entrada DestList lleva un valor de integridad que la mayoría de los scripts caseros no recalculan. La cabecera mantiene un contador de ID de entrada monótono que debe permanecer consistente con las filas. Edita las marcas temporales sin entender el orden MRU y el orden de las marcas temporales contradice el orden de los ID de entrada. Cada uno de esos puntos es una pista, y es exactamente lo que el artículo sobre línea de tiempo y anti-forense te enseña a buscar. El contenido plantado aún puede burlar a un analista que tome el archivo al pie de la letra bajo la presión del tiempo, que es toda la apuesta del atacante.

Persistencia: sobre todo sobrevalorada

De vez en cuando verás las Jump Lists listadas junto a los mecanismos de persistencia. Sé escéptico. Una Jump List no es una ubicación de arranque automático. Windows no ejecuta nada en AutomaticDestinations al arrancar o al iniciar sesión. Aquí no hay comportamiento de clave Run.

El grano de verdad está en CustomDestinations. Esas son las entradas ancladas y de tareas que una aplicación define, y una entrada anclada es un acceso directo que apunta a un objetivo que el usuario podría pulsar. Un atacante capaz de escribir en el CustomDestinations de un usuario podría anclar una entrada cuyo objetivo sea una carga útil maliciosa o una ruta UNC, posada en la Jump List a la espera de un clic. Eso es un vector de ingeniería social, no persistencia en ningún sentido propio. No sobrevive como ejecución de código, depende por completo del clic del usuario, y hay una docena de formas más fiables de poner un acceso directo malicioso delante de un usuario. Si construyes un programa de detección, no gastes presupuesto de caza de persistencia aquí. Gástalo en las ubicaciones de arranque automático que sí ejecutan.

La limpieza, y por qué rara vez funciona limpia

El último movimiento del atacante es el borrado, y la guía para vaciar o eliminar cubre la mecánica desde el lado del usuario. Operativamente, el atacante tiene las mismas opciones burdas que cualquiera: alternar el ajuste de elementos recientes, eliminar los archivos por AppID, o ejecutar un limpiador. ATT&CK lo archiva bajo T1070 Indicator Removal.

Rara vez funciona limpia, y un tester debería saber por qué para aconsejar al equipo azul dónde mirar. Eliminar el archivo no borra tanto el historial como reubica la prueba: la reciente hora de creación MFT del archivo recreado delata cuándo murió el antiguo, la escritura pasa por el diario USN con una marca temporal, y Volume Shadow Copy muy probablemente ha tomado un snapshot del original fuera de alcance. La cirugía selectiva sobre una sola entrada deja inconsistencias estructurales: una fila DestList que apunta a un flujo que ya no existe, o un flujo huérfano sin fila. La limpieza que parece completa en el volumen activo suele ser la que dejó más rastros corroborantes en algún sitio donde el atacante no pensó en limpiar.

La conclusión para el defensor

Lee los movimientos ofensivos al revés y se convierten en una lista de detección. Vigila el acceso a los recursos compartidos y archivos que las Jump Lists de un host nombran, porque eso es el reconocimiento dando fruto. Trata una Jump List en un host que ya sospechas como una afirmación a verificar contra artefactos independientes, no como verdad de campo, porque pudo haber sido plantada. No malgastes esfuerzo de caza de persistencia en AutomaticDestinations. Y cuando una Jump List parezca sospechosamente limpia, ve primero a las shadow copies y al diario USN, porque ahí es donde lo que el atacante intentó borrar sigue posado.