Due to the wide range of ESE database implementations, ESENTUTL is a powerful and complex tool. Luckily, Microsoft provides a tool to perform this action, ESENTUTL. A much easier option is to replay the dirty pages available in log files into the WebCache database file. While ESE log files can be manually interpreted, it is a painstaking process left as a last resort. Once recovered, the log files in this example held an additional 32 history entries, two cookies, and 3041 browser cache entries not yet written to the WebCache database.įigure 2: Modification Times of ESE Log Files and Database Mining the Log Files Very few forensic tools currently have the ability to extract data from ESE log files and in this example the investigator may have easily missed the last 24+ hours of available artifacts.
Note that the last log file was written to well over 24 hours after the last modification time of the WebCacheV01.dat file. To give an idea of how much data may still be present outside of the ESE database, Figure 2 shows the WebCache directory for a typical IE instance. This seemingly drawn out process explains why relevant data can exist outside of the ESE database and why we continue to find so many browser artifacts (including InPrivate browsing) in memory and the pagefile. Finally, the ESE database continuously monitors the number of dirty pages in the memory cache and prioritizes writes into the database file (WebCacheV*.dat in IE), aiming to preserve disk I/O performance. These "dirty pages" in the memory cache can persist for hours or even days. Next, the database creates an in-memory cache and formats the log file data into database pages to be written into the database. ESE log files contain enough information to bring the database to a logically consistent state in the event of a catastrophic event like power failure or application crash.
The log buffer is small, so data is quickly written to disk in the form of individual log files, each 512KB in size in the current version of Internet Explorer. Changes are written first into memory within the log file buffers, which typically range from 64KB in size to the low hundreds of kilobytes.
Instead, the ESE database uses a write-ahead model, meaning new data is not immediately written into the database. Each transaction can require multiple changes to the database, making it infeasible to write changes directly to the database file on disk as you might see in older database formats like "Index.dat". While the Internet Explorer implementation certainly doesn't require it, the ESE database format was built to handle a massive number of near-simultaneous transactions. Thus IE history, and the WebCache database in particular, continues to be a rich data source during many forensic examinations.
Internet Explorer and its supporting libraries are deeply tied to the Windows operating system and WinINet API functions often interact with IE databases. It may also hold evidence of malicious activity including HTTP connections initiated on behalf of malware or suspicious sites visited via links clicked in email clients.
Remember that even if a user never opens Internet Explorer, there may still be valuable records in their IE database including files opened on the local system, network shares, and removable devices. With the introduction of an enterprise-grade database hosting network artifacts, it is now time for every Windows investigator to understand how the database works and what data they may be missing. While many forensic examiners have remained blissfully unaware of the ESE format, it has been increasingly used throughout Microsoft products for Exchange, NTDS.DIT, the Windows search database, Windows Live Messenger contacts, and Internet Explorer (IE). The perennial Index.dat records were replaced with a centralized meta-data store for the browser using the proven "JET Blue" Extensible Storage Engine (ESE) database format. With the release of Internet Explorer 10, Microsoft made a radical departure from the way previous browser artifacts were stored.