Jump List Parser
← Volver al blog

AppID de Jump List: qué son y cómo resolver una

2026-06-156 min de lectura

La cadena hexadecimal de 16 caracteres delante de .automaticDestinations-ms no es un número de serie que Windows haya repartido. Es un hash, y en cuanto entiendes qué es lo que hashea dejas de tratar un AppID desconocido como ruido y empiezas a tratarlo como una pregunta.

Cada uno de los demás artículos de esta serie se apoya en la correspondencia de AppID. La guía DFIR te dice que tries primero por AppID. Este es el artículo al que debería haber enlazado.

El nombre de archivo es la identidad

Un archivo de Jump List lleva el nombre de la aplicación que lo posee. 1b4dd67f29cb1962.automaticDestinations-ms pertenece a una aplicación concreta, y 9b9cdc69c1c24e2b.automaticDestinations-ms a otra. El valor hexadecimal es el AppID. No hay un campo separado dentro del archivo que nombre la aplicación. El nombre es el nombre de archivo, y está hasheado.

Hay dos maneras en que se produce ese hash, y la distinción importa cuando una búsqueda falla.

La mayoría de las aplicaciones de escritorio nunca establecen una identidad propia. Para esas, la shell calcula el AppID a partir de la ruta completa del ejecutable, en minúsculas y normalizada, y la pasa por un CRC-64. Mueve el mismo binario a una ruta distinta y obtienes un AppID distinto. Notepad lanzado desde C:\Windows\System32\notepad.exe y el binario idéntico copiado a C:\Temp\notepad.exe son dos AppID distintos para Windows, porque la entrada al hash cambió.

El otro caso es una aplicación que establece explícitamente un Application User Model ID (AppUserModelID), una cadena como Microsoft.Windows.Explorer o una identidad de aplicación empaquetada. Cuando esa cadena está presente, Windows hashea la cadena en lugar de la ruta. Las aplicaciones UWP y empaquetadas, Office y un puñado de herramientas de Microsoft lo hacen todas. Sus AppID son estables independientemente de dónde resida el binario, que es justamente el sentido del mecanismo.

Se resuelve por búsqueda, no invirtiendo

CRC-64 es de un solo sentido. No puedes tomar 1b4dd67f29cb1962 y recalcular "Notepad" a partir de él. Quien te diga que invirtió un AppID quiere decir una de dos cosas: lo buscó en una tabla, o hasheó entradas candidatas hasta que una coincidió. No hay una tercera opción, así que no pierdas el tiempo intentando invertir el hash.

En la práctica casi todo el mundo usa la lista de referencia que acompaña a JLECmd. Es la tabla de facto, mantenida por la comunidad, y cubre las aplicaciones comunes a través de las versiones de Windows. Hexacorn publicó la investigación original sobre la derivación y mantiene también una gran tabla de correspondencia. Para la triage diaria, la lista resuelve los AppID que verás en la gran mayoría de los casos sin que tengas que calcular nada.

Cuando la lista vuelve vacía, construyes la coincidencia tú mismo. Enumera los ejecutables presentes en el host, calcula el CRC-64 basado en la ruta para cada uno, y busca tu AppID en los resultados. Esto solo funciona para el caso derivado de la ruta. Una aplicación con AppUserModelID explícito nunca coincidirá con un hash de ruta, así que si el host claramente tiene la aplicación instalada y tus hashes calculados no producen el AppID, es señal de que la aplicación establece su propia cadena de identidad y necesitas en su lugar la lista de cadenas conocidas.

Una forma rápida de enumerar los AppID explícitos ya registrados en un host activo es PowerShell:

Get-StartApps | Sort-Object Name | Format-Table Name, AppID

Eso devuelve el AppUserModelID de todo lo que esté anclado o registrado en Inicio. No cubrirá las aplicaciones de escritorio derivadas de la ruta, pero resuelve las identidades empaquetadas y de Microsoft que el enfoque de hash de ruta no puede alcanzar.

Cuando un AppID no aparece en ninguna lista

Aquí es donde se vuelve útil para una investigación. Un hueco en la tabla de búsqueda no es un callejón sin salida, es una señal. Las explicaciones benignas vienen primero, como siempre:

  • Una aplicación portable ejecutada desde una memoria USB o una carpeta de descargas. Ruta distinta, hash desconocido.
  • Software instalado en algún sitio no estándar, lo que es común en estaciones de desarrolladores y administradores.
  • Una aplicación legítima que simplemente aún no está en la lista pública.

Luego la explicación que justifica la triage:

  • Un binario renombrado o movido. Los atacantes copian cmd.exe, powershell.exe, o una carga útil dejada caer a una ruta extraña y la ejecutan. La Jump List, si el binario toca la shell de una forma que genera una, registra un AppID que nadie ha catalogado nunca porque nadie ha ejecutado nunca ese binario exacto desde esa ruta exacta. Un AppID no catalogado con una marca temporal DestList reciente es exactamente el tipo de hilo que se convierte en un hallazgo.

Para perseguirlo, toma el AppID desconocido y trátalo como la pregunta "¿qué ejecutable, en qué ruta, da este hash?". Pivota por el resto del host: Prefetch, AmCache y ShimCache te dan rutas de ejecutables candidatas. Hashea esas rutas, busca la coincidencia. Cuando una ruta de AmCache da tu AppID misterioso, has atado la Jump List a un binario concreto que se ejecutó en la máquina, y a menudo a uno que no debería haber estado allí.

Una nota sobre la suplantación

Como el nombre de archivo es solo un hash y Windows no lo autentica, un AppID puede plantarse. Quien quiera engañar a un analista puede dejar caer un archivo con el nombre de una aplicación benigna y rellenarlo con las entradas que quiera, o contaminar uno real. Es una técnica ofensiva, no un detalle de parsing, y se trata en el artículo del lado del atacante. Por ahora la conclusión es estrecha: el AppID te dice a qué aplicación una shell de Windows bien educada atribuyó la actividad. En un host que ya sospechas manipulado, trata esa atribución como una afirmación a verificar, no como un hecho a citar.

Para seguir leyendo