← Zurück zum Blog

Ransomware-Aktivität im USN-Journal erkennen

Selbst wenn die Binary weg ist, hinterlässt Ransomware einen sehr charakteristischen Fingerabdruck in $UsnJrnl:$J. Ein Durchgang durch die Muster, nach denen man sucht, und die zugehörigen Reason-Code-Kombinationen.

4 Min. Lesezeit

Ransomware ist eines der saubersten Signale im USN-Journal. Was der Operator sonst auch tat — Credential-Diebstahl, laterale Bewegung, Persistenz — die Verschlüsselungsphase fasst das Dateisystem mit einem einheitlichen, hochvolumigen Muster an, das auch noch Monate später heraussticht. Dieser Beitrag zeigt, wie es aussieht und wie man es findet.

Vorausgesetzt wird, dass du das $J bereits gezogen hast und es geparst ist (der Parser auf dieser Seite funktioniert; ebenso usnrs und andere). Für eine Auffrischung der Reason-Bitmaske ist unser Reason-Code-Beitrag die Feldreferenz.

Das kanonische Muster

Die meisten modernen Ransomware-Familien (LockBit, BlackCat/ALPHV, Royal, Akira, die Post-Conti-Varianten usw.) folgen pro Datei demselben Drei-Schritt-Rezept:

  1. Datei zum Lesen öffnen.
  2. Inhalt in-place überschreiben — oder eine neue Datei daneben schreiben und das Original löschen.
  3. Umbenennen mit einer Marker-Endung (.locked, .lockbit, eine 8-Zeichen-Zufallskette oder bei manchen Familien gar keine).

Im Journal produziert das pro Datei:

DataOverwrite | Close
DataOverwrite | Close
…           ← wiederholt, einer pro Schreibblock
RenameOldName | Close   (alt: document.docx)
RenameNewName | Close   (neu: document.docx.locked)

Die zwei charakteristischen Signale:

  • Bursts von DataOverwrite in einem kurzen Fenster über tausende Dateien. Normale Dateiaktivität produziert selten kontinuierliche DataOverwrite auf Nicht-Datenbank-Dateien.
  • Massen-RenameNewName mit identischen Neuendungs-Suffixen. Das Verhältnis von Neunamen-Records zu aktiven Dateien explodiert während der Verschlüsselung.

In MITRE ATT&CK entspricht das primär T1486 Data Encrypted for Impact und benachbartem Renaming-Verhalten.

Praktisches Detection-Rezept

Auf einem geparsten Journal:

  1. Histogrammiere die DataOverwrite pro Minute. Plotten oder einfach in Minuten-Buckets zerlegen und die Klippe suchen. Normale Windows-Hosts zeigen eine stabile niedrige Baseline (eine Handvoll pro Minute), unterbrochen von Anwendungsbursts (Office-Speichern, Chrome-Cache). Ransomware zeigt einen anhaltenden 50–500×-Spike über dieser Baseline, der erst stoppt, wenn dem Host die Dateien ausgehen.
  2. Cluster die RenameNewName-Events. Gruppiere nach neuer Endung oder per Regex über den neuen Namen. Wenn 80 % der Renames in einem Fenster dieselbe Endung oder dasselbe .{8}-Muster teilen, schaust du einen Encryptor an.
  3. Querchecke mit FileDelete | Close. Manche Familien schreiben den Cipher in eine neue Datei und löschen das Original. Mit einem FileCreate derselben Stamm-anderen-Endung, das in derselben Sekunde erscheint, paaren.
  4. Geh zum Elternverzeichnis hoch. Ransomware, die jeden Ordner unter dem Benutzerprofil oder jede Freigabe verschlüsselt, trifft Users\<user>\Documents, Users\<user>\Desktop, jede gemappte Laufwerksroot. Die per MFT aufgelösten Vollpfade machen das trivial.

Der Parser dieser Seite stellt den Reason-Filter direkt bereit — auf DataOverwrite für Schritt 1, auf RenameNewName für Schritt 2 setzen.

So sehen die Daten aus

Redigierter Auszug aus einem echten LockBit-3.0-Fall:

2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  RenameOldName Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  RenameNewName Close   C:\Users\ana\Desktop\notes.docx.HLJkNskOq
2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\quarterly.xlsx
…

Jede Datei im Verzeichnis wird innerhalb derselben Wand-Uhr-Sekunde verschlüsselt. Die neue Endung ist eine einheitliche 9-Zeichen-Zufallskette — starkes Cluster-Signal für Schritt 2.

Jenseits der Verschlüsselungsphase

Das Journal fängt auch Vorbereitungs- und Aufräumverhalten ein:

  • Schattenkopien-Löschen: in $J nicht direkt sichtbar (lebt in $WSC-verwalteten Namespaces), aber ein FileCreate von vssadmin.exe-gestarteten Temp-Dateien erscheint Momente vor dem Verschlüsselungsburst.
  • Discovery-Scans: viele Familien zählen das Volume per Verzeichnislisting auf, was keine Journal-Einträge erzeugt — aber wenn der Operator Tools wie adfind.exe oder PsExec.exe abgelegt hat, siehst du deren FileCreate-Events.
  • Notenzustellung: jede moderne Familie schreibt eine Lösegeldforderung in jedes verschlüsselte Verzeichnis. Ein FileCreate desselben Dateinamens (README.txt, HOW_TO_DECRYPT.html usw.) über viele Verzeichnisse in derselben Minute ist die faule Regex, die die meisten fängt.

Was das Journal nicht verrät

Das USN-Journal hält Änderungen am Dateisystem fest, nicht Akteure. Um einen Benutzer oder Prozess an den Verschlüsselungsburst zu hängen, brauchst du:

Für das breitere Response-Playbook ist CISAs #StopRansomware-Leitfaden die maßgebliche Referenz.

Eine Anmerkung zum Grundrauschen

Einige legitime Verhalten ähneln oberflächlich Ransomware:

  • Disk-Verschlüsselungs-Rollout (BitLocker-Erstkonvertierung) erzeugt einen kontinuierlichen DataOverwrite-Burst — aber keine RenameNewName-Events. Leicht zu eliminierender Falschalarm.
  • Backup-Software wie Veeam oder Macrium kann DataOverwrite-Bursts auf dem Ziel-Volume erzeugen. Immer Benutzer/Pfad querchecken.
  • Office-AutoSave oder Visual-Studio-Rebuilds machen kurze Bursts. Das Minuten-Histogramm macht sie offensichtlich — sie sind transient, Ransomware ist monoton.

Wenn deine Detection-Logik auf der Baseline null Alarme produziert, ist sie unterspezifiziert. Das gesuchte Signal ist die Kombination aus DataOverwrite-Rate, RenameNewName-Rate und Endungs-Clustering — nicht eines davon allein.