Datenexfiltration und USB-Kopieren mit dem USN Journal erkennen

Nach Ransomware ist die zweithäufigste DFIR-Frage eine Variante von "ist hier irgendetwas rausgegangen?". Das USN Journal ist einer der günstigsten Orte, um damit zu beginnen. Jedes USB-Kopieren, jeder Cloud-Sync-Upload und jede Drop-everything-in-a-temp-folder-then-zip-Operation hinterlässt eine erkennbare Form in $J — erkennbar genug, dass Sie mit zwei Filtern und einem Übergeordneter-Pfad-Pivot in der Regel ein Kandidaten-Exfil-Fenster in unter zwanzig Minuten triagieren können.

Dieser Beitrag ist das Playbook, um diese Muster zu finden, aufgeschlüsselt nach Exfil-Kanal.

USB-Laufwerke hinterlassen die saubersten Spuren

Wenn ein Benutzer ein Wechselvolume anschließt, weist Windows ihm einen Laufwerksbuchstaben zu, und wenn das Volume NTFS ist, bekommt das Gerät sein eigenes $UsnJrnl. Dateien, die auf das USB kopiert werden, landen im Ziel-Journal als FileCreate | Close plus einem Strom von DataExtend | Close-Einträgen. Dateien, die von der Quellfestplatte kopiert werden, hinterlassen eine weichere Spur auf der Quellseite: Open- und Close-Ereignisse, die oft BasicInfoChange | Close durch AV-Scanning und Dateisystem-Caching produzieren, das dem Read folgt.

Was Sie typischerweise bei einem echten Einsatz haben:

• Das Journal der Quellfestplatte. Zeigt, was geöffnet wurde, alle Temp- oder Archivdateien, die erstellt wurden, und den abschließenden Delete-Sweep, wenn der Benutzer aufgeräumt hat.
• Die Registry-Hives. SYSTEM\MountedDevices, SYSTEM\CurrentControlSet\Enum\USBSTOR, NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 und setupapi.dev.log identifizieren zusammen, welches physische Gerät wann angeschlossen war. Parsen Sie sie mit dem Registry-Parser.
• Das Journal des Zielvolumes, wenn Sie das USB-Image haben. Hier leben die tatsächlichen Datei-Schreibvorgänge.

Das entscheidende Signal auf der Quellseite ist das Archive-before-copy-Muster, weil die meisten Benutzer, die etwas zu verbergen haben, nach 7-Zip oder Explorers eingebauter Kompression greifen, bevor sie das Laufwerk aus dem Haus tragen: ein FileCreate einer .7z-, .zip-, .rar- oder zufällig benannten Datei an einem Temp-Pfad, gefolgt von anhaltenden DataExtend | Close-Einträgen, bis die Datei ihre endgültige Größe erreicht. Der Pfad ist normalerweise \Users\<u>\AppData\Local\Temp\, \Users\<u>\Desktop\ oder die Wurzel des Benutzerprofils.

Für die USB-Identifikationsseite vergleichen Sie die Zeitstempel im Journal mit Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx-Ereignissen für Verbindung/Trennung — der EVTX-Parser macht das zu einer Sache von wenigen Klicks. Paaren Sie mit LNK-Dateien unter \Users\<u>\AppData\Roaming\Microsoft\Windows\Recent\ und Jump Lists für explizite Beweise dafür, dass der Benutzer von USB geöffnet hat.

Das klassische Staging-dann-Archive-Muster

Bildet T1074 Data Staged in MITRE ATT&CK ab und sieht auf der Festplatte so aus:

FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
DataExtend | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\customers.csv
DataExtend | Close   ...
...
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3.zip
DataExtend | Close   ...           ← viele davon, Datei wächst groß
FileDelete | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\*  (Aufräumen)

Drei Signale in Sequenz:

1. Ein Burst von FileCreate in einem einzelnen Staging-Verzeichnis.
2. Ein nachfolgendes FileCreate plus rollendes DataExtend auf einem einzelnen Archiv, dessen endgültige Größe ungefähr der Summe der gestageten Dateien entspricht.
3. Ein Delete-Sweep des Staging-Verzeichnisses kurz nach dem Schließen des Archivs.

Jedes Signal allein ist verrauscht. Kombiniert sind sie diagnostisch. Filtern Sie nach FileCreate in \AppData\Local\Temp\, \Users\Public\, \Downloads\ und anderen beschreibbaren Benutzer-Tree-Stellen, dann clustern Sie nach übergeordnetem Verzeichnis und suchen Sie nach >50 Creates innerhalb von 60 Sekunden. Diese Kadenz fängt Insider-Diebstahl-Staging und die meisten Infostealer-Workloads ab. Lassen Sie bekannte Build-Pfade (node_modules\, target\, Debug\, Release\, obj\, .next\, dist\) aus dem Filter weg; sie produzieren identisch geformte Bursts und werden Ihre Ergebnisse sonst dominieren.

Cloud-Sync-Staging

OneDrive, Dropbox, Google Drive und Box pflegen alle einen lokalen Sync-Ordner und pushen alles darin in dem Moment, in dem der Agent es aufnimmt. Das Journal legt zwei diagnostische Muster offen:

Massen-RenameNewName in den Sync-Ordner. Der neue Übergeordnete ist \Users\<u>\OneDrive\, \Users\<u>\Dropbox\, \Users\<u>\Google Drive\ oder \Users\<u>\Box\; der alte Übergeordnete ist Desktop\, Documents\ oder Downloads\. Die Rename-Hälfte erhält die ursprüngliche Eltern-Referenz der Datei, was bedeutet, dass Sie die Herkunft beweisen können, selbst nachdem die Datei weg ist.

DataExtend | Close auf Dateien innerhalb des Sync-Ordners ohne ein entsprechendes Benutzer-App-FileCreate. Das sind die Schreibvorgänge des Agents selbst — Downloads von der Cloud-Seite zur lokalen Kopie. Die Creates sind das, was Sie für die Upload-Richtung wollen. Hintergrund-Sync-Agents wie OneDrive.exe und Dropbox.exe schreiben außerdem Log-Dateien in ihre AppData\Local\-Unterverzeichnisse, was Ihnen eine weitere Möglichkeit gibt, die Aktivität einzugrenzen, falls die Rename-Beweise spärlich sind.

Weniger häufig, aber wissenswert: Einige Operatoren scripten ein Copy-Item in eine Junction oder einen Symlink, der auf den Cloud-Ordner zeigt, was zusätzlich zum Rename-Paar ReparsePointChange-Einträge produziert.

BITS, native Upload-Tools und Living-off-the-land-Exfil

Ein Muster, das ich in jüngsten Ransomware-Einsätzen häufiger gesehen habe: Der Operator verwendet bitsadmin.exe oder PowerShells Start-BitsTransfer, um Dateien rauszuschicken, manchmal an angreiferkontrollierte Cloud-Speicher mit gültigen Zertifikaten. Das Journal zeigt:

• FileCreate von BITS-Job-State-Dateien unter \ProgramData\Microsoft\Network\Downloader\ (passend zu qmgr.db, qmgr0.dat, qmgr1.dat).
• Bei Uploads die Quelldateien, die unmittelbar vor dem Transfer in \Users\<u>\AppData\Local\Microsoft\BITS\ gestaged werden.

Paaren Sie mit den Microsoft-Windows-Bits-Client%4Operational.evtx-Event-IDs 59 (Job erstellt), 60 (Job übertragen) und 61 (Job abgeschlossen) — die EVTX-Brücke für BITS-Exfil ist eine der saubersten verfügbaren Korrelationen.

Ähnliche Geschichte für rclone.exe und MEGAsync.exe. Sie produzieren vorhersehbare Datei-Erstellungs-Signaturen in ihren App-Verzeichnissen und Log-Dateien; prüfen Sie \Users\<u>\AppData\Roaming\rclone\ für die Konfiguration, die das Ziel auflistet.

Heuristiken, die ihr Geld verdienen

Nach genug Einsätzen sind dies die Heuristiken, die konsistent echte Exfil markieren:

Burst-of-Creates. Mehr als N FileCreate-Ereignisse in einem einzelnen Verzeichnis innerhalb von T Sekunden. Auf Baseline tunen; N=50, T=60 ist der Ausgangspunkt für Desktop-Hosts.

Archive-after-Burst. Ein einzelnes FileCreate einer Datei mit .zip-, .7z-, .rar-, .tar.gz-, .tar.zst- oder .iso-Erweiterung innerhalb von Minuten nach einem Burst-of-Creates, mit rollendem DataExtend, das auf mehrere MB anwächst. Die Archivgröße entspricht ungefähr der kumulativen Größe der gestageten Dateien.

Massen-Rename über Verzeichnisgrenzen hinweg. RenameNewName-Einträge, deren neuer Eltern-Pfad strukturell anders ist als der alte — Documents\ zu OneDrive\, Desktop\ zu Users\Public\, Downloads\ zu \AppData\Local\Microsoft\BITS\. Leicht als Regex auf die MFT-aufgelösten Vollpfade auszudrücken.

Off-Hours-Bursts. Eines der obigen außerhalb der normalen Geschäftszeiten des Benutzers. Querreferenzieren Sie mit Security.evtx 4624-Logons für die tatsächlichen Sitzungsgrenzen.

Delete-Sweep nach dem Archiv. Ein FileDelete-Cluster im Staging-Verzeichnis, nachdem das Archiv geschlossen ist. Das ist der Benutzer, der versucht aufzuräumen. Die Cluster-Form — viele innerhalb von Sekunden gelöschte Dateien, alle mit einem gemeinsamen Übergeordneten — ist außerhalb von Dev/Build-Workflows ungewöhnlich.

Der Parser auf dieser Seite legt Zeitfenster- und Per-Reason-Filter offen, die die Burst-Erkennung und das Rename-Clustering jeweils zu einem Klick machen. Für Off-Hours-Analysen exportieren Sie nach CSV und pivotieren Sie auf Stunde-des-Tages.

Was Sie in $UsnJrnl nicht sehen werden

Ein paar echte Exfiltrations-Techniken produzieren kein nützliches USN-Signal:

• Direkter Upload aus dem Speicher über einen Browser-POST, Invoke-WebRequest -InFile aus einer Variablen oder curl, das aus Get-Content pipet. Nichts landet auf der Festplatte.
• Lesen aus einer Netzwerkfreigabe, die der Quellseite nicht gehört. Das Journal auf Ihrem Host hat nichts, weil die Datei dort nicht lebte.
• Screen Capture als Exfil. Nur die Screenshot-Dateien landen auf der Festplatte; die eigentlichen Daten gehen über das gerenderte Bild raus.
• Drucken. Hinterlässt nur \Windows\System32\spool\PRINTERS\-Aktivität, die ihr eigenes forensisches Artefakt ist.
• DNS- oder ICMP-Tunnelling. Nichts berührt die Festplatte; wechseln Sie zu Netzwerk-Captures und Sysmon Event 3.

Wechseln Sie für diese zu EVTX, Sysmon-Netzwerkverbindungen (Event 3), Browser-Historie, SRUM für Per-Prozess-Netzwerk-Bytes, RAM-Dumps oder PRINTERS-Spool-Artefakten. Die MITRE ATT&CK Exfiltration-Taktik-Seite listet jede Technik mit Notizen dazu, wo sie tatsächlich Rückstände hinterlässt.

Ein ausgearbeitetes Beispiel

Die Art von CSV, die Sie aus einem echten Einsatz exportieren könnten, um Exfil zu demonstrieren:

Diese Timeline ist ein Smoking Gun. Ohne das Journal würden Sie sie aus der Registry, Prefetch, Shadow Copies und OneDrives eigenen Logs rekonstruieren — fünfmal so viel Arbeit, halb so viel Vertrauen.

Weiterführende Literatur

• MITRE ATT&CK — die Exfiltration-Taktik und T1074 Data Staged für die vollständige Taxonomie.
• CISA, Insider-Threat-Ressourcen — die Baseline-Annahmen und Erkennungsschwellen in ihrem Playbook liegen nah an dem, was sich in einer echten Unternehmensumgebung bewährt.
• The DFIR Report — mehrere Langform-Intrusionen dokumentieren das Exfil-then-Encrypt-Muster Schritt für Schritt, mit USN-Beweisen in der Timeline. Das nächste an einem öffentlichen Ground-Truth-Korpus dafür, wie diese Muster in der Praxis aussehen.