What evidence exists only in a Windows memory image and never in a disk image?

## The distinction that matters A disk image answers *what was stored on this machine*. A memory image answers *what this machine was doing*. The two overlap - RAM contains cached file contents, mapped executables and loaded registry hives - but there is a set of evidence that exists in RAM and has no on-disk counterpart at all. If the host is powered off or reimaged, that evidence is gone permanently and no later collection recovers it. ## What only RAM holds **Code with no file behind it.** The classic modern case: an operator injects a payload into a process that is already running - a signed Microsoft binary, correctly installed, whose file on disk is genuinely untampered. Nothing was written to the filesystem, so there is no file to hash, no Authenticode result to check, no Prefetch or Amcache entry for a new image. The executable bytes exist as pages inside another process's address space. Only a memory image captures them. **The full command line.** Windows stores each process's command line in its own user-space parameter block, exactly as the loader received it. Log sources are less reliable here: the native Windows Security 4688 process-creation event includes the command line **only** when the audit policy option to include it has been switched on, and Sysmon Event ID 1 carries it only on hosts where Sysmon was installed and running before the process started. Memory has it for any process still alive at capture, regardless of what anyone configured months earlier. **Live network state with ownership.** The kernel's TCP endpoint structures record local and remote address, port, state and the owning process id. That last field is the point: it binds a connection to a process. A flow record from the network tells you bytes moved between two addresses; it cannot tell you which process on the host opened the socket. Memory can. **Decrypted material.** A process that reads an encrypted configuration file, unwraps a key or receives a TLS-protected response holds the plaintext in its own memory. On disk there is only ciphertext. **Credential material.** `lsass.exe` holds the secrets needed to authenticate on behalf of logged-on users - password hashes, Kerberos tickets and their session keys, and cleartext secrets wherever a security provider is configured to cache them. Recovering these from an image tells you what an adversary with the same access *could* have taken. ## What that evidence proves - and what it does not Be precise about direction. Finding a credential in memory proves **the secret was resident on that host at the moment of capture**, so it must be treated as exposed and rotated. It does **not** prove anybody read it. Likewise, a network endpoint structure proves a socket existed with that owner; it says nothing about what crossed it, because the endpoint structure carries no payload. And executable pages inside a legitimate process prove code is mapped there, not that the code is hostile - runtimes that compile code at execution time produce private executable memory as a matter of routine. ## Why this bites in practice In a live purple-team exercise against production Windows servers, a beacon injected into a running application-server process can be invisible to every rule and every sensor: no new file, no new process, no anomalous parent-child pair, a signed image, a normal process list. The exercise's proof that the technique ran can end up resting entirely on the memory image - the finding exists *because* the image was taken. That is also why the reflex to "just reimage it" destroys the case: reimaging removes the implant and every trace of it in one action. ## The limits Memory is not a superset of disk. It holds only what is currently mapped or cached, historical artefacts such as event-log records and filesystem metadata live on disk, and RAM is a partial and stale view of any file it happens to be caching. And a memory image taken from a running system is not an atomic snapshot - it is written over minutes while the kernel keeps changing what is being copied - so parts of it can disagree with each other. Treat the two images as complementary sources answering different questions rather than one substituting for the other.