Zum Inhalt springen
← Zurück zum Blog

Forensische Analyse von .lnk-Dateien: Worauf Ermittler achten

· 5 Min. Lesezeit

Ein .lnk ist klein, es überlebt unabhängig vom Ziel, auf das es zeigt, und es erfasst eine präzise Momentaufnahme der Quellmaschine zum Zeitpunkt der Verknüpfungserstellung. Nach genug Fällen hören Sie auf, Verknüpfungen als unordentliche Benutzerbequemlichkeit zu betrachten, und beginnen, sie als eines der billigsten Stücke Attributionsbeweise zu behandeln, die Windows produziert. Dieser Beitrag ist die Praktikerkarte dessen, was tatsächlich herauszuziehen ist, abgebildet auf die binären Abschnitte, die durch MS-SHLLINK definiert sind.

Die Schlagzeilen-Artefakte

Lassen Sie ein echtes .lnk in den Parser fallen, und das sind die Felder, die ein DFIR-Analyst zuerst prüft.

ArtefaktLebt inWarum es wichtig ist
LocalBasePathLinkInfoVollständiger Pfad auf der ursprünglichen Maschine; der Benutzername steht meist inline.
VolumeID (Serial, Label, Type)LinkInfo → VolumeIDIdentifiziert die Platte. Gleiche Seriennummer über mehrere Links bedeutet dieselbe Platte.
CreationTime / AccessTime / WriteTimeShellLinkHeaderFILETIMEs des Ziels, erfasst bei der Linkerstellung. Überlebt das Löschen des Ziels.
Maschinen-NetBIOS-NameExtraData → TrackerDataBlockHostname der Maschine, die den Link geschrieben hat.
Droid- und DroidBirth-GUIDsTrackerDataBlockVersion-1-UUIDs, deren letzte sechs Bytes die MAC der Quellmaschine sind.
BefehlszeilenargumenteStringData (COMMAND_LINE_ARGUMENTS)Womit das Ziel ausgeführt werden sollte. Phishing-Indikator.
ArbeitsverzeichnisStringData (WORKING_DIR)Offenbart oft USB-Buchstaben oder Staging-Ordner.
Netzwerkfreigabe-PfadLinkInfo → CommonNetworkRelativeLinkUNC-Pfad. Bewahrt verschwundene Freigaben.
ShowCommand / IconLocationShellLinkHeader / StringDataVerstecktes Fenster plus gefälschtes Icon ist ein starkes Malware-Signal.
LinkTargetIDListNach dem HeaderShell-Namespace-Walk; löst manchmal auf, wenn LinkInfo es nicht tut.

Die gesamte Liste stammt aus Standardfeldern, die in [MS-SHLLINK] dokumentiert sind. Dieselben Parser, die sie lesen, funktionieren auch bei .lnk-Dateien, die aus Jumplist-Compound-Dateien extrahiert wurden, das sind LNK-Streams in einer MS-CFB-Hülle.

Der TrackerDataBlock im Detail

Der TrackerDataBlock ist das am häufigsten zitierte LNK-Artefakt in der DFIR-Arbeit und verdient das Zitat. Seine Nutzlast besteht aus zwei 16-Byte-GUIDs (Droid und DroidBirth) plus einem NetBIOS-Namen. Jede GUID ist eine Microsoft Distributed Link Tracking-Kennung, eine v1-UUID, generiert aus:

  • einem hochauflösenden Zeitstempel (wann der Link zuerst geschrieben wurde) und
  • der MAC-Adresse der linkerstellenden Maschine, den letzten sechs Bytes der GUID.

Das bedeutet, dass eine einzige .lnk die MAC der Maschine durchsickern lassen kann, die sie erstellt hat. Ermittler korrelieren Droid-GUIDs über Tausende von Verknüpfungen, um:

  • Aktivität auf einem einzigen Ursprungshost zu clustern, selbst wenn Dateinamen und Pfade unterschiedlich sind.
  • Die Linkquelle zu identifizieren, wenn nur die .lnk überlebt.
  • Attributionsfehler zu fangen, mehrere öffentliche Threat-Actor-Attributionen stammten von .lnk-Dateien, die die Build-VM des Angreifers durchsickern ließen. Die Berichte zu Lazarus / APT37 / APT41 sind öffentliche Beispiele.

MAC-Randomisierung, virtuelle NICs und moderne Windows-Builds können dies in einigen Fällen brechen. Das Artefakt erscheint immer noch in der Mehrheit der realen Samples, die ich geparst habe.

Wo Windows automatisch Verknüpfungen für Sie schreibt

Die vom Benutzer erstellten Verknüpfungen auf Desktop und Startmenü sind offensichtlich. Die interessanten sind die Verknüpfungen, die Windows automatisch schreibt:

  • %APPDATA%\Microsoft\Windows\Recent\, eine .lnk pro kürzlich geöffnetem Element. Nahezu vollständige Nutzungshistorie. Paaren Sie das mit dem Registry-Parser für die passenden RecentDocs-Schlüssel in NTUSER.DAT.
  • %APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\, AutoDest-Jumplist-Dateien. MS-CFB-Compound-Dateien, die nummerierte LNK-Streams plus einen DestList-Stream mit Zugriffszeitstempeln, Zählungen und dem ursprünglichen NetBIOS-Hostnamen enthalten.
  • %APPDATA%\Microsoft\Windows\Recent\CustomDestinations\, von Anwendungen kuratierte Jumplists. Flacher Byte-Stream, konkatenierte LNKs, terminiert von 0xBABFFBAB.
  • %APPDATA%\Microsoft\Office\Recent\, das parallele MRU von Office.
  • Wechselmedien selbst, Windows schreibt oft .lnk-Verknüpfungen zurück auf USB-Laufwerke, wenn sie eingesteckt werden. Diese sind vom Laufwerk wiederherstellbar, lange nachdem der Host, der sie erstellt hat, weg ist.

Jede dieser Quellen ist eine wiederherstellbare Timeline-Quelle, selbst wenn das Ziel gelöscht ist.

Workflow

Ein typischer Ermittlungsdurchgang bei gesammelten .lnk-Dateien:

  1. Parsen und normalisieren. Konvertieren Sie jede Verknüpfung in einen strukturierten Datensatz mit den obigen Feldern. LECmd --csv, lnkinfo von libyal oder lnkparse3 für Python-Integration. Entscheiden Sie sich für ein Ausgabeschema eines Tools und bleiben Sie über den gesamten Fall dabei.
  2. Pivot auf die Droid-GUID. Gruppieren Sie nach Quell-MAC. Schließen Sie pro-Maschinen-Aktivität ein oder aus. Ein einzelner Droid, der auf Verknüpfungen aus mehreren Benutzerprofilen erscheint, ist ein starkes Attributionssignal.
  3. Pivot auf die Volumen-Seriennummer. Identifizieren Sie die Plattenherkunft. Gleiche Seriennummer über mehrere Links bedeutet dasselbe Laufwerk im Zeitverlauf. Unterschiedliche Seriennummern mit demselben Laufwerksbuchstaben bedeuten Wechselmedien.
  4. Bauen Sie eine Timeline. Die FILETIMEs des Headers sind die Momentaufnahme der Ziel-Metadaten des Links. Kombinieren Sie mit dem eigenen MFT-Eintrag des Links für die Linkschreibzeit und dem USN-Journal für Erstellungs-/Löschereignisse am Link selbst.
  5. Querverweise. Prefetch, ShimCache, AmCache, Jumplist DestList-Zeilen, Office-MRUs, Browserverlauf. Die stärksten Behauptungen haben mindestens zwei Quellen.

Was der Parser offenlegt

Der Parser auf dieser Seite dekodiert jedes obige Feld. Die Inspektion läuft lokal in WebAssembly, nützlich, wenn Sie eine schnelle Triage an einer Datei benötigen, die Ihnen jemand gerade per E-Mail geschickt hat, und Sie nicht möchten, dass NetBIOS-Name, MAC-abgeleitete GUID und Zielpfad die Maschine verlassen. Die Ausgabe gruppiert die Daten nach Abschnitt, Header, LinkTargetIDList, LinkInfo, StringData, jeder ExtraData-Block, sodass die Lektüre der Reihenfolge der Spezifikation entspricht.

Weiterführende Literatur