Wie Ransomware in $MFT aussieht

Ransomware tut auf jedem Host, jedes Mal ungefähr dasselbe: Dateien aufzählen, jede lesen, eine verschlüsselte Kopie schreiben, das Original löschen. Jeder Schritt landet in $MFT. Wenn du weißt, wie die Form aussieht, kannst du innerhalb von Minuten nach Erhalt der MFT bestätigen, dass ein Vorfall ein Ransomware-Lauf ist, ohne je die Binärdatei zu finden oder den Lösegeldbrief zu lesen.

Das ist das Muster, die Variationen, die ich gesehen habe, und wie ich Ransomware von anderen Formen massiver Dateiaktivität trenne, die oberflächlich ähnlich aussehen.

Die drei Signale

Erweiterungsänderungen en masse. Eine neue Datei erscheint mit demselben übergeordneten Verzeichnis und Basisnamen wie eine bestehende Datei, aber mit einer anderen Erweiterung. report.docx wird zu report.docx.locked, report.encrypted, report.crypted_{guid} oder report.docx.[victim_id].lockbit. Zu zählen, wie viele solcher Paare in einem kurzen Fenster erscheinen, ist einer der saubersten Indikatoren für Ransomware in $MFT. Hunderte in einer Minute, im Profil eines einzelnen Benutzers oder auf einer Freigabe, ist die Signatur.

Ein Burst von $STANDARD_INFORMATION-Created-Zeitstempeln, gehäuft innerhalb von Sekunden. Normale Benutzeraktivität erstellt Dateien in Schüben von ein oder zwei. Ransomware erstellt sie zu Tausenden. Plotte die SI-Created-Zeitstempel als Histogramm über das vermutete Fenster und der Verschlüsselungslauf erscheint als vertikaler Spike, der die Baseline übertönt. Die Breite des Spikes sagt dir, wie schnell die Ransomware lief (Multi-Threaded moderne Varianten beenden ein Benutzerprofil in unter einer Minute; ältere Single-Threaded brauchen länger und der Spike verteilt sich).

Gelöschte Originale, die zu verschlüsselten Duplikaten passen. Für jedes report.docx.locked gibt es typischerweise ein passendes report.docx, dessen IN_USE-Flag jetzt gelöscht ist. Der gelöschte Datensatz bleibt in $MFT, bis der Slot wiederverwendet wird. Du kannst den ursprünglichen Namen, die Größen und die Zeitstempel des Originals direkt aus dem gelöschten Slot wiederherstellen. Paare dies mit den $UsnJrnl-FILE_DELETE-Gründen im selben Fenster und die Operationsreihenfolge wird unmissverständlich.

Wissenswerte Variationen

Nicht jede Familie folgt demselben Muster. Die Variationen, die ich sehe:

• In-Place-Verschlüsselung. Manche Familien (ältere Sodinokibi-Varianten, bestimmte Conti-Builds) öffnen die Originaldatei, schreiben die verschlüsselten Bytes in dieselbe Datei zurück und benennen um. Es existiert keine separate "verschlüsselte Kopie"-Datei; das Muster des gelöschten Originals verschwindet. $UsnJrnl-DATA_OVERWRITE für Tausende von Dateien in einer Minute ist immer noch laut, und das Umbenennen hinterlässt ein RENAME_OLD_NAME / RENAME_NEW_NAME-Paar.
• Intermittierende Verschlüsselung. BlackCat und mehrere kürzliche Familien verschlüsseln nur Stücke der Datei (z. B. jeden zweiten 100-KB-Block), um den Lauf zu beschleunigen. Die Dateigröße ändert sich kaum, die Änderungszeit aktualisiert sich, aber die $DATA-Cluster sind größtenteils intakt. Sieht leichter in $MFT aus, aber das USN-Journal zeigt die Schreibvorgänge trotzdem.
• Nur Umbenennen. Eine Handvoll "falscher Ransomware"-Wiper benennen Dateien um, ohne sie zu verschlüsseln. Das MFT-Muster ist identisch zu einem echten Ransomware-Lauf; nur die Dateiinhaltsanalyse trennt die beiden.
• Auswirkung auf Netzlaufwerke. Viele Familien zählen gemappte Laufwerke auf und verschlüsseln über das Netzwerk. Die lokale MFT zeigt weniger Änderungen, als du für einen echten Vorfall erwarten würdest; die MFT des Dateiservers trägt die Hauptlast.

Lösegeldnotizen

Die meisten Familien legen eine Lösegeldnotiz in jedem betroffenen Verzeichnis ab, mit einem Namen wie HOW_TO_DECRYPT.txt, README_FOR_DECRYPT.html, restore-files.txt oder einer markenspezifischen Variante. Die Notizen haben identischen Inhalt, identische Größe und Erstellungszeiten, die im selben Fenster wie die Verschlüsselung gehäuft sind. Die MFT auf viele identische Größen-Text- oder HTML-Dateien, die über viele übergeordnete Verzeichnisse verstreut sind, zu durchsuchen, findet sie oft vor jedem Namensmuster.

Die Notizen sind auch forensisch nützlich als Baseline. Ihre Erstellungszeit ist im Wesentlichen der "frühester Moment, in dem Ransomware in diesem Verzeichnis aktiv war"-Stempel. Wenn ein Verzeichnis eine Notiz datiert auf 02:14 hat, aber verschlüsselte Dateien datiert auf 02:09 im selben Verzeichnis, hat die Ransomware aufgezählt und verschlüsselt, bevor sie die Notiz ablegte. Das sagt dir ein wenig über den Ablauf der Familie.

Was $MFT dir nicht sagt

Die MFT bestätigt das Was und Wann. Sie sagt dir nicht, welcher Prozess die Schreibvorgänge durchgeführt hat, wo der Operator hereinkam oder wie die Ransomware auf den Host kam. Dafür:

• Prefetch, Amcache und Shimcache für Beweise, welche ausführbare Datei im Fenster lief.
• Sysmon Event ID 1 für Prozesserstellung mit Kommandozeile, Elternteil und Hashes.
• Security Event 4688 für Prozesserstellung, falls Kommandozeilen-Audit aktiviert war.
• USN-Journal $J für die genaue Reihenfolge der Datei-Öffnen/Lesen/Schreiben/Umbenennen/Löschen-Operationen.
• RAM-Dump, falls die Maschine noch lebendig ist und der Verschlüsselungsprozess noch resident ist. Manchmal bekommst du den Verschlüsselungsschlüssel im Speicher.
• Browser-Verlauf und E-Mail-Artefakte für den initialen Zugriffsvektor.

Die MFT allein beantwortet die dringenden operativen Fragen: wann der Lauf begann, wie weit verbreitet er ist und welche Dateien angefasst wurden. Das reicht, um die Wiederherstellungsentscheidung zu treffen. Die Attribution ist eine separate Übung, die die MFT als einen Input verwendet.

VSS-Löschung als Verräter

Die meisten Ransomware-Familien versuchen, Volume Shadow Copies zu löschen, bevor sie mit der Verschlüsselung beginnen, weil VSS-Snapshots dem Opfer eine Wiederherstellung ohne Zahlung erlauben würden. Der übliche Befehl ist vssadmin delete shadows /all /quiet. Das hinterlässt:

• Einen Windows-System-Ereignisprotokolleintrag (Event ID 8224 für VSS-Service-Nachrichten).
• Einen Sysmon Event ID 1 für den vssadmin.exe-Aufruf, falls Sysmon deployt ist.
• Den frischen-aber-leeren VSS-Zustand auf dem Host. vssadmin list shadows gibt nichts zurück oder nur Post-Incident-Snapshots.

Wenn du einen Host ohne VSS-Snapshots und mit \$Extend\$UsnJrnl-MFT-Datensatz-Sequenznummern, die eine kürzliche Neuerstellung anzeigen, siehst, hast du Ransomware-Vorbereitung, selbst wenn der Verschlüsselungslauf noch nicht sichtbar gestartet ist. Siehe VSS und $MFT für das, was du noch wiederherstellen könntest.

Die Triage-Sequenz, der ich folge

1. Ziehe $MFT und $UsnJrnl:$J vom verdächtigen Host (oder vom Snapshot, falls VSS noch einen von davor hat).
2. Parse die MFT mit MFTECmd oder mft_dump. Sortiere SI created absteigend. Schau dir die Top-1.000-Einträge an.
3. Wenn die Top-Einträge sich innerhalb eines Fensters von Minuten häufen und viele von ihnen ungewöhnliche Erweiterungen haben, hast du einen Ransomware-Fußabdruck.
4. Ziehe die passenden gelöschten Datensätze. Ihre $FILE_NAME-Attribute geben dir die ursprünglichen Dateinamen. Jetzt weißt du, was verschlüsselt wurde.
5. Querverweise mit dem USN-Journal. FILE_CREATE für die verschlüsselte Datei plus FILE_DELETE für das Original im selben Moment bestätigt das Muster.
6. Identifiziere die Lösegeldnotiz: eine kleine Datei mit einem ungewöhnlichen Namen (HOW_TO_DECRYPT, RECOVERY, README_RESTORE), die in vielen Verzeichnissen gleichzeitig erscheint. Ihr Inhalt nennt die Familie.
7. Pivotiere vom Familiennamen zu bekannten IOCs: Datei-Hashes, C2-Domains, Registry-Persistenz und bekannte Kill-Chain-Artefakte in deinen anderen Logs.

Diese Sequenz dauert auf einem einzelnen Host meist unter dreißig Minuten und gibt dir genug, um Containment zu entscheiden und mit der Wiederherstellungsplanung zu beginnen.

Weiterführende Literatur

• Die Ransomware-Fallstudien von The DFIR Report. Jede Aufzeichnung paart MFT- und Journal-Beweise mit dem Rest der Kill-Chain.
• LockBit-, BlackCat-, Cl0p-technische Analysen auf The Record und Microsoft Security Blog. Familienspezifische MFT-Fußabdrücke unterscheiden sich im Detail.
• MITRE ATT&CK, T1486 Data Encrypted for Impact. Der Technikkatalog dafür, was Ransomware tut und welche Artefakte jedes Verhalten hinterlässt.