Cifrando pagefile.sys: el ajuste EncryptPagingFile y contra qué protege
20/5/2026 · 6 min de lectura
Windows viene en silencio con una funcionalidad que cifra el
contenido de pagefile.sys con una clave efímera por arranque. Es un
comando fsutil de una sola línea, prácticamente no cuesta nada en
tiempo de ejecución, y la mayoría de defensores no saben que existe.
Este post cubre qué hace, qué no hace, cómo interactúa con BitLocker y — relevante para este sitio — cómo afecta al análisis forense del pagefile.
El ajuste
fsutil behavior set EncryptPagingFile 1
Tras un reinicio, cada escritura en pagefile.sys queda cifrada. En
concreto:
- Se genera una clave AES de 256 bits en el arranque, se guarda en memoria no-paginada del kernel y se destruye al apagar.
- El Memory Manager / gestor de memoria entrega las páginas a NTFS con un IV por escritura; NTFS cifra con AES cada página antes de que aterrice en disco.
- La clave nunca se escribe en disco, nunca se exporta y no es recuperable — ni siquiera por el usuario que activó el ajuste.
Léelo:
fsutil behavior query EncryptPagingFile
0 significa desactivado, 1 significa activado. El valor por defecto
es 0 en la mayoría de los builds de Windows.
Contra qué protege esto
El modelo de amenazas es acceso al disco sin conexión / apagado tras que el sistema estuvo ejecutándose. Escenarios:
- Un portátil es robado mientras está apagado. Se toma una imagen
del disco. Sin
EncryptPagingFile, el contenido del pagefile de la última sesión es legible en claro (módulo el comportamiento normal del journaling de NTFS). Con él, está cifrado con AES con una clave que ya no existe. - Un disco interno se retira de un servidor durante mantenimiento y se imagina.
- Se captura un snapshot de VM pero no la RAM en ejecución.
Nota la constante: el sistema estuvo ejecutándose antes, ahora está apagado, y alguien está leyendo el disco a posteriori. El cifrado protege la lectura posterior.
Contra qué no protege
- Una adquisición de sistema en ejecución. La clave efímera está en RAM. Un proceso con acceso al kernel (Wraith, DumpIt, WinPMem, o simplemente un kernel debugger autorizado) puede recuperar la clave y descifrar pagefile.sys sobre la marcha.
- Un archivo de hibernación (
hiberfil.sys). Hibernar escribe la RAM en disco; siEncryptPagingFileestaba activo, los contenidos del pagefile en RAM en el momento de la hibernación ya estaban cifrados tras la escritura — pero la memoria viva de las aplicaciones no lo estaba.hiberfil.syses, por tanto, la mayor superficie de fuga en un portátil al que se le cierra la tapa (= hiberna) frecuentemente. Mitigación: BitLocker, que cifra el volumen donde vivehiberfil.sys. - Un crash dump (
MEMORY.DMP). Misma situación — contenido de RAM, no cifrado por el pagefile. - Una partición de swap en dual-boot con Linux.
EncryptPagingFilees una funcionalidad solo de Windows NTFS.
Interacción con BitLocker
BitLocker cifra el volumen entero, lo que incluye pagefile.sys.
Te puedes preguntar entonces por qué querer EncryptPagingFile encima.
El razonamiento:
| Escenario | BitLocker solo | + EncryptPagingFile |
|---|---|---|
| Disco imaginado tras apagado limpio | ❌ protegido | ✅ doblemente protegido |
| Disco imaginado con el sistema vivo | 🟡 (TPM unsealed) | ✅ pagefile aún a salvo |
| Clave de recuperación de BitLocker comprometida | 🔴 expuesto | ✅ pagefile aún a salvo |
MEMORY.DMP extraído del disco | 🟡 | 🟡 (no es pagefile) |
La idea clave: EncryptPagingFile sobrevive a un compromiso de
BitLocker porque su clave nunca toca disco. Para sistemas sensibles
en seguridad, usa ambos. El coste de runtime es despreciable (NTFS
hace el AES inline en hardware moderno que tiene AES-NI).
Coste de rendimiento
En la práctica, ninguno digno de medir en hardware de los últimos 10 años. AES-NI está en cada CPU desde Westmere (2010). El pagefile no es una carga de trabajo de hot-path en sistemas con RAM adecuada.
Si ves pérdida de rendimiento medible, el problema real es que estás paginando demasiado, no el cifrado — arregla el aprovisionamiento de RAM.
Qué implica para el análisis forense
Esta es la parte directamente relevante para este sitio.
Si eres un analista al que le entregan una imagen de disco apagada con
EncryptPagingFile = 1 puesto:
- El pagefile es irrecuperable. La clave ya no existe. Las técnicas de carving que este parser implementa fallan todas — los bytes parecen ruido aleatorio de alta entropía.
- Verás
high_entropydominar la pestaña Page map. Esa es la firma de páginas correctamente cifradas. - Qué hacer en su lugar: pivota a otras fuentes — dump de RAM si
tienes uno,
hiberfil.sys(que no está cifrado por el pagefile),MEMORY.DMP, ellsass.exevivo si el sistema sigue arriba, telemetría EDR, logs de flujo de red.
Si tienes el sistema vivo, antes de apagarlo:
- Adquiere la RAM primero. La clave del pagefile vive ahí.
- Luego adquiere el pagefile mientras el kernel siga arriba — obtendrás la vista descifrada vía lectura NTFS en bruto.
Si estás asesorando sobre bastionado:
- Recomienda
EncryptPagingFile = 1para portátiles y cualquier sistema que pueda salir de la custodia física. - Combínalo con BitLocker.
- No desactives el pagefile por completo; perderás crash dumps y la optimización de la lista de páginas modificadas. Ver ¿deberías borrar pagefile.sys?.
Cómo verificar que funciona de verdad
Tras configurarlo y reiniciar, puedes confirmar mirando la entropía del
contenido del archivo. Usa este parser sobre una pequeña muestra
capturada, o ent pagefile.sys desde la línea de comandos:
ent pagefile.sys
Entropy = 7.99 bits per byte.
7,99 / 8 significa esencialmente aleatorio — lo que esperarías de la salida de AES. Un pagefile no cifrado típicamente puntúa 6,5–7,5 gracias a su alta proporción de regiones estructuradas (baja entropía) y relleno con ceros.
También puedes arrancar desde un USB forense de Linux e intentar grepear el archivo:
strings -a pagefile.sys | head
Con EncryptPagingFile = 1, no verás esencialmente ninguna cadena en
inglés. Sin él, verás una avalancha — URLs, líneas de comandos, rutas
de archivos, lo que sea.
¿Por qué no está activo por defecto?
La respuesta de Microsoft es aproximadamente "compatibilidad y usabilidad del crash dump":
- Un pagefile cifrado con una clave efímera complica el debugging del kernel.
MEMORY.DMPse escribe a través del pagefile en el momento del crash, y existen casos límite históricos en los que el dump writer ha tenido problemas con pagefile cifrado.- El ajuste es por máquina y requiere reinicio.
Para la mayoría de endpoints empresariales, ninguna de estas razones supera el beneficio de seguridad — activarlo vía GPO es buena idea.
Group Policy
El mismo ajuste se expone vía:
Configuración del equipo → Plantillas administrativas → Sistema → Sistema de archivos → NTFS → "Configurar cifrado para el archivo de paginación"
…o directamente como el valor de registro:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
EncryptPagingFile (REG_DWORD) = 1
Relacionado
- ¿Deberías borrar o desactivar pagefile.sys? — la alternativa.
- Encontrar credenciales en pagefile.sys — por qué querrías cifrarlo.
- Limitaciones del análisis de pagefile.sys — incluyendo qué pinta tiene un pagefile cifrado para un carver.