Archive for January, 2011
Every file system handles MAC times slightly differently, however sleuthkit (as well as other forensics software products) use the same acronym/fields no matter which file system you’re analyzing. Here’s a quick run-down of some popular file systems and what the M, A, C, and B mean:
|Ext2/3||Modified||Accessed||Attribute modification and/or file content change||N/A|
|NTFS||File Modified||Accessed||MFT Modified||Created|
|UFS||Modified||Accessed||Attribute modification and/or file content change||N/A|
Harlan Carvey recently wrote a post on his blog called Accessing Volume Shadow Copies, which provided some excellent instruction on how you can go about accessing Volume Shadow Copies (VSCs) from an existing image without having to use expensive tools (in fact, his solution uses completely free tools). In Windows 7 and Vista, VSS is turned on by default and thus additional artifacts are possibly just waiting to be discovered. Accessing a system’s VSC(s) can be highly useful in an investigation and can possibly help you get your hands on older copies of registry hives (i.e. being able to get historical UserAssist data, etc) as well as other older file snapshots (pictures, etc), which can come in very handy. So, needless to say, if you’re not presently looking for VSCs as part of your forensics workflow, you probably should be…
In the process of testing Harlan’s procedure, I started to wonder how Windows, by default, decides to generate these VSCs (and what is included). I came up with some data and I thought that I’d go ahead and post my findings (feel free to comment if I’ve gotten anything wrong here):
- Windows 7/Vista automatically (out of the box) create restore points at pseudo-random intervals:
- A scheduled task (named SR in Win7) controls when a snapshot occurs. By default, the task is set to run at 12:00AM every day and 30 minutes after every system startup, but will only execute when the system is plugged in and has been idle for 10 minutes. If the system is not idle, the task will continue to wait for idle for 23 hours.
- If a restore point/snapshot has not been successfully created in the last seven days, system protection will create one automatically.
- And finally, a restore point may be created “automagically” as part of certain software installation/driver installation processes.
- The bottom line: it is basically impossible to predict with any degree of certainty when a snapshot will occur.
- All files/folders are covered in a volume snapshot, except for those defined under the HKLM\System\CurrentControlSet\Control\Backup Restore\FilesNotToSnapshot registry key.
- If a file is modified several times between snapshots, only the version that was current when the restore point/VSC was made will be available to you for analysis. Mind you, there may be multiple VSCs available, so that can be helpful with getting further historical revisions.
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 0×40 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)…