Tor Browser forensics: what's on disk

Tor Browser is Firefox ESR with the Tor Project's privacy patches and a bundled Tor client, configured to behave like permanent private mode. It does not retain history, clears cookies and cache on exit, and keeps no form history — so an on-disk profile parse usually comes back nearly empty. The high-value signal is rarely the browsing data; it is the fact that Tor Browser exists on the machine and ran at all.

Where it lives

Tor Browser is a portable install: a self-contained Tor Browser folder the user dropped wherever they liked — Desktop, a USB stick, a Downloads subfolder. There is no system installer and no registry-style "installed programs" entry to lean on, so locating the folder is the first task. Search the volume for the Tor Browser directory or its firefox.exe / start-tor-browser launcher.

Inside, the profile is at:

Browser/TorBrowser/Data/Browser/profile.default/

That is a standard Firefox profile layout. Any artifacts present there are in ordinary Firefox formats and will parse with the usual tooling — including this one — but in a default configuration most of those stores are empty or reset.

What the default config does (and doesn't) keep

By design, Tor Browser runs as if private mode were always on:

History — not retained. places.sqlite will not hold a browsing timeline for default sessions.
Cookies, cache, site data — cleared on exit; held in memory during a session.
Form and search history — not recorded.

So do not promise a "what sites did they visit" timeline from the disk profile. It almost certainly is not there.

What may still persist

Plenty of context survives even when the browsing itself does not:

The install's existence and timestamps. The presence of a Tor Browser folder, plus the folder and file creation/modification times, establishes that Tor was deployed and roughly when. This is often the single most useful finding.
Bookmarks. Bookmarking is an explicit persist action; entries survive in the normal Firefox bookmarks store.
prefs.js. Preferences can reveal configuration choices, the last update state, and other settings the user touched.
Tor state and torrc. The Tor client's state files and config can show bridge use, configured options, and other operational detail.
Downloaded files. Anything the user chose to save lands on disk like any other file, with its own filesystem timestamps — outside the profile's self-cleaning behavior.

Where to look instead

Because the profile is deliberately sparse, the strongest disk-side evidence lives in the operating system, not the browser. Execution artifacts answer "did it run, and when":

Prefetch — confirms firefox.exe / tor.exe executed, with run counts and timestamps.
ShimCache / AmCache — records the executable's path and presence, useful when the folder was later deleted.
Jump lists — may show recent file or launcher activity.
USN journal — captures the create/rename/delete trail, including a later attempt to wipe the Tor Browser folder.

How to run a Tor case

Be honest with whoever tasked the case: for Tor, the disk usually proves existence and execution, not browsing content. Memory capture is the most valuable source — a live RAM image taken before shutdown can hold URLs, page content, and session state that the profile never writes. Take it first.

After memory, prioritise the OS execution artifacts above, then the install folder itself. Parse the profile anyway — for bookmarks, prefs.js, the Tor state files, and saved downloads — but set expectations that the browsing history will be thin or absent. Cross-reference saved downloads against the MFT for on-disk creation and the USN journal for any later cleanup.