Others have posted bits and pieces regarding System Restore Point analysis (Stephen Bunting's site has some great info), and I've even blogged on this topic before, but I wanted to add a bit more information and a tidbit or two I've run across. This will go a bit beyond what's in my book, but I do want to say that the content in my book is not invalidated in any way.

First off, you can use some of the tools on the DVD accompanying my book in either live response or during post-mortem analysis to collect information from the Restore Points. I've recently updated the code to the SysRestore.pl ProDiscover ProScript to make it more usable and flexible, given some situations I've seen recently.

Another interesting thing I've run across is that using an alternative method of analysis, such as mounting the acquired image as a read-only drive letter (using VDKWin or Mount Image Pro), can be more of a problem than a solution. Accessing the system this way can really be a boon to the examiner, as you can hit the system with an AV scanner (...or two...or three...) and save yourself a great deal of time trying to locate malware. However, the problem occurs due to the fact that the ACLs on the System Volume Information directory require System level access for that system, and even having System level access on your analysis system does not equate to System level access on the mounted image. So things tend not to work as well...files within the "protected" directories will not be scanned, and your alternative is to either perform your analysis within a forensic analysis application such as ProDiscover (using ProScripts), or export the entire directory structure out of the image, at which point, storage is then a consideration (I've seen systems with quite a number of Restore Points).

This is can be an issue because bad guys may try to hide stuff in these directories...read on...

Remember me mentioning the existence of web browsing history for the Default User? This indicates the use of the WinInet API (wget.exe, IE, etc.) by someone who accessed the system with System level privileges. This level of access would also allow that user to access the System Volume Information directory, where the Restore Points are maintained, and possibly put things there, such as executable image files, etc. It's unlikely that a restore point would be used for persistence (ie, point a Windows Service to an executable image within a restore point), as the restore points eventually get deleted or flushed out (see the fifo.log file). However, this would be an excellent place to put an installer or downloader file, and then the intruder could place the files that he wanted to be persistent in either the System Volume Information directory, or the "_restore*" directory.

So, besides looking for files that we know are in the Restore Points (ie, drivetable.txt, rp.log, Registry files), we should also consider looking for files that shouldn't be there, particularly if we find other artifacts that indicate a System-level intrusion.

Beyond this, Restore Points provide a wealth of historical information about the system. By parsing all of the rp.log files, we can develop a timeline of activity on the system that will give us an idea of what was done (system checkpoint, application install/uninstall, etc.) as well as provide us with that timeline...if the Restore Points are in sequence and the dates seem skewed, then we have an indication that someone may have fiddled with the system time. Using the drivetable.txt file, you can see what drives were attached to the system at the time that the Restore Point was created (by default, one is created every 24 hrs).

Beyond these files, we also have access to the Registry files that are backed up to the Restore Points. You can parse these to see if and when a user's privilege levels were modified (ie, added to the Administrator group), determine IP addresses and network settings for the system (parse the NetworkCards key from the Software file, then the Tcpip Services key from the System file), etc.

Analysis of the Registry files maintained in Restore Points is also useful in determining a timeline for certain Registry modifications that are difficult to pin down. For example, when a Registry value is added or modified, the key's LastWrite time is updated. What if one value is added, and one is modified...how do we determine which action caused the LastWrite time to be modified? Well, by using the historical data maintained in the Restore Points, we can look back and see that on this date, the modified value was there, but the added value wasn't...and then it appears in the next Restore Point. Not exact, but it does give us a timeline.

So...what interesting things have you found in Restore Points?

Links
Kelly's Korner (XP Restore Points)
MS Windows XP System Restore
System Restore WMI Classes

I received an interesting comment to one of my recent blog posts...the poster was musing that he wished he could determine the version of XP (Home or Pro), presumably during a post-mortem examination. As this struck my interest, I began to research this...and most of what I found applies to a live running system. For example, MS has a KB article that tells you how to determine the version of XP you've got. Also, the WMI class Win32_OperatingSystem has a value called "SuiteMask" which will let you determine the version of the operating system; to see if you're on the Home version of XP, perform a logical AND operation with the SuiteMask value and 0x0200 (the "Personal" bit) - if it succeeds, you're on XP Home. You can also use the Win32::GetOSVersion() function in Perl, or implement the WMI Win32_OperatingSystem class in Perl.

This information seems to be maintained in memory, and appears to be retrieved using the GetVersionEx() API function. Running a couple of tests to extract the information while running RegMon doesn't appear to reveal anything interesting as far as Registry keys that are accessed while attempting to determine the OS version.

During a post-mortem examination, you can go to the file "%WinDir%\system32\eula.txt" and locate the last line of the file that begins with "EULAID", and you'll see something similar to:

EULAID:XPSP2_RM.0_PRO_OEM_EN

If it says "HOM" instead of "PRO", you're dealing with the Home version of XP.

Also, you can try the file "%windir%\system32\prodspec.ini", and right below the line that says "[Product Specification]", you'll see an entry that will tell you which version of the OS you're working with (note: be sure to check the last modification date on these files, as well...).

Links
Determine the version of IE installed
Check the Version of Office XP
Determine the Windows version using C# (using VB)
32- or 64-bit version of Windows?

Pp 216 - 128 of my book address the Windows XP firewall logs; where the file(s) is/are located on a system, and how they are useful to an investigation. I even include a sample firewall log on the DVD from where I enabled all logging and scanned my system with nmap from another system. I wanted folks to see what this kind of thing looks like, and I hope that you've found it beneficial.

Has anyone seen the "Bonus" directory on the DVD yet? Within the Bonus directory is a Perl script (and an associated EXE file...be sure to follow the instructions and keep the appropriate DLL with the EXE if you copy it off of the DVD) called "fw.pl" that uses WMI to get configuration information about the Windows XP firewall, and the SecurityCenter, in general.

Using either the Perl script or the EXE, type "-?" or "/h" at the command prompt to see the syntax information. Simply typing "fw.pl" or "fw" (for the EXE) tells the tool to collect and display all information. The tool displays basic information about the firewall, authorized applications, service/port information, SecurityCenter information, etc., all from a live system.

Porting this over to extracting the same information from an imaged system shouldn't be too difficult.

Note: The fw.exe file that you see in the Bonus directory was "compiled" from the Perl script using Perl2Exe. When I compiled the EXE, I used the "-small" switch so that the Perl runtime DLL would be pulled out as a separate file. However, other Perl modules are used as well, so I also compiled a version using the "-tiny" switch. This setting creates a separate DLL for each Perl module used, rather than pulling them out of the EXE at runtime and creating temporary files on the local hard drive. This file is in the "fw.zip" file...using the "-tiny" switch means that its suitable for use in live response, particularly with the Forensic Server Project.

There is discussion now and again in computer forensic circles regarding "anti-forensics", techniques that are used on systems to remove or obfuscate the artifacts that an examiner may look for and analyze. These are usually discussed in the context of purposeful actions performed by a user or attacker, but not so much in the sense that there are "under the hood", "behind the scenes" activities that go on as part of normal, day-to-day operations of the operating system that can serve the same function.

What is it that happens behind the scenes on a live XP system that most of us don't really know about? Have you ever fired up FileMon or RegMon and just watched what they recorded on a live system, without you interacting with the system at all? Now...move the mouse pointer across the screen...

While XP is a treasure trove of artifacts for an examiner, there are also things that the examiner needs to keep in mind when performing artifact extraction and analysis, particularly when it comes to looking for deleted files. When a file is deleted on a Windows system (not moved to the Recycle Bin, but really deleted), it's common knowledge that its not really gone. In a nutshell, the sectors that the file occupies are still on the hard drive, although they are now available for use by the operating system. And there's a lot that XP does to use those available sectors.

Many applications, such as MS Word, like to create temporary files while you're editing a document, and then delete those when you close the document. The sectors used by those temporary files need to come from somwhere. Yes, this is an application-specific issue and applies to any version of Windows that the application is running on.

XP creates System Restore Points, every 24 hrs by default, but also during various other actions, such as software installation or removal, etc. These Restore Points contain files that consume sectors. See my book for more information on Restore Point analysis.

Every three days, the XP Prefetch function performs a limited defragmentation of files on the hard drive. While this is limited, it still moves the contents of some sectors, overwriting others.

Speaking of XP Prefetch, when a user (any user) on the system launches a "new" application, a Prefetch file may be created for that application (assuming the 128 Prefetch file limit hasn't been reached). On my system, I have 104 .pf files, ranging in size from 8K to over 100K. Again, sectors are consumed.

As discussed in the Registry Analysis chapter of my book, there are a number of places within the Registry where a user's actions are recorded in some manner. New entries are added to the Registry, increasing the size of the files...not just the user's NTUSER.DAT file, but some actions will added entries to the HKLM hives, as well.

Of course, there are also a number of Registry settings that will have an effect on the examiner's analysis; these are addressed in detail in my book. While these aren't specific to XP, they do have a decidedly anti-forensic effect.

I mention these things because many times an examiner may be looking for evidence of a deleted file, carving unallocated space looking for a keyword or a file header, and come up empty. Remember Harlan's Corollary? ;-) Funny how there just seem to be more and more ways to apply that corollary...

Sites discussing anti-forensics aren't hard to find:
The MetaSploit AntiForensics Site
Ed Skoudis is quoted on antiforensics in 2003
Marcus K. Rogers' presentation
Ryan Harris' DFRWS paper

Microsoft recently released this KB article, titled The Change Analysis Diagnostic Tool for Windows XP is available.

So, why is this interesting? Bear with me for just a moment. Reading the article, we see that the tool looks at programs, OS components, BHOs, drivers, ActiveX controls, and ASEPs (MS's term for autostart locations). Okay, so not entirely interesting, per se...there are tools that already do this, I know. However, the really interesting part is this:

The Change Analysis Diagnostic tool queries the System Restore data for the number of days that the user selects. The tool finds the changes to the registry and to the file system that are relevant to these categories. Then, the tool presents the changes together with contextual information.

Is that sweet or what? Tools like this generally require a baseline, such as when we're performing dynamic malware analysis (ie, snapshot the system, install malware, snapshot the system again, and compare the two). In this case, MS is using the Restore Points as the snapshots. Makes me glad that I took the time to address Restore Point analysis in my book!