Casey Anthony Firefox History

Extracting and Analyzing Firefox Browsing History in Digital Forensics

Pulling browsing history from a Firefox profile is one of those tasks that sounds simple until you actually sit down with a real case. The theory is straightforward: locate the profile folder, grab the places.sqlite file, and query it. The practice is less forgiving. During the 2011 trial, investigators pulled Firefox data from Casey Anthony's computer. The browser had been used to look up information about chloroform, how to dispose of a body, and various drug-related topics. The actual history records came from the places.sqlite database, along with session data and cache files. The prosecution used this evidence to build a timeline of intent. Defense challenges focused on whether the data had been tampered with or whether the timeline was being misinterpreted. That's the context for why this specific case matters in forensic circles. I've recovered Firefox profiles from maybe two dozen machines over the years, and each one throws a different wrench at the process. The places.sqlite file is the core artifact, but it doesn't exist in isolation. You also need cookies.sqlite, formhistory.sqlite, and the parent.lock file to understand the full picture of what was open, when, and what might have been modified after the fact.

The standard approach is to image the drive first. Don't skip that. If you pull the SQLite file off a live system, you're contaminating modification timestamps and potentially triggering overwrite cycles. Firefox writes to places.sqlite frequently, sometimes multiple times per second. A raw copy without preserving the full volume structure loses a lot of metadata you might actually need later. Once you have the image, locate the Firefox profile directory. On Windows it's typically under %APPDATA%\Mozilla\Firefox\Profiles\, and inside that you'll find a randomly named folder like abc123.default-release. That's your target. Copy the entire profile folder to your analysis workstation before touching anything. Open places.sqlite with a proper SQLite client. Not the one that comes bundled with Firefox itself — use something like DB Browser for SQLite or sqlite3 from the command line. The key tables are moz_places for URLs, moz_historyvisits for the visit records, and moz_bookmarks if you need to cross-reference saved items. The most useful query structure looks at place_id from moz_historyvisits joined to moz_places to get the URL, title, visit type, and date. Visit dates are stored as integer64 values representing microseconds since October 7, 2007. Convert them early. Don't try to do mental math on microsecond timestamps during testimony.

Here's the thing most people miss: the visit_type column. It tells you how the page was reached. A value of 1 means a typed URL, 4 means a link click, and 16 means a redirect. If you're reconstructing a timeline of intent, typed URLs carry more weight than link clicks. The prosecution in the Anthony case relied heavily on the typed URL records because they directly show what someone intentionally searched for rather than what they stumbled onto through normal browsing. I ran into a problem last year where the places.sqlite file was damaged — corruption from a power loss during a write cycle. Firefox had left behind a places.sqlite.bak but it was several days old. The workaround was to run a SQLite integrity check first, then use the .recover command to extract what data I could from the damaged file. It only recovered about 60 percent of the history, but the recovered portion included the critical entries. If you're working with a damaged file and your first attempt fails, don't stop. Try the recovery command, try opening it with a newer version of SQLite that has better corruption tolerance, and always check for backup files in the profile directory. There's also a cert9.db and key4.db in modern Firefox profiles that handle certificate and key data, which can be relevant if you're trying to determine what SSL connections were made. Another counter-intuitive detail: Firefox does not always delete history cleanly. When a user clears their browsing history, Firefox removes the records from places.sqlite but the space isn't immediately overwritten. Standard carving techniques can sometimes recover deleted history entries from unallocated space within the database file itself. I've had cases where someone thought they'd covered their tracks by clearing history, and the deleted entries were still recoverable through page carver or a manual hex search of the database file. This doesn't always work. It depends on how much time has passed, whether the system has been writing other data, and the size of the profile folder. But it's worth attempting before you conclude the history is gone.

Sessionstore.jsonlz4 is another artifact that people overlook. It contains data about which tabs were open during a browser session, including URLs and timestamps. When places.sqlite is incomplete or corrupted, the session store can fill in gaps. The format is compressed JSON, so you'll need to decompress it. Tools like the JSONLZ4 decompressor built into Forensic Browser for SQLite can handle this, or you can use a standalone Python script. The session data gives you a snapshot of what was open at a point in time, which is different from the chronological history in places.sqlite. Using both together gives you a much more complete reconstruction. The biggest limitation with Firefox history analysis is that it only shows what was accessed through that particular Firefox installation. If the subject used Chrome, Edge, or a mobile device, that data is completely separate. Firefox also stores data in its Profile Global File (places.sqlite) using a specific schema that has changed across versions. Firefox 3.x uses a different schema than Firefox 4 and later. Make sure your analysis tool supports the version you're examining, or you'll get errors on basic queries. This came up in a case a while back where I was working with a Firefox 3 profile from an older machine and kept getting schema mismatch errors until I switched to an older version of my analysis toolkit. There's also the question of accuracy when it comes to timing. Firefox stores visit times in UTC microseconds, but users often don't adjust their system clock. If the computer's clock was wrong, every timestamp in the history is wrong. I've seen cases where the system clock was off by several hours, which threw off the entire timeline. Always verify the system clock setting against external evidence like email headers or website certificates before relying on the timestamps.

For tool recommendations, Autopsy handles Firefox profile analysis reasonably well if you're doing a full disk image review. It will extract places.sqlite and present the data in a browser-friendly interface. For deeper work, especially with corrupted databases or when you need custom queries, a combination of DB Browser for SQLite and the Session Parser tool gives you the most control. If you're working in a legal context and need to demonstrate your methodology in court, document every step including the hash values of the files you examined, the tools used, and the query results. The Anthony case showed how quickly browser history evidence can become a focal point, and how important it is to have a defensible chain of custody and analysis process. One more thing: don't ignore the downloads.sqlite file in the profile. It tracks every file downloaded through Firefox, including the original URL, the local file path, and the start and end times. That can corroborate or contradict what the browsing history alone suggests about someone's activities.