Aller au contenu
Pagefile.sys Parser
← Retour au blog

Trouver des identifiants dans pagefile.sys

20/05/2026 · 6 min de lecture

pagefile.sys est notoirement un endroit où finissent en clair des identifiants qui n'auraient jamais dû y atterrir. Les logiciels manipulent des secrets en mémoire toute la journée : les clients HTTP construisent des en-têtes Authorization, les navigateurs déchiffrent à la demande les mots de passe enregistrés, les bibliothèques de bases de données assemblent des chaînes de connexion, les agents SSH conservent le matériel cryptographique, les flux OAuth font circuler des jetons bearer. Le noyau n'a aucune idée de quelles plages mémoire sont sensibles — si bien que lorsque la pression mémoire choisit une page froide, cette page peut atterrir sur disque, en clair.

Ce billet passe en revue les formes d'identifiants les plus utiles à rechercher dans un pagefile capturé, et la manière dont cet outil les fait remonter.

Pourquoi cela arrive

Le gestionnaire de mémoire Windows ignore ce que contient une page — il sait seulement à quel point elle est froide. La mémoire d'un processus moderne contient :

  • Des tampons de requêtes/réponses HTTP avec des en-têtes Authorization en clair.
  • Des onglets WebView / Chrome / Edge qui déchiffrent les mots de passe enregistrés en RAM lors de l'auto-remplissage d'un formulaire.
  • Des bibliothèques clientes de bases de données qui construisent des chaînes de connexion Server=…;Password=….
  • Des JWT mis en cache dans des tas JS (onglets de navigateurs, apps Electron, Teams, Slack).
  • Le working set de lsass.exe — quand les pages de LSASS refroidissent, on peut récupérer des fragments contenant des hashes NTLM, des tickets Kerberos, des secrets LSA.
  • Les outils CLI : AWS CLI, gcloud, az, kubectl gardent tous en mémoire des credentials récemment émis.

La plupart de ces composants n'écrivent jamais le secret dans un fichier de manière intentionnelle — mais ils n'ont aucune protection contre le fait que le système d'exploitation swappe la page dans laquelle le secret réside. pagefile.sys devient alors une copie persistante, sur disque, de « ce qui était chaud en RAM mais ne l'est plus tout à fait ».

Ce qu'il faut chercher

Les balayages regex d'artefacts de ce parser incluent une catégorie « credentials », mais voici les formes de recherche les plus productives si vous parcourez un export de chaînes à la main.

Champs de mot de passe en clair

password=
pwd=
passwd=
PASSWORD=
Pwd=

Souvent à l'intérieur de chaînes de connexion :

Server=db01;Database=app;User Id=app_rw;Password=hunter2;

… ou dans des corps de formulaires HTTP :

username=admin&password=hunter2&csrf=…

En-têtes HTTP Authorization

Authorization: Basic dXNlcjpwYXNzd29yZA==
Authorization: Bearer eyJ…
Authorization: Negotiate YIIE…

La forme Basic se décode (base64) en user:password. Le Bearer est en général un jeton opaque ou un JWT.

JWT

Trois segments base64url séparés par des points, commençant par eyJ :

eyJhbGciOiJSUzI1NiIsImtpZCI6Ii4uLiJ9.eyJzdWIiOiI...".dHJ1c3RtZQ

Le premier segment se décode en l'en-tête (alg, kid), le second en les claims (sub, iss, aud, exp, …). Tout ce qui est encore dans sa fenêtre exp est potentiellement exploitable.

NTLM et Kerberos

  • Messages NTLMSSP : cherchez le magique NTLMSSP\0 (4E 54 4C 4D 53 53 50 00).
  • Les challenges de type 2 contiennent le nonce de challenge serveur ; les réponses de type 3 contiennent le matériel de hash Net-NTLMv1/v2 cassable hors-ligne avec hashcat (-m 5500 / -m 5600).
  • Tickets Kerberos : de gros blobs binaires à proximité des chaînes krbtgt, LSA Kerberos, ou des noms principaux de service (HTTP/host, MSSQLSvc/host, …). Extraire des tickets complets depuis un pagefile est plus difficile qu'à partir d'une RAM, mais du matériel Kerberos TGT/TGS y survit parfois.

Secrets LSA et Domain Cached Credentials

lsass.exe conserve du matériel secret en mémoire. Quand les pages de LSASS sont assez froides pour être évincées, des fragments apparaissent — notamment :

  • DCC2 (MS-Cache v2) : hashes de 16 octets à proximité des chaînes NL$KM / _SC_.
  • Mots de passe de comptes de service en clair si LsaCfgFlags n'est pas positionné.

Le décodage complet exige un outil spécialisé (mimikatz / pypykatz sur une image mémoire), mais les fragments bruts sont trouvables ici.

Matériel de clés SSH et PGP

Les clés privées OpenSSH en mémoire commencent par -----BEGIN OPENSSH PRIVATE KEY----- ou -----BEGIN RSA PRIVATE KEY-----. Idem pour les clés secrètes PGP (-----BEGIN PGP PRIVATE KEY BLOCK-----). Quand l'agent a la clé déverrouillée, elle vit en mémoire jusqu'à effacement — donc elle peut paginer.

Jetons des CLI cloud

  • AWS : aws_access_key_id, aws_secret_access_key, aws_session_token, jetons STS (souvent en forme de JWT).
  • GCP : jetons mis en cache par gcloud auth (access_token, refresh tokens), souvent en JSON.
  • Azure : jetons mis en cache par Az.Accounts ; formes MSAL.Token.
  • Kubernetes : JWT de comptes de service (eyJhbGciOiJSUzI1NiIsImtpZCI…).

Artefacts de clients de bases de données

  • Chaînes de connexion ODBC / OLEDB : Provider=…;Data Source=…;User ID=…;Password=…;.
  • Les arguments sqlcmd -P, mysql -p survivent sur la ligne de commande — voir la section sur les lignes de commande malveillantes pour des motifs apparentés.

Mots de passe enregistrés des navigateurs

Chrome / Edge / Brave stockent les mots de passe enregistrés chiffrés via DPAPI, mais ils les déchiffrent à l'auto-remplissage et la version en clair vit brièvement dans le tas du renderer. Un pagefile capturé peu après une session de navigation peut contenir ces formulaires déchiffrés.

Comment cet outil les met en avant

L'onglet Artifacts → Credential indicators du parser matche :

  • password= / pwd= / passwd= dans n'importe quelle chaîne.
  • Les en-têtes Authorization: Bearer … et Authorization: Basic ….
  • Les jetons en forme de JWT (trois segments base64url séparés par des points, commençant par eyJ).

L'onglet Strings est le fourre-tout — utilisez le champ de filtre pour chercher Authorization, NTLMSSP, BEGIN OPENSSH, aws_secret, Bearer, etc.

Tout ce qui est manifestement un blob binaire (octets de challenge NTLM, tickets Kerberos) n'apparaîtra pas comme chaîne mais sera signalé par le bucket haute entropie dans la carte des pages — c'est là qu'il faut regarder ensuite.

Notes opérationnelles

  • Le temps compte. Plus un système tourne longtemps après le chargement d'un credential, plus la page risque d'être écrasée par du contenu paginé plus récent. Acquérez le pagefile dès que vous soupçonnez une compromission.
  • Un dump RAM apparié est multiplicativement plus utile pour la chasse aux credentials — il vous donne le LSASS vivant, le cache Kerberos complet, et des secrets rattachables à un processus. Le billet sur les limites explique pourquoi.
  • Ne redémarrez pas l'hôte suspect avant d'avoir récupéré pagefile.sys — Windows peut écraser les emplacements paginés au prochain démarrage. Si vous devez absolument le faire, capturez d'abord.
  • hiberfil.sys est encore meilleur pour la récupération de credentials quand il est présent — c'est un snapshot RAM complet. Voir le billet comparatif.

Rappel légal / éthique

N'analysez de pagefiles que sur des systèmes pour lesquels vous êtes autorisé à enquêter. Des identifiants en clair extraits de la machine d'autrui restent des identifiants, et les utiliser hors du périmètre de la mission constitue une infraction distincte à part entière.