Ransomware mit Prefetch untersuchen: eine Walkthrough

Was folgt, ist ein fiktiver Fall. Hostname, Datei-Hashes und der Operator sind erfunden. Die Form der Intrusion nicht. Ich habe sehr ähnliche Timelines aus Prefetch-Verzeichnissen in tatsächlichen Einsätzen aufgebaut, und die Muster wiederholen sich.

Der Sinn der Walkthrough ist zu zeigen, wie Prefetch sich liest, wenn Sie eine echte Intrusion vor sich haben und die acht Ausführungszeitstempel das Verlässlichste sind, was Sie haben. Paaren Sie jeden Schritt mit den Artefakten, die ihn bestätigen oder erweitern.

Das Setup

Eine kleine Beratungsfirma. Sechzig Workstations und vier Server. Freitagabend werden die Dateifreigaben auf FS01 unzugänglich. Ein Ransom-Note erscheint unter \\FS01\Shared\!!READ-ME!!.txt. Bis Montagmorgen hat der IT-Manager Triage-Daten von FS01, dem Jump-Host JH01 und drei Workstations einschließlich Patient Zero WS-ACCT-04 erfasst.

Ich erhalte die Prefetch-Verzeichnisse aller fünf Hosts am Dienstag. Die EVTX-Channels für Security und Sysmon sind unvollständig. Einige wurden gelöscht, einige hatten nie Sysmon laufen. Prefetch ist überwiegend intakt. Das ist typisch.

Was WS-ACCT-04 zu sagen hat

Beginnen Sie dort, wo der Angreifer begann.

Das Parsen von C:\Windows\Prefetch\ auf WS-ACCT-04 mit PECmd ergibt 412 .pf-Dateien. Die meisten sind Rauschen: Office-Binärdateien, Browser, Antivirus-Komponenten, Windows-Utilities. Die interessanten kommen zum Vorschein, wenn ich nach Pfaden der ausführbaren Dateien außerhalb von \Windows\ und \Program Files\ filtere, absteigend nach NTFS-Created sortiere und die ersten dreißig Zeilen betrachte.

Die Top-Treffer, in Reihenfolge der Erstellungszeit (für die Walkthrough gerundet):

Created	Filename	Exec path	Runs
Wed 14:02	`WINWORD.EXE-00B41B71.pf`	`C:\Program Files\Microsoft Office\Office16\WINWORD.EXE`	47
Wed 14:03	`EQNEDT32.EXE-1F2E0AB2.pf`	`C:\Program Files\Common Files\Microsoft Shared\Equation\EQNEDT32.EXE`	1
Wed 14:03	`MSHTA.EXE-2A1D9904.pf`	`C:\Windows\System32\mshta.exe`	1
Wed 14:04	`POWERSHELL.EXE-3DD11E22.pf`	`C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe`	8
Wed 14:05	`WMIPRVSE.EXE-XXXXXXXX.pf`	`C:\Windows\System32\wbem\WmiPrvSE.exe`	(viele)
Wed 14:06	`CMD.EXE-XXXXXXXX.pf`	`C:\Windows\System32\cmd.exe`	(viele)
Wed 14:11	`RUNDLL32.EXE-XXXXXXXX.pf`	`C:\Windows\System32\rundll32.exe`	(viele)
Wed 14:12	`UPDATE.EXE-77AAFF12.pf`	`C:\Users\Public\update.exe`	1
Wed 14:14	`NLTEST.EXE-XXXXXXXX.pf`	`C:\Windows\System32\nltest.exe`	1
Wed 14:14	`WHOAMI.EXE-XXXXXXXX.pf`	`C:\Windows\System32\whoami.exe`	1
Wed 14:15	`PSEXEC.EXE-A1A1A1A1.pf`	`C:\Users\Public\psexec.exe`	3
Wed 14:23	`7Z.EXE-B2B2B2B2.pf`	`C:\Users\Public\7z.exe`	1

Das ist eine vollständige Intrusion-Kette in etwa zwanzig Minuten, rekonstruiert aus dem Prefetch-Verzeichnis eines einzigen Hosts.

In Klartext gelesen:

14:02: Word öffnet. (Lauf 47 von 47 — normale Word-Nutzung auf diesem Host.)
14:03: EQNEDT32.EXE läuft zum ersten Mal überhaupt auf diesem Host. Equation Editor. Ein Angriffsvektor aus 2017 für bösartige DOCX. Die .pf für WINWORD.EXE wurde um 14:02 aktualisiert, kurz davor. Paaren Sie mit LNK-Dateien und E-Mail-Client-Artefakten. Der Benutzer öffnete ein bösartiges Dokument.
14:03: MSHTA.EXE läuft zum ersten Mal. Die Load-Liste (mehr dazu unten) zeigt ein Skript in einem Temp-Verzeichnis. Der Equation-Editor-Exploit lieferte einen HTA-Payload.
14:04: PowerShell startet. Die erste von acht Ausführungen.
14:05: WmiPrvSE.exe-Aktivität. Möglicherweise Remote-WMI-Aufrufe; prüfen Sie die Load-Liste und das entsprechende EVTX.
14:11: rundll32.exe läuft. Oft ein DLL-Ausführungsvektor.
14:12: Eine Binärdatei namens update.exe läuft aus C:\Users\Public\. Erste und einzige Ausführung. Kein legitimes update.exe; der Pfad ist falsch. Die Hash-Bytes 77AAFF12 kollidieren mit nichts Harmlosem.
14:14: nltest.exe und whoami.exe laufen, beide zum ersten Mal. Domain-Reconnaissance.
14:15: psexec.exe läuft aus C:\Users\Public\. Drei Ausführungen, was drei Lateral-Movement-Ziele nahelegt.
14:23: 7z.exe läuft aus C:\Users\Public\. Archivierung für Staging oder Exfiltration.

Diese Reihenfolge kam direkt aus den Prefetch-Created-Zeitstempeln plus dem Per-.pf-Last run-Feld. Sie ist keine Vermutung.

Was die Load-Listen bestätigen

Die Prefetch-Einträge sagen mir, was lief. Die Load-Listen sagen mir, was jede Binärdatei tat.

Die MSHTA.EXE-2A1D9904.pf-Load-Liste, gefiltert auf Nicht-System-Pfade:

\DEVICE\HARDDISKVOLUME2\USERS\ALICE\APPDATA\LOCAL\TEMP\BACK.HTA
\DEVICE\HARDDISKVOLUME2\USERS\ALICE\APPDATA\LOCAL\TEMP\STG1.PS1

Das platziert den HTA-Payload (vom Equation-Editor-Exploit geliefert) unter C:\Users\Alice\AppData\Local\Temp\back.hta und ein Folge-PowerShell-Skript unter stg1.ps1 im selben Verzeichnis.

POWERSHELL.EXE-3DD11E22.pf-Load-Liste, gefiltert:

\DEVICE\HARDDISKVOLUME2\USERS\ALICE\APPDATA\LOCAL\TEMP\STG1.PS1
\DEVICE\HARDDISKVOLUME2\USERS\ALICE\APPDATA\LOCAL\TEMP\STG2.DLL
\DEVICE\HARDDISKVOLUME2\USERS\PUBLIC\UPDATE.EXE
\DEVICE\HARDDISKVOLUME2\USERS\PUBLIC\PSEXEC.EXE
\DEVICE\HARDDISKVOLUME2\USERS\PUBLIC\7Z.EXE

PowerShell lud das Stage-1-Skript, lud eine Stage-2-DLL und stagete oder rief dann das Lateral-Movement-Tooling unter \Users\Public\ auf. Das Prefetch sagt mir nicht, was PowerShell mit diesen Dateien tat (lesen, ausführen, kopieren), aber das Vorhandensein dieser Pfade in der Load-Liste sagt, dass PowerShell sie berührt hat.

UPDATE.EXE-77AAFF12.pf-Load-Liste:

\DEVICE\HARDDISKVOLUME2\USERS\PUBLIC\UPDATE.EXE
\DEVICE\HARDDISKVOLUME2\PROGRAMDATA\STG\KEY.BIN
\DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\BCRYPT.DLL
\DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\BCRYPTPRIMITIVES.DLL
\DEVICE\HARDDISKVOLUME2\USERS\ALICE\DOCUMENTS\<viele .docx, .xlsx, .pdf paths>

update.exe ist der Encryptor. Es lud eine Schlüsseldatei aus \ProgramData\stg\key.bin. Es lud die Windows-Kryptografie-Primitive. Und es öffnete jedes Dokument in Alices Documents-Verzeichnis.

Das Load-Listen-Limit liegt bei etwa 1000 Einträgen. Auf einem dokumentenstarken Host stoßen Sie an dieses Limit. Die Menge der Pfade, die Sie sehen, ist eine partielle Aufzählung dessen, was berührt wurde.

PSEXEC.EXE-A1A1A1A1.pf-Load-Liste:

\DEVICE\HARDDISKVOLUME2\USERS\PUBLIC\PSEXEC.EXE
\DEVICE\HARDDISKVOLUME2\USERS\PUBLIC\UPDATE.EXE
\DEVICE\HARDDISKVOLUME2\USERS\PUBLIC\PSEXEC.SYS

PsExec lud sich selbst, den Encryptor (was nahelegt, dass psexec verwendet wurde, um update.exe an andere Hosts zu schieben) und seinen eigenen Kernel-Treiber. Der Ausführungszähler von drei kombiniert mit der Load-Liste legt stark drei laterale Pushes des Encryptors nahe.

Die acht Zeitstempel verraten mir die Schleife

Für PSEXEC.EXE-A1A1A1A1.pf enthält das Array der acht Ausführungszeitstempel drei gültige Zeiten:

14:15:22
14:16:48
14:19:01

Das gibt mir den Rhythmus des Angriffs: ungefähr 90 Sekunden zwischen Lateral-Movement-Pushes. Auf FS01, dem Dateiserver, erwarte ich eine UPDATE.EXE-XXXXXXXX.pf zu finden, deren erste Ausführungszeit ungefähr 14:15:30 plus ein paar Sekunden ist, da psexec-Push bis zum Start des Encryptors schnell ist.

Im Prefetch-Verzeichnis von FS01 finde ich UPDATE.EXE-77AAFF12.pf (gleiche Hash-Bytes — gleicher Pfad, C:\Users\Public\update.exe, auch auf FS01) mit einer ersten Ausführungszeit von 14:15:34. Das bestätigt die Lateral-Bewegung.

Dasselbe update.exe taucht auf zwei weiteren Hosts auf, mit ersten Ausführungszeiten von 14:16:55 und 14:19:08. Jede liegt im Sekundenbereich des entsprechenden psexec-Pushes.

Ich habe jetzt, allein aus Prefetch, die vollständige Lateral-Movement-Timeline für den Encryptor über vier Hosts hinweg.

Was Prefetch mir nicht gab

Das Prefetch gab mir nicht die Befehlszeile für irgendeine dieser Ausführungen. Dafür brauche ich Sysmon EID 1, das auf zwei der fünf Hosts existierte. Daraus rekonstruiere ich die Argumente an PowerShell, den Parent-Prozess für update.exe und den Benutzerkontext.

Das Prefetch gab mir nicht das Netzwerkziel des C2-Kanals. back.hta und stg1.ps1 enthalten diese Information vermutlich, aber sie sind nicht im Prefetch — nur ihre Pfade. Wenn die Dateien auf der Festplatte überleben, parse ich sie. Wenn sie bereinigt wurden, schaue ich in RAM (falls ich ein Memory-Image erfasste), das Pagefile oder Browser-History nach Spuren der C2-Domain.

Das Prefetch gab mir nicht den tatsächlichen verschlüsselten Inhalt oder die Wiederherstellungsaussichten. Dafür brauche ich die MFT und das USN-Journal, um zu verstehen, welche Dateien in welcher Reihenfolge berührt wurden und ob VSCs überlebten. Die Load-Liste des Encryptors sagte mir, welche Verzeichnisse anvisiert wurden; die MFT und USN sagten mir, was mit den Dateien in diesen Verzeichnissen passierte.

Warum Prefetch das Rückgrat dieser Untersuchung war

EVTX war unvollständig. Der Angreifer hatte das Security-Log auf FS01 gelöscht (das 1102-Audit-Log-Cleared-Event war vorhanden, aber die relevanten 4688-Einträge waren weg). Sysmon war nicht überall ausgerollt. AmCache hatte Hashes für einige Binärdateien, aber nicht alle (einige wurden vor der Ausführung umbenannt, und AmCache assoziiert über Binärdatei-Metadaten auf Arten, die gelegentlich verfehlen).

Prefetch saß quer dazu. Es ist pro Maschine, es schreibt kontinuierlich und es war auf vier der fünf Hosts vollständig (ein Host war oft genug neu gestartet, dass die älteren .pf-Dateien herausgealtert waren, aber die jüngsten waren da). Das Acht-Zeitstempel-Array auf den .pf-Dateien des Encryptors, über Hosts hinweg quervergliechen, war das einzelne Artefakt, mit dem ich die Lateral-Movement-Timeline mit Sub-Minuten-Konfidenz aufbauen konnte.

Für den Bericht zitierte ich die Zeitstempel direkt. Die gegnerische IR-Firma, mit der wir arbeiteten, hatte eine EVTX-only-Timeline zitiert, der zwei der vier betroffenen Hosts fehlten (die, auf denen der Encryptor lief, aber das Security-Log gelöscht und Sysmon nicht vorhanden waren). Ihre Timeline war auf Arten unvollständig, die Prefetch korrigierte.

Das Muster in einem Absatz

Eine echte Intrusion erzeugt eine charakteristische Prefetch-Signatur: ein Cluster von Erst-Ausführungen von System-Utilities (Equation Editor, MSHTA, rundll32, nltest, whoami) in einem engen Zeitfenster, gefolgt von Erst-Ausführungen von Angreifer-Binärdateien aus benutzerschreibbaren Pfaden (\Users\Public\, \AppData\Local\Temp\, \ProgramData\), gefolgt von einer kleinen Anzahl von Ausführungen von Lateral-Movement-Tools (PsExec, WMIC, gelegentlich legitime Tools wie RDP-Clients), gefolgt vom Encryptor selbst. Die gesamte Sequenz passt üblicherweise in zwanzig bis neunzig Minuten. Das Prefetch-Acht-Zeitstempel-Array pro Host nagelt jeden Schritt auf Sekunden fest.

Wenn Sie das Prefetch-Verzeichnis eines getroffenen Hosts parsen und diese Signatur nicht sehen, schauen Sie entweder auf einen Host, der nicht tatsächlich kompromittiert wurde, oder der Angreifer war ausgefeilt genug, Prefetch zu bereinigen, in welchem Fall die Lösch-Rückstände in der MFT und dem USN-Journal der nächste Anlaufpunkt sind.

Wenn Sie den Workflow gegen Ihr eigenes Prefetch-Verzeichnis im Browser ausprobieren wollen, lädt der Parser auf dieser Seite .pf-Dateien lokal und gibt Ihnen die sortierbare Tabelle, von der der obige Workflow abhängt.

Weiterführende Literatur

Eric Zimmerman, PECmd — Bulk-Parsen eines Verzeichnisses in CSV, und der obige Workflow ergibt sich natürlich.
The DFIR Report, jährliche Fall-Aufschriebe — viele enthalten Prefetch-Belege, präsentiert in etwa der obigen Form.
Microsoft, Mitigating Ransomware — Verteidiger-Kontext, warum das wichtig ist.