Finding credentials in pagefile.sys

pagefile.sys is famously a place where plaintext credentials end up that were never supposed to. Software handles secrets in memory all day: HTTP clients build Authorization headers, browsers decrypt saved passwords on demand, database libraries assemble connection strings, SSH agents hold key material, OAuth flows shuffle bearer tokens. The kernel has no idea which of those memory ranges are sensitive — so when memory pressure picks a cold page, that page might land on disk, in the clear.

This post walks through the credential shapes most worth searching for in a captured pagefile, and how this tool surfaces them.

Why it happens

The Windows Memory Manager doesn't know what's in a page — only how cold it is. Modern process memory holds:

HTTP request/response buffers with Authorization headers in plain text.
WebView / Chrome / Edge tabs that decrypt saved passwords into RAM while autofilling a form.
Database client libraries that construct Server=…;Password=… connection strings.
JWTs cached in JS heaps (browser tabs, Electron apps, Teams, Slack).
lsass.exe working set — when LSASS pages cool, you can get fragments containing NTLM hashes, Kerberos tickets, LSA secrets.
CLI tools: AWS CLI, gcloud, az, kubectl all keep recently-issued credentials in memory.

Most of these never write the secret to a file by design — but they have no protection against the OS swapping the page they happen to live in. pagefile.sys is then a long-lived on-disk copy of "what was hot in RAM but isn't quite hot enough now."

What to search for

This parser's artifact regex sweeps include a credential category, but here are the most productive search shapes if you're hand-grepping a strings export.

Plaintext password fields

password=
pwd=
passwd=
PASSWORD=
Pwd=

Often inside connection strings:

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

…or HTTP form bodies:

username=admin&password=hunter2&csrf=…

HTTP Authorization headers

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

The Basic form decodes (base64) to user:password. The Bearer is usually an opaque token or a JWT.

JWTs

Three base64url segments separated by dots, starting with eyJ:

eyJhbGciOiJSUzI1NiIsImtpZCI6Ii4uLiJ9.eyJzdWIiOiI...".dHJ1c3RtZQ

The first segment decodes to the header (alg, kid), the second to the claims (sub, iss, aud, exp, …). Anything that's still inside its exp window is potentially usable.

NTLM and Kerberos

NTLMSSP messages: look for the magic NTLMSSP\0 (4E 54 4C 4D 53 53 50 00).
Type-2 challenges contain the server challenge nonce; Type-3 responses contain Net-NTLMv1/v2 hash material that's crackable offline with hashcat (-m 5500 / -m 5600).
Kerberos tickets: large binary blobs near the strings krbtgt, LSA Kerberos, or service principal names (HTTP/host, MSSQLSvc/host, …). Extracting full tickets out of a pagefile is harder than from RAM, but Kerberos TGT/TGS material does sometimes survive.

LSA secrets and Domain Cached Credentials

lsass.exe keeps secret material in memory. When LSASS pages are cold enough to be evicted, fragments show up — including:

DCC2 (MS-Cache v2): 16-byte hashes near NL$KM / _SC_ strings.
Service account passwords in plaintext if LsaCfgFlags is not set.

These need a specialized tool to fully decode (mimikatz / pypykatz against a memory image), but raw fragments are findable here.

SSH and PGP key material

OpenSSH private keys in memory begin with -----BEGIN OPENSSH PRIVATE KEY----- or -----BEGIN RSA PRIVATE KEY-----. Same with PGP secret keys (-----BEGIN PGP PRIVATE KEY BLOCK-----). When the agent has the key unlocked, it lives in memory until cleared — which means it can page out.

Cloud CLI tokens

AWS: aws_access_key_id, aws_secret_access_key, aws_session_token, STS tokens (often JWT-shaped).
GCP: gcloud auth cached tokens (access_token, refresh tokens), often in JSON.
Azure: Az.Accounts cached tokens; MSAL.Token shapes.
Kubernetes: service-account JWTs (eyJhbGciOiJSUzI1NiIsImtpZCI…).

Database client artifacts

ODBC / OLEDB connection strings: Provider=…;Data Source=…;User ID=…;Password=…;.
sqlcmd -P, mysql -p arguments survive on the command line — see the malware command-line section for related patterns.

Browser-saved passwords

Chrome / Edge / Brave store saved passwords encrypted via DPAPI, but they decrypt on autofill and the plaintext lives briefly in the renderer's heap. A pagefile captured shortly after a browsing session can contain those decrypted forms.

How this tool surfaces them

The parser's Artifacts → Credential indicators tab matches:

password= / pwd= / passwd= in any string.
Authorization: Bearer … and Authorization: Basic … headers.
JWT-shaped tokens (three base64url segments separated by dots, starting with eyJ).

The Strings tab is the catch-all — use the filter input to search for Authorization, NTLMSSP, BEGIN OPENSSH, aws_secret, Bearer, etc.

Anything that's clearly a binary blob (NTLM challenge bytes, Kerberos tickets) won't show up as a string but will be flagged by the high-entropy bucket in the page map — that's where to look next.

Operational notes

Time matters. The longer a system runs after a credential is loaded, the more likely the page is overwritten with newer paged-out content. Acquire pagefile as soon as you suspect compromise.
A paired RAM dump is multiplicatively more useful for credential hunting — it gives you the live LSASS, full Kerberos cache, and process-attributable secrets. The limitations post covers why.
Don't reboot the suspect host before you've grabbed pagefile.sys — Windows may overwrite paged-out slots on the next boot. If you absolutely must, capture first.
hiberfil.sys is even better for credential recovery when present — it's a full RAM snapshot. See the comparison post.

Legal / ethical reminder

Only analyze pagefiles from systems you are authorized to investigate. Plaintext credentials extracted from someone else's machine are still credentials and using them outside the engagement scope is a separate offense entirely.