Jump List Parser
← Zurück zum Blog

Jump-List-AppIDs: Was sie sind und wie man eine auflöst

2026-06-155 Min. Lesezeit

Die 16-stellige Hex-Zeichenfolge vor .automaticDestinations-ms ist keine Seriennummer, die Windows vergeben hat. Sie ist ein Hash, und sobald Sie verstehen, was sie hasht, hören Sie auf, eine unbekannte AppID als Rauschen zu behandeln, und beginnen, sie als Frage zu behandeln.

Jeder andere Beitrag dieser Serie stützt sich auf die AppID-Zuordnung. Die DFIR-Anleitung sagt Ihnen, zuerst nach AppID zu triagieren. Dies ist der Beitrag, auf den sie hätte verlinken sollen.

Der Dateiname ist die Identität

Eine Jump-List-Datei ist nach der Anwendung benannt, die sie besitzt. 1b4dd67f29cb1962.automaticDestinations-ms gehört einer bestimmten Anwendung, und 9b9cdc69c1c24e2b.automaticDestinations-ms einer anderen. Der Hex-Wert ist die AppID. Es gibt kein separates Feld in der Datei, das die Anwendung benennt. Der Name ist der Dateiname, und er ist gehasht.

Es gibt zwei Wege, auf denen dieser Hash entsteht, und die Unterscheidung zählt, wenn eine Suche fehlschlägt.

Die meisten Desktop-Anwendungen legen nie eine eigene Identität fest. Für diese berechnet die Shell die AppID aus dem vollständigen Pfad der ausführbaren Datei, kleingeschrieben und normalisiert, und schickt ihn durch einen CRC-64. Verschieben Sie dieselbe Binärdatei an einen anderen Pfad, und Sie erhalten eine andere AppID. Notepad, gestartet aus C:\Windows\System32\notepad.exe, und die identische Binärdatei, kopiert nach C:\Temp\notepad.exe, sind für Windows zwei verschiedene AppIDs, weil sich die Eingabe in den Hash geändert hat.

Der andere Fall ist eine Anwendung, die explizit eine Application User Model ID (AppUserModelID) festlegt, eine Zeichenfolge wie Microsoft.Windows.Explorer oder eine Identität einer paketierten App. Wenn diese Zeichenfolge vorhanden ist, hasht Windows die Zeichenfolge statt des Pfades. UWP- und paketierte Apps, Office und eine Handvoll Microsoft-eigener Werkzeuge tun das alle. Ihre AppIDs sind stabil, egal wo die Binärdatei liegt, was der ganze Sinn des Mechanismus ist.

Man löst per Nachschlagen auf, nicht per Umkehrung

CRC-64 ist eine Einbahnstraße. Sie können nicht 1b4dd67f29cb1962 nehmen und "Notepad" daraus zurückrechnen. Wer Ihnen sagt, er habe eine AppID umgekehrt, meint eines von zwei Dingen: Er hat sie in einer Tabelle nachgeschlagen, oder er hat Kandidaten-Eingaben gehasht, bis eine passte. Es gibt keine dritte Option, verschwenden Sie also keine Zeit damit, den Hash umzukehren.

In der Praxis nutzt fast jeder die Referenzliste, die mit JLECmd geliefert wird. Sie ist die De-facto-Tabelle, von der Community gepflegt, und sie deckt die gängigen Anwendungen über die Windows-Versionen hinweg ab. Hexacorn hat die ursprüngliche Forschung zur Ableitung veröffentlicht und pflegt ebenfalls eine große Zuordnung. Für die tägliche Triage löst die Liste die AppIDs, die Sie in der überwiegenden Mehrheit der Fälle sehen, auf, ohne dass Sie irgendetwas berechnen müssen.

Wenn die Liste leer zurückkommt, bauen Sie den Treffer selbst. Zählen Sie die auf dem Host vorhandenen ausführbaren Dateien auf, berechnen Sie für jede den pfadbasierten CRC-64 und suchen Sie Ihre AppID in den Ergebnissen. Das funktioniert nur für den pfadabgeleiteten Fall. Eine App mit expliziter AppUserModelID wird nie zu einem Pfad-Hash passen, wenn der Host die Anwendung also eindeutig installiert hat und Ihre berechneten Hashes die AppID nicht ergeben, ist das ein Zeichen, dass die App ihre eigene Identitätszeichenfolge festlegt und Sie stattdessen die Liste der bekannten Zeichenfolgen brauchen.

Ein schneller Weg, die expliziten AppIDs aufzuzählen, die bereits auf einem aktiven Host registriert sind, ist PowerShell:

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

Das gibt die AppUserModelID für alles zurück, was an Start angeheftet oder dort registriert ist. Es deckt keine pfadabgeleiteten Desktop-Apps ab, aber es löst die paketierten und Microsoft-eigenen Identitäten auf, die der Pfad-Hash-Ansatz nicht erreichen kann.

Wenn eine AppID in keiner Liste steht

Hier wird es für eine Ermittlung nützlich. Eine Lücke in der Nachschlagetabelle ist keine Sackgasse, sie ist ein Signal. Die harmlosen Erklärungen kommen zuerst, wie immer:

  • Eine portable Anwendung, gestartet von einem USB-Stick oder einem Download-Ordner. Anderer Pfad, unbekannter Hash.
  • Software, die irgendwo Nicht-Standardmäßiges installiert ist, was auf Entwickler- und Administrator-Arbeitsplätzen üblich ist.
  • Eine legitime App, die einfach noch nicht in der öffentlichen Liste steht.

Dann die Erklärung, die die Triage rechtfertigt:

  • Eine umbenannte oder verschobene Binärdatei. Angreifer kopieren cmd.exe, powershell.exe oder eine abgelegte Nutzlast an einen seltsamen Pfad und führen sie aus. Die Jump List, falls die Binärdatei die Shell auf eine Weise berührt, die eine erzeugt, zeichnet eine AppID auf, die noch nie jemand katalogisiert hat, weil noch nie jemand genau diese Binärdatei von genau diesem Pfad ausgeführt hat. Eine nicht zugeordnete AppID mit einem jungen DestList-Zeitstempel ist genau die Art Faden, der zu einem Befund wird.

Um ihr nachzugehen, nehmen Sie die unbekannte AppID und behandeln Sie sie als die Frage "welche ausführbare Datei, an welchem Pfad, ergibt diesen Hash?". Pivotieren Sie durch den Rest des Hosts: Prefetch, AmCache und ShimCache liefern Ihnen Kandidaten-Pfade ausführbarer Dateien. Hashen Sie diese Pfade, suchen Sie den Treffer. Wenn ein Pfad aus AmCache Ihre rätselhafte AppID ergibt, haben Sie die Jump List an eine bestimmte Binärdatei gebunden, die auf der Maschine ausgeführt wurde, und oft an eine, die nicht dort hätte sein sollen.

Eine Anmerkung zum Spoofing

Weil der Dateiname nur ein Hash ist und Windows ihn nicht authentifiziert, kann eine AppID platziert werden. Wer einen Analysten in die Irre führen will, kann eine Datei ablegen, die nach einer harmlosen Anwendung benannt ist, und sie mit beliebigen Einträgen füllen, oder eine echte verunreinigen. Das ist eine offensive Technik, kein Parsing-Detail, und sie wird im Beitrag zur Angreiferseite behandelt. Vorerst ist die Erkenntnis eng: Die AppID sagt Ihnen, welcher Anwendung eine wohlerzogene Windows-Shell die Aktivität zugeschrieben hat. Auf einem Host, den Sie bereits der Manipulation verdächtigen, behandeln Sie diese Zuschreibung als eine zu prüfende Behauptung, nicht als eine zu zitierende Tatsache.

Weiterführende Literatur