Let’s just say that you’re doing an investigation of a subject and that the investigation centers around proving that they visited a certain website. Of course, you’ve check the usual places: history files, typed URLs in the registry, etc – but everything looks pretty clean. In fact, things are looking a bit *too* clean. You’re starting to suspect that the subject may have used some sort of private browsing mode while browsing. All is not lost, especially if the subject used Internet Explorer 8’s InPrivate Browsing mode, because thankfully (for us at least) Internet Explorer leaves some artifacts lying around that include URLs and sometimes even a site title. Let’s jump in…
Internet Explorer creates recovery files, which are used in the event that the browser does not exit cleanly (i.e. crashes) in order to restore the browser state upon restart. These “files” are stored in memory and depending on what the OS does from a memory management standpoint, could possibly be placed on the disk via the pagefile or hibernation file. If the recovery files are indirectly written to the disk, we’re in luck. There are, however, a few limitations that you should note. First, there is limited metadata available – given where these artifacts were originally written (i.e. pagefile.sys and hiberfil.sys) there may be limited (if any) pertinent metadata available for the artifacts that you find, so it may be difficult to place the activity on a timeline. Second, you will not be able to definitively state that a subject utilized InPrivate Browsing to visit the URLs that you find – all you can say is that the URLs found during your search for these “recovery files” have been visited at some point in time on the system where the drive was connected (of course, be careful about possible drive residue if the drive was previously used in a different system).
To find these artifacts, you’re going to be looking for a specific signature on a drive image. The signature appears to be highly predictable (at least based upon my limited research) and presents as follows:
- Lead-in (hex): 61 80 00 00 00 00
- URL (variable length)
- If there is a title present:
- 10 bytes (doesn’t appear to be consistent, however sometimes 0x2A or 0x40 appears in the 7th byte – I’m sure these have some significance, I just haven’t figured out what yet)
- Website title (variable length)
- Lead-out (hex): 01 00 + 6 bytes of null padding + FF FF FF FF (may not consistently appear, and doesn’t appear to be used if a title is not present)
Remember, we’re dealing with artifacts here, in a pagefile or hibernation file, and most likely retrieved from unallocated space – so the presentation may not be always consistent (or readable for that matter). When viewed in a hex editor, a complete artifact looks like this:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 00 00 00 00 00 00 00 00 61 80 00 00 00 00 68 00 ........a€....h. 00000010 74 00 74 00 70 00 3A 00 2F 00 2F 00 77 00 77 00 t.t.p.:././.w.w. 00000020 77 00 2E 00 6D 00 73 00 6E 00 2E 00 63 00 6F 00 w...m.s.n...c.o. 00000030 6D 00 2F 00 00 00 00 00 00 00 40 00 00 00 4D 00 m./.......@...M. 00000040 53 00 4E 00 2E 00 63 00 6F 00 6D 00 01 00 00 00 S.N...c.o.m..... 00000050 00 00 00 00 FF FF FF FF 00 00 00 00 00 00 00 00 ....ÿÿÿÿ........
So given you now know what these artifacts look like, you should be able to quickly write yourself a little script (I’m actually working on one right now – I’ll publish it once it has been completed) to find these artifacts to include in your evidence acquisition arsenal. Or feel free to use a commercial tool designed to find these artifacts (like Internet Evidence Finder)…