pagefile.sys verschlüsseln: die Einstellung EncryptPagingFile und wogegen sie schützt

Windows wird seit jeher leise mit einem Feature ausgeliefert, das den Inhalt von pagefile.sys mit einem boot-spezifischen, ephemeren Schlüssel verschlüsselt. Es ist ein einzeiliger fsutil-Befehl, kostet zur Laufzeit praktisch nichts, und die meisten Verteidiger wissen nicht, dass es existiert.

Dieser Beitrag behandelt, was es tut, was nicht, wie es mit BitLocker interagiert und — für diese Seite relevant — wie es die forensische Pagefile-Analyse beeinflusst.

Die Einstellung

fsutil behavior set EncryptPagingFile 1

Nach einem Reboot wird jeder Schreibvorgang in pagefile.sys verschlüsselt. Konkret:

• Beim Boot wird ein 256-Bit-AES-Schlüssel erzeugt, im Non-Paged- Kernel-Speicher abgelegt und beim Shutdown zerstört.
• Der Memory Manager / Speichermanager übergibt Seiten an NTFS mit einer IV pro Schreibvorgang; NTFS verschlüsselt jede Seite per AES, bevor sie auf Disk landet.
• Der Schlüssel wird nie auf Disk geschrieben, nie exportiert und ist nicht wiederherstellbar — auch nicht durch den Benutzer, der die Einstellung gesetzt hat.

Auslesen:

fsutil behavior query EncryptPagingFile

0 heißt aus, 1 heißt an. Der Standard ist in den meisten Windows-Builds 0.

Wogegen sie schützt

Das Threat Model ist Offline-Disk-Zugriff, nachdem das System lief. Szenarien:

• Ein Laptop wird im ausgeschalteten Zustand gestohlen. Ein Disk-Image wird gezogen. Ohne EncryptPagingFile ist der Pagefile-Inhalt der letzten Session im Klartext lesbar (modulo NTFS-Journaling-normalem Verhalten). Mit eingeschaltetem EncryptPagingFile ist er AES-verschlüsselt mit einem Schlüssel, der nicht mehr existiert.
• Eine interne Disk wird im Rahmen einer Wartung aus einem Server ausgebaut und gespiegelt.
• Ein VM-Snapshot wird genommen, aber nicht der laufende RAM.

Beachten Sie das Konstante: Das System lief vorher, ist jetzt aus, und jemand liest hinterher die Disk. Die Verschlüsselung schützt gegen den nachträglichen Lesezugriff.

Wogegen sie nicht schützt

• Ein laufendes System, das erfasst wird. Der ephemere Schlüssel liegt im RAM. Ein Prozess mit Kernel-Zugriff (Wraith, DumpIt, WinPMem oder schlicht ein autorisierter Kernel-Debugger) kann den Schlüssel bergen und pagefile.sys live entschlüsseln.
• Eine Hibernation-Datei (hiberfil.sys). Hibernate schreibt das RAM auf Disk; wenn EncryptPagingFile an war, waren die Pagefile-Inhalte im RAM zum Zeitpunkt des Hibernate bereits verschlüsselt — der lebende Anwendungs-Speicher aber nicht. hiberfil.sys ist daher auf einem Laptop, der häufig den Deckel schließt (= hibernated), die größere Leak-Surface. Gegenmaßnahme: BitLocker, das das Volume verschlüsselt, auf dem hiberfil.sys liegt.
• Ein Crash-Dump (MEMORY.DMP). Gleiche Situation — RAM-Inhalte, nicht pagefile-verschlüsselt.
• Eine Swap-Partition unter Linux-Dual-Boot. EncryptPagingFile ist ein reines Windows-NTFS-Feature.

Zusammenspiel mit BitLocker

BitLocker verschlüsselt das gesamte Volume, also auch pagefile.sys. Man könnte sich fragen, warum man EncryptPagingFile zusätzlich haben will. Die Begründung:

Die zentrale Erkenntnis: EncryptPagingFile überlebt eine BitLocker- Kompromittierung, weil sein Schlüssel niemals die Disk berührt. Für sicherheitssensible Systeme nutzen Sie beides. Der Laufzeit-Overhead ist auf moderner Hardware mit AES-NI vernachlässigbar (NTFS macht AES inline).

Performance-Kosten

In der Praxis nichts Messbares auf Hardware der letzten 10 Jahre. AES-NI gibt es auf jeder CPU seit Westmere (2010). Das Pagefile ist auf Systemen mit ausreichend RAM kein Hot-Path-Workload.

Wenn Sie messbare Performance-Einbrüche sehen, ist das eigentliche Problem, dass Sie zu viel pagen — nicht die Verschlüsselung. Beheben Sie die RAM-Auslegung.

Was das für die forensische Analyse bedeutet

Dieser Teil ist direkt relevant für diese Seite.

Wenn Sie als Analyst ein Offline-Disk-Image mit gesetztem EncryptPagingFile = 1 erhalten:

• Das Pagefile ist nicht rekonstruierbar. Der Schlüssel ist weg. Die Carving-Techniken, die dieser Parser implementiert, schlagen alle fehl — die Bytes sehen aus wie zufälliges High-Entropy-Rauschen.
• Sie sehen im Tab Page map überwiegend high_entropy. Das ist die Signatur sauber verschlüsselter Seiten.
• Stattdessen tun: auf andere Quellen pivotieren — RAM-Dump, falls vorhanden, hiberfil.sys (das nicht pagefile-verschlüsselt ist), MEMORY.DMP, das lebende lsass.exe bei noch laufendem System, EDR-Telemetrie, Netzwerk-Flow-Logs.

Wenn Sie das laufende System haben, vor dem Herunterfahren:

• Zuerst RAM erfassen. Der Pagefile-Schlüssel lebt darin.
• Dann das Pagefile erfassen, während der Kernel noch läuft — über Roh-NTFS-Lesen erhalten Sie die entschlüsselte Sicht.

Wenn Sie zum Hardening beraten:

• EncryptPagingFile = 1 für Laptops und alle Systeme empfehlen, die ihre physische Obhut verlassen könnten.
• Mit BitLocker kombinieren.
• Pagefile nicht komplett deaktivieren; Sie verlieren Crash-Dumps und die Modified-Page-List-Optimierung. Siehe Sollten Sie pagefile.sys löschen?.

Wie man verifiziert, dass es tatsächlich greift

Nach dem Setzen und Reboot lässt sich das über die Entropie des Dateiinhalts bestätigen. Nutzen Sie diesen Parser auf einem kleinen gesicherten Sample oder ent pagefile.sys auf der Kommandozeile:

ent pagefile.sys
Entropy = 7.99 bits per byte.

7,99 / 8 bedeutet im Wesentlichen Zufall — das, was man von AES-Output erwartet. Ein nicht verschlüsseltes Pagefile erreicht typischerweise 6,5–7,5, dank seines hohen Anteils an strukturierten (niederentropischen) Bereichen und Null-Füllungen.

Sie können auch von einem forensischen Linux-USB-Stick booten und die Datei greppen:

strings -a pagefile.sys | head

Mit EncryptPagingFile = 1 sehen Sie im Grunde keine englischsprachigen Strings. Ohne sehen Sie eine Flut — URLs, Befehlszeilen, Dateipfade, das ganze Programm.

Warum ist es nicht standardmäßig an?

Microsofts Antwort lautet sinngemäß „Kompatibilität und Crash-Dump-Brauchbarkeit":

• Ein Pagefile, das mit einem ephemeren Schlüssel verschlüsselt ist, erschwert Kernel-Debugging.
• MEMORY.DMP wird zum Crash-Zeitpunkt durch das Pagefile geschrieben, und historisch gab es Edge-Cases, in denen der Dump-Writer mit verschlüsseltem Pagefile Probleme hatte.
• Die Einstellung ist pro Maschine und erfordert einen Reboot.

Für die meisten Enterprise-Endpoints wiegen diese Gründe den Sicherheitsgewinn nicht auf — ein Aktivieren über GPO ist eine gute Idee.

Group Policy

Dieselbe Einstellung ist verfügbar unter:

Computerkonfiguration → Administrative Vorlagen → System → Dateisystem → NTFS → „Verschlüsselung für die Auslagerungsdatei konfigurieren"

…oder direkt als Registry-Wert:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
    EncryptPagingFile (REG_DWORD) = 1

Verwandt

• Sollten Sie pagefile.sys löschen oder deaktivieren? — die Alternative.
• Anmeldedaten in pagefile.sys finden — warum man es verschlüsseln will.
• Grenzen der pagefile.sys-Analyse — inklusive dessen, wie ein verschlüsseltes Pagefile aus Sicht eines Carvers aussieht.