Internet Explorer and legacy Edge history forensics

Internet Explorer is gone from supported Windows, but its artefacts are not. You will still meet them on legacy hosts, on long-lived VMs, and inside applications that embed the old WebBrowser control. IE10+ and pre-Chromium ("Spartan") Edge both store their browsing data in a single ESE database, and it does not look like the SQLite world you are used to.

Where it lives

From IE10 onward, history, cache, cookies and download history all live in WebCacheV01.dat:

C:\Users\<user>\AppData\Local\Microsoft\Windows\WebCache\WebCacheV01.dat

This is not SQLite. It is an ESE database (Extensible Storage Engine, also called JET Blue) — the same storage engine behind the Windows SRUM database and several other system artefacts. ESE keeps a transaction log alongside the main file (V01*.log, V01.chk), and the database can be left in a dirty state when the host is acquired live. Collect the whole WebCache\ directory, not just the .dat, so the log files come with it.

The container model

WebCacheV01.dat is organised around containers. A top-level Containers table maps numeric container IDs to per-container tables and records what each one holds:

History — visited URLs, one container per user and date range.
Cookies — cookie records and their backing files.
Content — the cache (the old Temporary Internet Files), with paths to the cached response bodies on disk.
DownloadHistory / iedownload — download records.

To read history end to end you walk the Containers table, find the History containers, then read the per-container tables they point at. Tools that understand the format do this enumeration for you.

What a record contains

Each entry in a container table carries the fields you would expect from a history artefact:

URL — including the Visited: and iedownload: prefixes IE uses internally.
AccessedTime and ModifiedTime — stored as Windows FILETIME: 100-nanosecond intervals since 1601-01-01 UTC. Convert before you correlate with anything else on the timeline.
Cache file paths — for Content entries, the local file holding the cached response, which can be carved or hashed independently.

Cross-referencing the cached file paths against the live filesystem (and the MFT) often recovers page content long after the history entry itself was the only thing on the analyst's radar.

Older IE: index.dat

IE9 and earlier predate the ESE layout. They used index.dat files — one per History, Cache and Cookies store — built from binary records tagged URL (a visited or cached entry), REDR (a redirect) and LEAK (an entry marked for deletion that was never reclaimed). LEAK records are useful: they are effectively deleted history that survived. If you are on a pre-IE10 host, this is the format in front of you, not WebCacheV01.dat.

Honest scope: this tool does not parse ESE

BrowserForensics is a 100% client-side, in-browser tool, and it targets the Chromium, Firefox and Safari families — SQLite, plists, LevelDB and the formats covered across this series. It does not parse the ESE WebCacheV01.dat format. There is no in-browser ESE engine here, and faking one would do you a disservice on a real case.

To extract IE / legacy Edge history, use a dedicated ESE tool first:

libesedb / esedbexport to dump the ESE tables to flat files, then reconstruct the container relationships.
An established IE-history parser (the well-known DFIR tools that read WebCacheV01.dat and index.dat directly) if you want the records resolved for you.

Once you have the URLs and FILETIME values out, the analysis mindset is the same as everywhere else in this series. Treat this post as orientation for the artefact, not a promise that you can drop the .dat into the browser.

Modern Edge is a different story

Do not confuse legacy Edge with current Edge. Modern Edge is Chromium and is fully supported by this tool — same History SQLite database, same schema as Chrome. If the host was updated past 2020, you are almost certainly looking at the Chromium layout. See Microsoft Edge history file locations for the paths and the one EdgeHTML caveat that still applies.