---
{
  "title": "Computer forensics",
  "summary": "Interpret host artifacts in the context of a question and a system.",
  "topic": "forensics",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Integrating Forensic Techniques into Incident Response",
      "url": "https://csrc.nist.gov/pubs/sp/800/86/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Computer forensics examines persistent host evidence such as files, metadata, application records, operating-system artifacts, and logs. Artifacts vary by operating system and version. Their interpretation depends on how they are created and updated. A filename, timestamp, or recovered string may be a clue rather than proof of execution or intent. Correlate independent artifacts and preserve the source before making changes.

## In practice

A download record, file metadata, and process event together support a stronger sequence than a single file timestamp alone.

## A common misunderstanding

Finding a file does not automatically prove that the user opened it, created it, or knew what it contained.

## Check your understanding

Why learn artifact semantics?

**Think it through:** The same visible field can mean different things, and a mistaken interpretation can produce an incorrect timeline.


## Let the question guide the artifacts

A host contains many traces, but collecting more data does not automatically produce a better answer. Start with an investigative question: whether a file was present, whether a program executed, or how an account accessed a resource. Different artifacts support different propositions. A filename in a recent-items list is not equivalent to the file's current content or proof of a deliberate human action.

Understand the operating system and application semantics behind each record. Caches, synchronization, automatic indexing, and background services can create traces without direct user interaction. Correlate independent sources where possible and record competing explanations. A tool's attractive report does not remove the need to understand how it interpreted the source.

## A fictional suspicious document

An academy investigates a document found on a staff laptop. The analyst examines file metadata, application records, browser context, and relevant execution evidence. A download record may support acquisition of the file, while another artifact may support opening or processing. The report distinguishes those facts instead of collapsing them into a single statement that the employee knowingly used it.

Work from preserved copies where appropriate, document tools and methods, and retain references to the original artifacts. If an artifact is missing, consider retention, collection scope, and platform behavior before concluding the action never occurred. Absence is meaningful only when the source would reliably have recorded and retained the event.

## Compare evidence strength

For a fictional training file, list three possible artifacts and the exact question each can answer. Write a claim that would exceed each artifact's support. Then combine two independent observations into a narrower, better-supported conclusion. This practice builds forensic reasoning beyond simply finding suspicious-looking strings or accepting a tool's label.

## Keep exploring

- [[file-metadata]]
- [[windows-registry]]
- [[browser-artifacts]]
- [[disk-imaging]]