Volatility + pagefile.sys: beides zusammen für vollständige Memory-Forensik

Volatility (und sein neueres Geschwister MemProcFS) sind die Standardwerkzeuge für Windows-Memory-Forensik. Die meisten Analysten setzen sie allein gegen einen RAM-Dump ein. Was dabei untergeht, ist, dass beide pagefile.sys lesen können, wenn man es ihnen übergibt — und das erweitert dramatisch, was sich rekonstruieren lässt.

Warum Volatility das Pagefile nicht allein nutzen kann

Volatilitys Aufgabe ist es, die Kernel-Datenstrukturen eines erfassten Memory-Image zu durchlaufen: EPROCESS-Listen, Page Table Entries (PTEs), Kernel-Pools, Netzwerkpuffer. All das lebt im RAM — nichts davon steht im Pagefile.

Ein Pagefile für sich ist lediglich Inhalt: rohe 4-KB-Speicherframes ohne Zuordnung. Volatility weiß nicht, welcher Slot zu welchem Prozess gehört, zu welcher virtuellen Adresse oder auch nur, um welche Art Speicher (Heap, Stack, Mapped File) es sich handelt.

Genau deshalb verfolgen Standalone-Tools wie dieser Parser einen Carving-Ansatz — sie betrachten den Inhalt allein über Magic-Byte-Signaturen. Siehe den Limitations-Beitrag für die vollständige Erläuterung.

Was sich ändert, wenn man beides hat

Wenn Sie Volatility einen RAM-Dump und das zugehörige Pagefile geben, kann es:

1. PTEs im RAM durchlaufen, um zu ermitteln, welcher Prozess und welche virtuelle Adresse zu jedem Pagefile-Slot gehören.
2. Ausgelagerte Seiten on demand lesen während der Plugin- Ausführung — sodass ein Process-Scan, ein pslist, ein cmdline, ein vadinfo, ein dumpfiles den vollständigen Inhalt auch für Speicherbereiche bekommt, die ausgelagert waren.
3. Plugins ausführen, die vorher gescheitert oder unvollständig waren: pstree, cmdline, dlllist, handles, consoles, cmdscan — sie werden alle vollständig.

Im Effekt wird das Pagefile als Backing Store für das Memory-Image gemountet.

Volatility-3-Syntax

# Ohne Pagefile (ausgelagerter Inhalt fehlt)
vol -f memory.dmp windows.pslist

# Mit Pagefile (ausgelagerter Inhalt wird nachgeladen)
vol -f memory.dmp \
    --layer "Stacker.layer0:PageFile=pagefile.sys" \
    windows.pslist

Die --layer-Syntax erlaubt es, einen PagefileLayer über den physischen Memory-Layer zu stapeln; Volatilitys Übersetzung fällt durch ihn hindurch, wenn ein PTE das Pagefile-Bit gesetzt hat.

Hinweis: Das exakte CLI zum Stacken von Pagefile-Layern hat sich über die Minor-Versionen von Volatility 3 weiterentwickelt; prüfen Sie vol --help und das -h für windows.info auf Ihrem Build.

Volatility-2-Syntax

Legacy, aber immer noch stark im Einsatz:

vol.py -f memory.dmp --profile=Win10x64_19041 \
    --pagefile pagefile.sys \
    pslist

Das --pagefile-Flag funktioniert für die meisten Win64-/Win10-Profile. Für ältere Profile wird das Flag eventuell nicht unterstützt.

MemProcFS-Syntax

MemProcFS exponiert die Analyseoberfläche als virtuelles Dateisystem, in das man cd-en kann:

MemProcFS.exe -device memory.dmp -pagefile0 pagefile.sys

Der Parameter pagefile0 nimmt einen Pfad entgegen; pagefile1, pagefile2, … lassen sich für weitere Pagefiles nutzen (Multi-Volume- Server).

Einmal gemountet liefern Pfade wie:

M:\pid\1234\virt2phys.txt
M:\pid\1234\memory.vmem
M:\pid\1234\modules\…

…Inhalte mit transparent aus dem Pagefile nachgeladenen, eingeblendeten Daten.

Wann welches Tool

Eine vollständige IR-Triage nutzt meist alle drei: RAM-Capture für die Live-Analyse, Pagefile für ausgelagerten Inhalt und einen Strings-Sweep für die schnellen IOCs.

Praktischer Workflow

Ein vernünftiger End-to-End-Workflow auf einem Windows-Host:

1. RAM erfassen (DumpIt, WinPMem, Magnet RAM Capture).
2. pagefile.sys erfassen (siehe den eigenen Beitrag).
3. hiberfil.sys erfassen, falls vorhanden (warum) — es ist ein reichhaltigeres zweites Memory-Image.
4. Herunterfahren, Disk imagen.
5. Erster Durchgang: Pagefile in diesen Parser werfen für einen schnellen IOC-Sweep — URLs, IPs, Befehlszeilen, Anmeldedaten. Das ist der schnellste Weg zur Frage „ist hier irgendetwas offensichtlich böses drin?".
6. Zweiter Durchgang: MemProcFS mit RAM-Dump + Pagefile laufen lassen. Prozesse durchlaufen, LSASS dumpen, Netzwerkverbindungen prüfen, Treiber inspizieren.
7. Dritter Durchgang: Volatility-3-Plugins für alles, was MemProcFS nicht abdeckt (Custom Plugins, malware-familien-spezifische Extraktoren).
8. Querverweise gecarvter Funde gegen EDR-/Sysmon-/EVTX-Logs für die zeitliche Verankerung.

Was, wenn Sie nur das Pagefile haben?

Häufig in Fällen, in denen ein Live-Capture nicht möglich war (System gesperrt, BitLocker ohne Recovery Key, Angreifer hat bereits heruntergefahren etc.):

• Volatility / MemProcFS sind ohne korrespondierendes RAM-Image weitgehend nutzlos.
• Dieser Parser ist Ihr Werkzeug. Carving + Strings + Artefakte liefern das stärkste aus dem Pagefile allein erreichbare Signal.
• Die Qualität der Rekonstruktion ist content-only, kein Kontext — siehe die Limitations.

Was, wenn Sie nur den RAM-Dump haben?

Häufig in Cloud-/VM-Forensik, wo das Pagefile auf dem Hypervisor-Volume liegt und nicht ohne Weiteres zugänglich ist:

• Volatility / MemProcFS funktionieren, aber jede ausgelagerte Adresse gibt Null zurück.
• Einige Plugins schlagen teilweise fehl; andere sind unbeeinflusst (alles, was nur Non-Paged-Kernel-Pools berührt).
• Das Pagefile ist die Ergänzung, die aus einem partiellen Memory-Image ein vollständiges macht.

Crash-Dumps als Hybrid

MEMORY.DMP aus einem Kernel-Crash ist strukturell einem RAM-Dump ähnlich, und Volatility liest ihn nativ (--profile=… plus die Datei). Er enthält keinen Pagefile-Inhalt. Paaren Sie ihn auf dieselbe Weise mit pagefile.sys, wie Sie es bei einem Live-Capture tun würden.

Verwandt

• Wie man pagefile.sys sichert — die Datei überhaupt erst beschaffen.
• pagefile.sys vs. hiberfil.sys vs. swapfile.sys — was in welcher Datei steckt und wann zuzugreifen ist.
• Grenzen der pagefile.sys-Analyse — warum Standalone-Pagefile + Volatility-allein jeweils nur das halbe Bild sind.