Tools · Forensics tools · 10 / 25
Volatility 3: files and registry hives cached in RAM
The kernel caches file objects and registry hives. windows.filescan and the registry plugins let you see names that were open recently, including some the disk timeline already showed you from a different side.
A file object is a name the kernel was using
windows.filescan scans for file objects and prints a path and an offset. The path can be a file that was open, a file that was recently used, or a name still sitting in a structure after the close. It is another source, like a handle, and it is allowed to include files you already saw in Autopsy. Agreement between a file object named \Temp\p4.xlsx and a directory entry with the same path is corroboration. A file object with no directory entry is a name that was used and then deleted, or a path you have not found yet. You search the disk exam before you call it deleted.
Paths in memory use the kernel’s form, often with a device prefix rather than C:. Read the suffix. Users\avery\AppData\Local\Temp\p4.xlsx is the same place as the Autopsy path once you account for the prefix. Quote the plugin’s string, then add the drive-letter form in parentheses if you are sure of the volume. If you are not sure which volume, leave the kernel path alone.
vol -f NL-FIN-14.raw windows.filescan
A dumped file is a derivative
windows.dumpfiles can write out cached file contents for an offset you choose from the scan. Use it when the disk copy is missing or when you need to know whether the cached pages differ from the file Autopsy hashed. Hash the dump immediately. Record the memory offset, the path, and the image hash it came from. If the dump’s SHA-256 matches the Temp workbook, the cache and the disk agree. If it differs, you have two contents and you keep both hashes. If the dump is partial because pages were not resident, say it is partial. A short file with the right header and the wrong length is not “the payroll file” until the hash or a structured compare says so.
Store dumps in the case export folder with the manifest habit from the Autopsy report lesson. Memory dumps and disk extracts should be obviously named. NL-2026-041-mem-p4.xlsx is a cache extract. It should not be dropped into the same folder as the evidence image under a name that looks like an original.
Hives in memory are the registry at that moment
Windows keeps registry hives in memory. The registry plugins can list hives and print a key you name. The keys that matter in a laptop exam of this shape are the ones that start programs: Run keys for the user and the machine, services, and scheduled-task artifacts if you have a plugin output that shows them. You print the key you have a reason to read. A full hive dump is a lot of personal configuration, and the authorization is about the payroll incident. Stay on the keys that answer “what would start again at next logon” and “what did this user run.”
A value in memory can be newer than the hive file on disk, or it can match it. When you cite a Run value, also look at the hive file in Autopsy and say whether they agree. Quote the value name and the data. A value that points at powershell.exe with an argument that includes the workbook name is the same kind of exhibit as the command line, with a different source. A value that points at a path that does not exist is still a value. Note the missing target.
Put memory back on the timeline
Memory artifacts often lack the neat timestamps the filesystem has. The acquisition time bounds them: they were still in RAM at 09:22 America/New_York. Some process objects carry create and exit times, and those you already converted. File objects and registry values may not. When you place them on the case timeline, label them “resident at acquisition” unless you have a structure time. Do not assign them 09:18 because that is when you wish the copy happened. The command line and the process times are what tie pid 4812 to that window.
The memory chapter of the report can now be a single page. Image hash, symbol table, acquisition time, the exited powershell object and its command line, the TIME_WAIT row, the quiet malfind, and any file or registry name you corroborated. Each line names a plugin. That page is what Autopsy could not say, and it stays inside what the snapshot contained.
Worked case: the Temp path still resident, the Run key quiet
windows.filescan includes a path ending in \Users\avery\AppData\Local\Temp\p4.xlsx. You do not dump it, because Autopsy already has the file and the hash, and the name in memory matches. You note “file object resident at 09:22 America/New_York.” The user Run key and the machine Run key, printed from the hives in memory, contain the office’s normal login items and nothing that names powershell, p4.xlsx, or drop.lab.example.
The memory page for NL-2026-041 is done. Process 4812 exited after a command that names both workbook paths. A TCP structure still pointed at 203.0.113.44:443 in TIME_WAIT. No private executable region, no new Run value. The remaining question is whether Sysmon recorded the process and the connection at 09:17, when the snapshot itself is too late to be a live view.
Diagram
From a cached name to a line on the memory page
- Scan
filescan supplies a kernel path. Translate the prefix carefully, and keep the original string in the note.
- Disk
Search the Autopsy case for the same suffix. Record whether the directory entry exists and what its hash is.
- Dump
Dump cached pages only when the disk copy is missing or you need to compare. Hash the dump and file a manifest line.
- Keys
Print the Run keys you have a reason to read. Say whether memory and the on-disk hive agree.
File object at acquisition: ...\Temp\p4.xlsx Disk exhibit: same suffix, SHA-256 matches the Documents copy User Run key: no value names this path
Check yourself
1. filescan shows the Temp workbook path. Autopsy has that file with a SHA-256. You have not dumped the cache. What is the accurate statement?