Jump Lists aus Angreifersicht: Aufklärung, Spoofing, Bereinigung

Das meiste Geschriebene über Jump Lists ist defensiv, was eine Lücke lässt: Wenn Sie das Artefakt nur je als Ermittler lesen, verpassen Sie, was jemand auf der anderen Seite damit tut. Hier ist die offensive Sicht, geschrieben für Verteidiger und autorisierte Tester. Die Schritte zu kennen, ist die Art, sie zu erkennen, und zwei davon sind leiser, als die Literatur nahelegt.

Alles hier ist erkennbar. Ich sage wo, denn das Ziel ist nicht "seht, wie raffiniert", es ist "hier ist der Rückstand".

Sie zu lesen ist die billigste Aufklärung überhaupt

Bevor jemand irgendetwas löscht, ist der erste Angreiferwert schlicht das Lesen. Der AutomaticDestinations-Ordner eines Benutzers ist eine kommentierte Karte dessen, woran er arbeitet. Kürzlich geöffnete Dokumente nach Name und Pfad. Das Hostnamen-Feld der DestList liefert die Namen der Datei-Server und der von ihnen gemounteten Freigaben. Volume-Bezeichnungen und -GUIDs markieren Wechselmedien, die eingesteckt wurden. Besonders Jump Lists von Office und Explorer tendieren dazu, direkt auf die sensiblen Freigaben zu zeigen, die ein Operator finden will.

Nichts davon erfordert Erhöhung. Die Dateien leben im eigenen Profil des Benutzers und sind als dieser Benutzer lesbar. Ein Angreifer, der als normaler Benutzer gelandet ist, ohne bislang Rechteausweitung, kann also die Jump Lists lesen und erfahren, wo die interessanten Daten leben und auf welche Server zu pivotieren ist. Es ist Living-off-the-Land-Erkundung ohne Werkzeug, ohne LOLBins, ohne irgendetwas, das den Prozessbaum eines EDR aufleuchten lässt.

Das entspricht ATT&CK T1083 File and Directory Discovery, und von der defensiven Seite ist es heikel, weil das Lesen einer Datei im eigenen Profil kein Ereignis ist, auf das die meisten Stacks alarmieren. Die realistische Erkennung liegt stromabwärts: der Zugriff auf die Freigaben, die der Angreifer erfahren hat, nicht das Lesen der Jump List selbst.

Spoofing und Platzieren

Das Format ist dokumentiert, die Datei ist weder signiert noch authentifiziert, und die AppID ist nur ein CRC-64-Hash, der als Dateiname dient (der AppID-Beitrag erklärt, warum das zählt). Der Inhalt kann also gefälscht werden.

Zwei Geschmacksrichtungen. Der Angreifer bearbeitet eine echte Jump List, um Einträge einzufügen, die irgendwohin Irreführendes zeigen: ein platzierter Pfad, der einen anderen Benutzer oder einen anderen Host belastet, ein fabrizierter Hostname in einer DestList-Zeile, um eine Ermittlung zur lateralen Bewegung fehlzuleiten. Oder er legt eine ganze Datei ab, benannt nach einer harmlosen Anwendung, vorgefüllt, um eine Historie zu fabrizieren, die nie stattfand. Weil die Shell die AppID gegen nichts validiert, muss eine nach Notepad benannte Datei nicht von Notepad stammen.

Das ist real, und es ist auch der Punkt, an dem Angreifer erwischt werden, denn die Binärstruktur von Hand zu bearbeiten ist leicht subtil falsch zu machen. Jeder DestList-Eintrag trägt einen Integritätswert, den die meisten selbstgebauten Skripte nicht neu berechnen. Der Header führt einen monotonen Eintrags-ID-Zähler, der mit den Zeilen konsistent bleiben muss. Bearbeiten Sie Zeitstempel ohne Verständnis der MRU-Reihenfolge, und die Zeitstempel-Reihenfolge widerspricht der Eintrags-ID-Reihenfolge. Jeder dieser Punkte ist ein Anzeichen, und es ist genau das, was der Beitrag zu Zeitleiste und Anti-Forensik Sie zu suchen lehrt. Der platzierte Inhalt kann einen Analysten, der die Datei unter Zeitdruck für bare Münze nimmt, dennoch täuschen, was die ganze Wette des Angreifers ist.

Persistenz: meist überschätzt

Sie werden hin und wieder Jump Lists neben Persistenzmechanismen aufgelistet sehen. Seien Sie skeptisch. Eine Jump List ist kein Autostart-Ort. Windows führt nichts in AutomaticDestinations beim Booten oder Anmelden aus. Es gibt hier kein Run-Key-Verhalten.

Das Körnchen Wahrheit liegt in CustomDestinations. Das sind die angehefteten Einträge und Aufgaben, die eine Anwendung definiert, und ein angehefteter Eintrag ist eine Verknüpfung, die auf ein Ziel zeigt, das der Benutzer anklicken könnte. Ein Angreifer, der in die CustomDestinations eines Benutzers schreiben kann, könnte einen Eintrag anheften, dessen Ziel eine schädliche Nutzlast oder ein UNC-Pfad ist, in der Jump List platziert, in Erwartung eines Klicks. Das ist ein Social-Engineering-Vektor, keine Persistenz im eigentlichen Sinne. Es überlebt nicht als Codeausführung, es hängt vollständig vom Klick des Benutzers ab, und es gibt ein Dutzend zuverlässigere Wege, einem Benutzer eine schädliche Verknüpfung vorzulegen. Wenn Sie ein Erkennungsprogramm aufbauen, geben Sie hier kein Budget für die Persistenzjagd aus. Geben Sie es für die Autostart-Orte aus, die tatsächlich ausführen.

Die Bereinigung, und warum sie selten sauber funktioniert

Der letzte Angreiferschritt ist das Entfernen, und die Anleitung zum Leeren oder Löschen behandelt die Mechanik aus Benutzersicht. Operativ hat der Angreifer dieselben groben Optionen wie jeder: die Einstellung der zuletzt verwendeten Elemente umschalten, die AppID-Dateien löschen oder einen Reiniger ausführen. ATT&CK ordnet das unter T1070 Indicator Removal ein.

Es funktioniert selten sauber, und ein Tester sollte wissen, warum, um der Blue Team zu raten, wo zu suchen ist. Die Datei zu löschen tilgt die Historie weniger, als dass es den Beweis verschiebt: Die junge MFT-Erstellungszeit der neu erstellten Datei verrät, wann die alte starb, der Schreibvorgang läuft durch das USN-Journal mit einem Zeitstempel, und Volume Shadow Copy hat das Original sehr wahrscheinlich außer Reichweite gesichert. Die selektive Operation an einem einzelnen Eintrag hinterlässt strukturelle Inkonsistenzen: eine DestList-Zeile, die auf einen nicht mehr vorhandenen Stream zeigt, oder einen verwaisten Stream ohne Zeile. Die Bereinigung, die auf dem aktiven Volume vollständig aussieht, ist meist diejenige, die die meisten bestätigenden Spuren irgendwo hinterließ, wo der Angreifer nicht ans Bereinigen dachte.

Die Erkenntnis für den Verteidiger

Lesen Sie die offensiven Schritte rückwärts, und sie werden zu einer Erkennungsliste. Achten Sie auf den Zugriff auf Freigaben und Dateien, die die Jump Lists eines Hosts benennen, denn das ist Aufklärung, die sich auszahlt. Behandeln Sie eine Jump List auf einem Host, den Sie bereits verdächtigen, als eine gegen unabhängige Artefakte zu prüfende Behauptung, nicht als Grundwahrheit, denn sie könnte platziert worden sein. Verschwenden Sie keinen Aufwand für die Persistenzjagd auf AutomaticDestinations. Und wenn eine Jump List verdächtig sauber aussieht, gehen Sie zuerst zu den Schattenkopien und dem USN-Journal, denn dort liegt das, was der Angreifer zu entfernen versuchte, noch immer.