Autopsy: names, deleted files, and hash sets

The name and the bytes can part ways

A directory entry is a name, a parent, and a pointer at content. On NTFS the content lives in the file record and, when the file is large, in runs on the volume. Delete the file and the name may remain until that index entry is reused, marked so the examiner can still see it. The content remains until those clusters are allocated to something else. Autopsy shows deleted names when the directory still has them. “Deleted” in that view means the name is not in the live tree. It does not mean the bytes are gone, and it does not mean the bytes are intact.

A carved file is the opposite shape. A carver looks through unallocated space for a header and a footer it recognizes, and it offers you a candidate with no original name and no original path. You label it as carved, you hash it, and you keep the offset. Putting a carved JPEG in the report as “the user’s photo” overclaims what the carver knew. Putting it in the report as “a JPEG candidate at this offset, hash, not tied to a directory name” is the accurate exhibit.

Hash the bytes you are talking about

A hash is a name for the content. MD5 still appears because older sets were built with it. SHA-256 is the value to quote when you describe a file to someone outside the tool. Hash the file you mean: the Documents copy and the Temp copy can share a name pattern and differ by a byte, and they will not share a SHA-256. If they do share one, you have a strong statement that the content matches, which is still not a statement about who copied it.

Extension mismatch is a separate check. A file named report.txt whose type identification says it is an executable is a lead. Type identification looks at the header, and headers can be deliberate or coincidental. Open the result as “the extension and the detected type disagree,” then decide whether the file matters to this case. A mismatch on a printer cache in a payroll case can wait. A mismatch on p4.xlsx cannot.

Known files and known-bad files do different jobs

The National Software Reference Library (NSRL) and similar sets list hashes of files from operating systems and common software. A match means the bytes are a known build of that file. It is how you stop reading the thousandth copy of a Windows binary. It is a weak alibi for behavior. A stock powershell.exe that matches the set is still the program that ran, and the command line, the parent process, and the files it touched are the rest of the question. Ignore the hash match and you will waste the day on system files. Treat the match as innocence and you will ignore the tool the account actually used.

A known-bad set is a list you were given: prior case files, a lab specimen, a hash the SOC already computed. A match is a priority. You still open the context. The same bytes in a quarantine folder and the same bytes in a Run key’s target are different stories, and the hash set does not know the folder. Keep the set’s name and version in the notes. “Matched our list” is unverifiable. “Matched northline-lab-2026-04.txt, SHA-256, line for the April workbook” is something the next examiner can load.

• Quote SHA-256 for files you will talk about.
• Record which set and which algorithm produced a hit.
• A known-file hit lowers priority. It does not erase the way the file was used.
• A known-bad hit raises priority. The path and the timestamps still get written down.

Extract a copy without losing the link

When you extract a file for another tool, hash the extract and write down the original path, the data source, and the hash. The extract is a derivative. The image remains the evidence. If CyberChef or YARA will see the extract, the case note should say so, including the hash you handed over. Two files with the same name in Temp and in your export folder will confuse a later you unless the hash is on both notes.

Keyword hits are pointers back into this same discipline. A hit on the string Payroll-April inside a pagefile or a log is not the workbook. It is a place the name occurred. You open it, you see the surrounding bytes, and you decide whether it is the file, a mention, or a fragment. The hit list is a queue.

Worked case: two names, one hash, one known binary

Documents\Payroll-April.xlsx and AppData\Local\Temp\p4.xlsx share a SHA-256. The extension on the Temp copy is still xlsx, and file type identification agrees. You record one content hash and two paths, with the timeline times from the previous lesson. Hash lookup on C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe matches the NSRL entry for the laptop’s Windows build. You note the match and keep the binary in the case as the program a later command line may name, and you do not drop it from the story.

A carved item in unallocated space has an xlsx header and a different hash. You tag it “carved candidate,” store the offset, and leave it out of the sentence about the two named copies. It may matter later. It is not yet the payroll file.