Jump List Parser
← Zurück zum Blog

Jump-List-Forensik: Eine praktische DFIR-Anleitung

2026-05-255 Min. Lesezeit

Jump Lists beantworten eine Frage, um die andere Artefakte herumtanzen: Welche Anwendung hat welche Datei auf welchem Host zu welcher Zeit geöffnet. Nach genug Fällen greifen Sie nicht mehr zu ShellBags oder Prefetch als erstem Schritt bei einer "Was hat dieser Benutzer angefasst?"-Frage und beginnen mit AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\. Die Felder, die Sie interessieren, sind drin, jedes Mal, in jeder Windows-Version seit 7. Das ist der Workflow, den ich durchlaufe.

Was Ihnen das Artefakt tatsächlich gibt

Pro Eintrag, nach dem Parsen:

  • Vollständiger Zielpfad des geöffneten Elements, lokal, UNC oder Wechselmedien.
  • Zeitstempel des letzten Zugriffs (FILETIME, UTC) und eine Zugriffszählung pro Eintrag. Die Zählung ist ein Float; angeheftete Einträge speichern stattdessen einen Sentinel.
  • NetBIOS-Hostname der Maschine, der zum Zeitpunkt des Zugriffs aufgezeichnet wurde. Das ist das Feld, das für die laterale Bewegung wichtig ist.
  • Angehefteter Zustand. Angeheftet bedeutet, dass der Benutzer aktiv "An diese Liste anheften" geklickt hat.
  • AppID, die deterministisch auf die startende Anwendung abbildet (gekürzter CRC64 über den Pfad der ausführbaren Datei).
  • Volume-ID und Volume-Label aus dem eingebetteten LNK. Nützlich für die Korrelation mit Wechselmedien.
  • Drei FILETIMEs aus dem LNK-Header, Erstellungs-, Zugriffs- und Schreibzeit des Ziels, wie es beim Schreiben des LNK gesehen wurde. Sie machen den Moment zum Schnappschuss und aktualisieren sich danach nie.
  • Befehlszeilenargumente und Arbeitsverzeichnis, sofern vorhanden.

Ein 5-Schritte-DFIR-Workflow

  1. Beschaffung. Ziehen Sie %AppData%\Microsoft\Windows\Recent\AutomaticDestinations\ und den Schwesterordner CustomDestinations\ für jedes Benutzerprofil. Live-Dateien sind typischerweise von explorer.exe gesperrt, arbeiten Sie also aus einem forensischen Image, einem VSS-Snapshot oder einem Werkzeug, das die Sperre korrekt handhabt. KAPE hat ein Ziel dafür; andernfalls funktioniert robocopy /b aus einer gemounteten Schattenkopie. Kopieren Sie nicht live mit einfachem xcopy.

  2. Triage nach AppID. Listen Sie die AppIDs (Dateinamen minus Erweiterung) auf und ordnen Sie sie Anwendungen zu. Die AppID-Liste, die mit JLECmd ausgeliefert wird, ist die de-facto-Referenz. Alles Nichtzugeordnete ist eine nähere Betrachtung wert, benutzerdefinierte und portable Apps erzeugen ihre eigenen AppIDs, und so auch Angreifer-Tools, die sich als Shell-aware registriert haben. Eine unbekannte AppID mit einer aktuellen DestList-Zeile ist ein Hinweis.

  3. Parsen. Extrahieren Sie jeden nummerierten LNK-Stream und die DestList-Zeilen. JLECmd erzeugt CSV oder JSON für Batch-Arbeit. JumpListExplorer (das Eric-Zimmerman-GUI-Pendant) ist das richtige Werkzeug für die interaktive Überprüfung. Plaso / log2timeline gibt Timeline-Ereignisse aus. Autopsy zeigt sie als Ingest-Ergebnisse. Für eine einmalige Überprüfung, ohne das Artefakt von der Analysten-Workstation zu entfernen, führt der In-Browser-Parser auf dieser Seite dieselbe Logik clientseitig aus und lädt nie hoch.

  4. Korrelieren. Richten Sie DestList-Zugriffszeitstempel an der interaktiven Sitzungstimeline des Benutzers aus. Die Pivots, die tatsächlich funktionieren:

    • Security.evtx 4624 / 4634 / 4647 für Anmelde- und Abmeldefenster (siehe EVTX-Parser).
    • Der UserAssist-Schlüssel in NTUSER.DAT für GUI-Starts (siehe Registry-Parser).
    • Prefetch-Treffer für Prozessausführung.
    • Das USN-Journal für Erstellungs-/Zugriffsereignisse an der Zieldatei.
    • AmCache und ShimCache für die ausführbare Datei selbst.
    • SRUM für Netzwerk- und CPU-Nutzung der startenden Anwendung.
    • Ein RAM-Dump über Volatility, falls Sie einen haben, um zu bestätigen, dass die Anwendung zu der Zeit resident war.

  5. Berichten. Zitieren Sie jeden Befund nach Quelldatei, Streamnummer und DestList-Eintrags-ID, zum Beispiel 1b4dd67f29cb1962.automaticDestinations-ms, Stream 7, DestList-Eintrag 0x12. Reproduzierbarkeit ist das, was den Befund unter der Überprüfung standhalten lässt. "Die Jump List hat es gezeigt" ist kein Zitat.

Das Hostname-Feld und warum es sein Geld wert ist

Jede DestList-Zeile trägt den NetBIOS-Hostnamen, der aufgezeichnet wurde, als das Ziel geöffnet wurde. Auf einer Workstation, die Freigaben von mehreren Servern mountet, offenbart dieses Feld, welcher Server jedes geöffnete Dokument beherbergte, ohne die eigenen Logs des Servers zu benötigen. Bei Untersuchungen zur lateralen Bewegung enthält eine Jump List auf einem kompromittierten Host häufig den Staging-Servernamen des Angreifers lange nachdem die Freigabe unmounted und der Server neu installiert wurde.

Ich habe Fälle anhand dieses einen Feldes abgeschlossen. Ein per RDP gesprungener Benutzer öffnet eine Datei von einem Staging-Host, der Angreifer reißt den Staging-Host ab, das SOC hat nichts. Die automaticDestinations-ms des kompromittierten Endpunkts für Notepad hat sechs Wochen später noch immer den NetBIOS-Namen und die Volumen-GUID.

Häufige Fallstricke

  • FILETIME-Mathematik. 100-Nanosekunden-Intervalle seit 1601-01-01 UTC. Konvertieren Sie mit unix_seconds = (filetime / 10_000_000) - 11_644_473_600. Off-by-one-day-Fehler hier sind die häufigste Quelle schlechter Timelines, die ich überprüfe.
  • DestList-Versions-Skew. Win7 schrieb Version 1. Win10 und Win11 geben üblicherweise v3 oder v4 aus. Zeilengrößen und Feld-Offsets verschieben sich. Ältere Parser, die das v1-Layout fest verdrahten, werden auf modernen Hosts stillschweigend fehlausgerichtet, und Sie verbringen eine Stunde damit, sich zu fragen, warum die Hostnamen wie Müll aussehen.
  • Angeheftete Einträge blähen Zählungen auf. Einige Anwendungen (Office, Explorer) heften Elemente aggressiv an und erhöhen die Zugriffszählungen beim Hintergrund-Indexieren. Eine hohe Zählung ist allein noch kein Beweis für wiederholte Benutzerinteraktion. Gegenchecken mit Prefetch und UserAssist.
  • "Zuletzt geöffnete Elemente anzeigen"-Schalter. Das Deaktivieren unter Einstellungen → Personalisierung → Start kürzt die pro-AppID-Dateien. Die Dateien werden bei der nächsten Verwendung neu erstellt, sodass unerwartet kurze DestLists mit allen Zeitstempeln, die um dasselbe kürzliche Datum gruppiert sind, ein Indikator dafür sind, dass der Benutzer (oder etwas, das den Benutzer vortäuscht) den Schalter umgelegt hat.
  • Angeheftete customDestinations-ms-Einträge überleben Resets. Nützlich, ein angehefteter UNC-Pfad ist Absicht. Notieren Sie sie im Bericht getrennt von MRU-Beweisen.
  • AppID-Kollisionen sind selten, aber real. Zwei Installationen derselben ausführbaren Datei am selben Pfad erzeugen dieselbe AppID. Wenn Sie in einer Multi-Mandanten-Citrix- oder VDI-Umgebung arbeiten, erwarten Sie Überlappungen; verlassen Sie sich auf das Hostname-Feld und den TrackerDataBlock des LNK zur Disambiguierung.

Ein abschließender Pivot

Sobald Sie eine Liste verdächtiger Einträge haben, nehmen Sie die Droid-GUID des TrackerDataBlock des LNK und schwenken Sie durch jedes andere LNK auf dem Host (Desktop, Startmenü, Recent\, beide Destinations-Ordner). Gleicher Droid bedeutet gleiche Quellmaschine. Unterschiedlicher Droid in derselben Jump List bedeutet, dass die Datei auf mehr als einem Host geöffnet wurde und Windows beide Versionen aufbewahrt hat. Dieser zweite Fall ist ungewöhnlich und fast immer interessant.

Legen Sie eine Datei auf der Startseite ab, um all das zu sehen, ohne Daten irgendwo hinzusenden. Für die Byte-Ebenen-Referenz ist der Beitrag zum automaticDestinations-Dateiformat die nächste Lektüre.

Weiterführende Literatur

  • Eric Zimmerman, JLECmd und JumpListExplorer, die kanonischen Offline-Tools.
  • Yogesh Khatri und Mike Stevens, "Jumping into the Past", ursprüngliches DestList-Reverse-Engineering.
  • Kacos2000, Jumplist-Browser, PowerShell-Viewer zur Inspektion roher Streams.
  • MITRE ATT&CK T1083 File and Directory Discovery und T1021 Remote Services, für Kontext darüber, was die Jump-List-Spur typischerweise bestätigt.