Chiffrer pagefile.sys : le réglage EncryptPagingFile et ce contre quoi il protège
20/05/2026 · 6 min de lecture
Windows embarque discrètement une fonctionnalité qui chiffre le
contenu de pagefile.sys avec une clé éphémère par démarrage. C'est
une commande fsutil d'une ligne, le coût à l'exécution est quasi nul,
et la plupart des défenseurs ignorent son existence.
Ce billet couvre ce qu'elle fait, ce qu'elle ne fait pas, comment elle interagit avec BitLocker, et — pertinent pour ce site — comment elle affecte l'analyse forensique du pagefile.
Le réglage
fsutil behavior set EncryptPagingFile 1
Après un redémarrage, chaque écriture dans pagefile.sys est chiffrée.
Concrètement :
- Une clé AES 256 bits est générée au démarrage, stockée en mémoire noyau non paginée, et détruite à l'extinction.
- Le gestionnaire de mémoire fournit les pages à NTFS avec un IV par écriture ; NTFS chiffre chaque page en AES avant qu'elle n'atterrisse sur disque.
- La clé n'est jamais écrite sur disque, jamais exportée, et irrécupérable — y compris pour l'utilisateur qui a activé le réglage.
Le relire :
fsutil behavior query EncryptPagingFile
0 signifie désactivé, 1 activé. Par défaut, 0 sur la plupart des
builds Windows.
Ce contre quoi cela protège
Le modèle de menace est l'accès disque hors-ligne après que le système ait tourné. Scénarios :
- Un laptop est volé éteint. Une image disque est prise. Sans
EncryptPagingFile, le contenu du pagefile de la dernière session est lisible en clair (modulo le comportement normal du journal NTFS). Avec, il est chiffré en AES avec une clé qui n'existe plus. - Un disque interne est retiré d'un serveur pendant une maintenance et imagé.
- Un snapshot de VM est capturé sans la RAM active.
Notez la constante : le système tournait précédemment, puis est éteint, et quelqu'un lit le disque après coup. Le chiffrement protège contre la lecture a posteriori.
Ce contre quoi cela ne protège pas
- Un système actif acquis. La clé éphémère est en RAM. Un processus avec accès noyau (Wraith, DumpIt, WinPMem, ou simplement un debugger noyau autorisé) peut récupérer la clé et déchiffrer pagefile.sys à la volée.
- Un fichier d'hibernation (
hiberfil.sys). L'hibernation écrit la RAM sur disque ; siEncryptPagingFileétait activé, le contenu du pagefile en RAM au moment de l'hibernation avait déjà été chiffré-après-écriture — mais la mémoire applicative vivante ne l'était pas.hiberfil.sysest donc la plus grosse surface de fuite sur un laptop dont le capot se ferme (= hibernation) souvent. Atténuation : BitLocker, qui chiffre le volume sur lequel vithiberfil.sys. - Un dump de crash (
MEMORY.DMP). Même situation — contenu RAM, pas chiffré-pagefile. - Une partition swap sur Linux en dual-boot.
EncryptPagingFileest une fonctionnalité NTFS de Windows uniquement.
Interaction avec BitLocker
BitLocker chiffre le volume entier, ce qui inclut pagefile.sys.
Vous pourriez donc vous demander pourquoi EncryptPagingFile par
dessus. Le raisonnement :
| Scénario | BitLocker seul | + EncryptPagingFile |
|---|---|---|
| Disque imagé après arrêt propre | ❌ protégé | ✅ doublement protégé |
| Disque imagé pendant que le système tourne | 🟡 (TPM descellé) | ✅ pagefile toujours sûr |
| Clé de récupération BitLocker compromise | 🔴 exposé | ✅ pagefile toujours sûr |
MEMORY.DMP extrait du disque | 🟡 | 🟡 (pas du pagefile) |
L'idée clé : EncryptPagingFile survit à une compromission BitLocker
parce que sa clé ne touche jamais le disque. Pour les systèmes
sensibles, utilisez les deux. Le coût à l'exécution est négligeable
(NTFS fait l'AES inline sur du matériel moderne avec AES-NI).
Coût de performance
En pratique, rien de mesurable sur du matériel des 10 dernières années. AES-NI est présent sur tous les CPU depuis Westmere (2010). Le pagefile n'est pas une charge sur le chemin critique pour des systèmes avec assez de RAM.
Si vous voyez une perte de performance mesurable, le vrai problème est que vous paginez trop, pas le chiffrement — corrigez le dimensionnement RAM.
Ce que cela implique pour l'analyse forensique
C'est la partie directement pertinente pour ce site.
Si vous êtes un analyste à qui l'on remet une image disque hors-ligne
avec EncryptPagingFile = 1 :
- Le pagefile est irrécupérable. La clé n'existe plus. Les techniques de carving qu'implémente ce parser échouent toutes — les octets ressemblent à du bruit aléatoire haute entropie.
- Vous verrez
high_entropydominer l'onglet Page map. C'est la signature de pages correctement chiffrées. - Que faire à la place : pivotez vers d'autres sources — un dump
RAM si vous en avez un,
hiberfil.sys(qui n'est pas chiffré par le pagefile),MEMORY.DMP, lelsass.exevivant si le système est encore debout, la télémétrie EDR, les journaux de flux réseau.
Si vous avez le système actif, avant de l'éteindre :
- Acquérez la RAM d'abord. La clé du pagefile y vit.
- Puis acquérez le pagefile pendant que le noyau est encore debout — vous obtiendrez la vue déchiffrée via une lecture NTFS brute.
Si vous conseillez sur le durcissement :
- Recommandez
EncryptPagingFile = 1pour les laptops et tout système susceptible de quitter sa garde physique. - Combinez avec BitLocker.
- Ne désactivez pas entièrement le pagefile ; vous perdez les dumps de crash et l'optimisation de la modified-page list. Voir faut-il supprimer pagefile.sys.
Comment vérifier que ça fonctionne vraiment
Après activation et redémarrage, vous pouvez confirmer en regardant
l'entropie du contenu du fichier. Utilisez ce parser sur un petit
échantillon capturé, ou ent pagefile.sys en ligne de commande :
ent pagefile.sys
Entropy = 7.99 bits per byte.
7,99 / 8 signifie essentiellement aléatoire — ce à quoi on s'attend en sortie d'AES. Un pagefile non chiffré donne typiquement 6,5–7,5 grâce à sa forte proportion de régions structurées (basse entropie) et de remplissage à zéro.
Vous pouvez aussi démarrer depuis une clé USB Linux forensique et tenter de grepper le fichier :
strings -a pagefile.sys | head
Avec EncryptPagingFile = 1, vous ne verrez quasiment aucune chaîne
lisible. Sans, vous en verrez un flot — URL, lignes de commande,
chemins de fichiers, tout.
Pourquoi n'est-ce pas activé par défaut ?
La réponse de Microsoft tient en gros à « compatibilité et exploitabilité des dumps de crash » :
- Un pagefile chiffré avec une clé éphémère complique le débogage noyau.
MEMORY.DMPest écrit à travers le pagefile au moment du crash, et il existe historiquement des cas limites où l'écrivain de dump avait des soucis avec le pagefile chiffré.- Le réglage est par machine et requiert un redémarrage.
Pour la plupart des endpoints d'entreprise, aucune de ces raisons ne l'emporte sur le bénéfice sécurité — l'activer via une GPO est une bonne idée.
Group Policy
Le même réglage est exposé via :
Configuration ordinateur → Modèles d'administration → Système → Système de fichiers → NTFS → « Configurer le chiffrement du fichier d'échange »
… ou directement via la valeur de registre :
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
EncryptPagingFile (REG_DWORD) = 1
Liens connexes
- Faut-il supprimer ou désactiver pagefile.sys ? — l'alternative.
- Trouver des identifiants dans pagefile.sys — pourquoi vouloir le chiffrer.
- Limites de l'analyse de pagefile.sys — y compris à quoi ressemble un pagefile chiffré pour un carver.