Forensic Analysis of System Restore
Points in Microsoft Windows XP
Kris Harms
MANDIANT Corporation
675 N Washington Street
Suite 210
Alexandria, VA 22314
Forensic Analysis of System Restore Points in Microsoft Windows XP
Kris Harms
MANDIANT Corporation
675 N Washington Street
Suite 210
Alexandria VA 22314
Keywords : Windows XP System Restore Points Forensic Analysis Intrusion Key Logger
Introduction
Investigating computer intrusions can be a complicated matter. Attackers are continually hiding
their malicious code, erasing or modifying log files, and finding new techniques to minimize the
trace evidence they leave behind. After reviewing nearly 200 compromised systems in the last
12 months, I have often become frustrated with the lack of evidence found on victim systems
after the intrusions took place. In fact, the exploitation and post-exploitation techniques used by
current attackers almost always thwart traditional physical media analysis practiced by the
majority of computer forensic examiners. Therefore, we have to continually improve our
techniques, and add investigative steps that used to be rare, but now must become commonplace
to the forensic examinations we perform in support of computer intrusion cases. Several new
investigative steps we have added to our repertoire include in-depth examination of System
Restore points.
This article is the result of a case study on an investigation conducted in the United States. This
case demonstrates how computer forensic examiners can review System Restore points to
establish an event timeline and unearth well hidden clues that assist in understanding how a
computer system had been compromised. Without review of the System Restore points, our
investigation would have fallen very short of answering the questions promoted by the case.
The Case1
Tuesday, 5/11/2006: A financial manager at a law firm checked the company’s bank account
and she noticed that $20,000 USD was transferred from the account without proper
authorization. A phone call was placed to the bank, and the password to the account was
changed.
Wednesday, 5/12/2006: A day after the first unlawful and unauthorized money transfer took
place, the manager checked the company’s account and found another $20,000 transferred out of
the account. She placed a phone call to the bank and the password was changed, again.
Friday, 5/14/2006: The company’s bank account was checked and $10,000 was missing from
the account again, liquidating the entire account. A third phone call was placed to the bank, and
the entire account was frozen by the bank.
We were called to respond to the incident, collect live response data, and image the computers.
The issue became, who was responsible for the loss of the money? The bank or the woman? To
answer this question, it was pertinent to determine who was responsible for the loss of the user
account and password used by attackers to transfer the money unlawfully.
The bank hired a well known vulnerability assessment group to determine if the bank’s
applications were vulnerable to attack. $150,000 and a full source code review later, the
assessment group gives the bank a clean bill of health and rules out the direct attack vector.
Therefore, it was believed that perhaps the woman’s system had been compromised, and that the
-2-
attackers obtained the user account (which was the private bank account number) and the
password from her system. Her attorney requested that a thorough computer forensic analysis be
conducted on her system to determine if she was the victim of a computer exploit.
One of our senior forensic examiner’s received the laptop and started his investigation the same
way he starts all his digital investigations, with a Zen-like review of the hard drive to get a “feel”
for its layout and contents, and to provide himself an opportunity to follow his instinct before
following the structured forensic review he has laid out. The technique revealed a goldmine of
valuable information. Upon review of the \windows\System32 directory of the Windows XP
laptop image, the forensic examiner noticed a mysterious file called sdsini.ini. This file was
suspicious because .ini files are generally not used anymore for core windows applications,
having been replaced with registry entries. He examined the content of the file and found an
organized list of usernames and passwords associated to websites. The file appeared to be
generated by an attacker’s key logger, but it did not contain the exact keystrokes that would
provide an attacker with the bank account number and password required to manipulate funds. A
thorough analysis of the live response data, including running processes, open network ports, and
memory collected on the response revealed no currently executing malicious activities. We left
with a file that captured the woman’s keystrokes, but we could not find any malicious code such
as a key logger, nor could we find the exact moment at which the bank account credentials were
compromised. Therefore, we still could not answer the key issue; who lost the credentials, the
bank or the woman?
Challenges
The challenges of the forensic examiner in this case were the following.
1. Confirm or dispel the laptop’s compromise.
2. Determine if compromise lead to loss of credentials.
3. Identify any malicious code used by the attacker.
4. Construct a timeline of events.
It was analysis of the System Restore points that solved the case.
What You Need to Know to Solve This and Other Cases
System Restore Overview
System Restore first appeared in Windows ME and was further refined in Microsoft Windows
XP Home and Professional. The process is meant to provide the user an opportunity to restore
critical operating system and application files during a crash or crisis. System Restore monitors
changes to system and various application files and provides simple and immediate recovery to
various points in time through the creation of restore points. Its value can also be utilized in the
forensic arena.
Restore points may contain the key piece of evidence to support a case, but are commonly
overlooked. Content within restore points can be a crippling piece of history to leave behind for
an attacker, exposing code, configurations and log files. Many times, these file can be found
-3-
even after attempts at counter forensics such as log wiping, time/date stomping and secure
deletion.
Creation
The Restore Point creation process is enabled by default and happens automatically so odds are
high that they can be found on a compromised Windows XP Professional system. System
Restore Point creation is triggered by one of the following events2:
•
•
•
•
•
•
•
•
Initial boot of Windows XP
Every 24 hours of up time
Before program installations
Before automatic updates
Before a restore point restoration
Before an unsigned driver is installed
Before restoring backup data using the Backup tool
Manual creation
A GUI exists for the creation and management of System Restore points. It can be found under
Start / Programs / Accessories / System Tools / System Restore. This interface provides
administrative control over many of the monitoring activities.
Contents
Registry hives and specific files are copied into restore points upon creation. Not all files are
copied after a change however. File selection is governed by include and exclude statements in
filelist.xml located in the C:\WINDOWS\system32\Restore\ directory3. This XML file guides the
restore point creation process and dictates which file extensions will be monitored. Also
contained in this list are directory inclusions and exclusions, so it is important when reviewing
System Restore points that your first investigative check be the filelist.xml for a comparison with
the default values to rule out tampering.
Contents most apt to support an ongoing investigation are;
• Registry snapshots
Analysis of registry snapshots over the course of time can be a very fruitful piece of evidence
and is useful across several different types of investigations. Snapshots of the registry can show
system changes such as the installation of hardware and software, program configuration
changes, password changes and network history. The registry is vast in its information, so the
list is endless.
• File Snapshots
An example of files you will find in restore points include .exe’s, .dll’s, .ini’s and a very large
list of other extensions most users are not familiar with. These files can be copied into restore
points unbeknown to an attacker. Some counter forensic efforts can be thwarted by the creation
of a restore point which captures the attacker’s tools before they are securely uninstalled after the
attack. Files that you will not find in restore points are user specific files such as .doc’s, .pdf’s
-4-
and .pst’s. Various log files including Windows event logs are also not included in restore points
by default.
• File Metadata
File attributes such as the last modified, last accessed and last created (MAC) times are not
altered during the creation of System Restore points. The MAC data on the file is transferred in
tact to the RP# folder. Metadata associated with files can add in the creation of an event timeline
and allow a better view into the actions that have taken place on the computer. MAC analysis can
quickly identify files related to an incident by comparing MAC times of known malicious files to
unknown files. It can show when files were introduced to the system, or when they were
changed, and help identify a time frame of the attack.
Size
By default, restore point size is limited to 12% of the drive space on drives larger than 4GB, and
400MB on drives smaller than 4GB. Size is further limited by the amount of free space on the
drive, giving priority to the system, not the restore points. As restore points fill 90% of the
allotted 12% drive space, System Restore will delete restore points on a first in first out (FIFO)
basis until only 75% of the 12% allocated drive space is used. This configuration can be
changed in the GUI application mentioned above, or the registry, which is discussed later.
File Structure
The figure below illustrates the relevant directory structure of System Restore Point storage. We
will discuss each directory and its contents, starting with the root and working ourselves into the
tree.
Figure 1: Directory Structure of Restore Point Storage
The System Volume Information directory can be found at the root of all XP system drives
regardless of the state of System Restore. On a running system, this directory and its contents
are restricted to SYSTEM level access by default, but it should be known that alteration of the
data is possible by simply changing the rights of the file to include administrator or user level
access.
The _restore(System GUID)4resides inside the System Volume Information directory. This
directory exists only when System Restore monitoring is enabled and contains the list of
previously created restore points. The restore point folders are appropriately named RP## where
the #’s are numbers sequentially assigned to folder. This directory also contains _filelist.cfg, a
-5-
binary file which contains the list of the monitored extensions and excluded directories found in
filelist.xml mentioned above.
Figure 2: A directory listing of the _restore directory
The RP# directory is the storage location for all monitored files that changed between the
creation time of this restore point, and the creation time of the previous restore point. The
System Restore process copies new and changed files matching the included extensions into this
directory and renames them. An example of the naming convention used is A0000628.exe. The
numbers increment by one as files are added to the restore point. The file extensions are kept the
same. A log of these files and their original names and location from which they were copied
are kept in a change.log file in this directory also. Further analysis of the change.log is
documented later.
Figure 3: Directory listing of RP8 with the /TC switch, showing creation dates.
The snapshot directory is a subfolder in the RP# directory. Here you will find exact copies of
the registry at the time of restore point creation.
-6-
Figure 4: Directory listing of snapshot directory
Compression
The snapshot directory, which contains “snapshots” of the registry, is compressed using NTFS
compression. Several forensic software products on the market can seamlessly manage the
uncompressing of these files for analysis. Be aware that not all forensic tools have built in NTFS
compression support. While there may be others out there, currently Encase V5 and FTK
support NTFS compression.
Configuration
There are several configuration options available to “tweak” the usage of restore points. These
are stored in the registry under
HKEY_Local_Machine\Software\Microsoft\WindowsNT\CurrentVersion\SystemRestore.
The following is a breakdown of a few of the relevant registry keys and their meanings.
Key Name
Type
CreateFirstRunRP
Default
Configuration
Reg_DWORD 1
DisableSR
DiskPercent
DSMax
Reg_DWORD 0
Reg_DWORD 12
Reg_DWORD 400
DSMin
Reg_DWORD 200
RestoreDiskSpaceError
Reg_DWORD 0
RestoreSafeModeStatus Reg_DWORD 0
-7-
Description
Determines whether or not a
restore point is created when SR is
turned on for the first time.
1=SR is disabled 0= SR is running
Disk percent is the percentage of
disk space in MB allocated to SR.
DS Max is the max allowed disk
space. SR uses the larger of the
two.
The minimum amount of disk
space in MB required for SR to be
running.
Tells the computer to produce an
error message if System Restore is
unsuccessful because of disk space
problems.
Shows whether the last restore
RestoreStatus
Reg_DWORD Key only exists
when a restore
occurs.
RPGlobalInterval
Reg_DWORD 0x15180
RPLifeInterval
Reg_DWORD 0x76a700
RPSessionInterval
Reg_DWORD 0
process was done through safe
mode.
Indicates whether the last restore
processed failed. 0x00 = failed,
0x01 = succeeded, 0x02 =
interrupted.
Amount of time in seconds that SR
waits before creating another
restore point. Default = 24 hours
Amount of time in seconds that SR
keeps restore points before
deleting them. Default = 90 days.
Amount of usage time in seconds
the computer waits before creating
restore points. This is turned off
by default.
Table 1: Restore Point Registry Configuration Settings5
Disabling Monitoring and Restore Point Deletion
If you are doing an investigation on a Windows XP computer and you are not finding any
System Restore point information, it could be because System Restore has been turned off. This
can be checked in the DisableSR registry setting mentioned in the above table. Turning off
System Restore monitoring will remove the System Restore points from the logical file system,
however they may still be recoverable through undelete features in forensic software. Review of
the system event logs will show this and other restore related events that have taken place. The
following are a few of the relevant event ID’s, their corresponding types and descriptions.
Event ID
113
114
115
116
7035
Type
Information
Information
Information
Information
Information
7036
Information
Description
System Restore monitoring was enabled on drive X:\
System Restore monitoring was disabled on drive X:\
System Restore monitoring has been enabled on all drives
System Restore monitoring has been disabled on all drives.
The System Restore Service was successfully sent a Start
control.
The System Restore Service was successfully sent a Stop
control.
Table 2: Restore Point Windows Event Logs
The Change.Log File
The Change Log is the tracking repository for all files saved through the restore process. The
information contained in the file includes the file’s original location in the file system, the
original name of the file, and the name of the file it has been changed to. The difficulty lies in
retrieving this information in a usable format. The file is stored in a binary format and can be
spread across several change.log files for one restore point, so finding the one which has the
information you are looking for can be a somewhat tedious task. The data is most easily
readable in a good hex viewer. We have made this process easier by writing a script to parse out
-8-
the necessary data and output it into a spreadsheet format. This script can be found on our
website, www.MANDIANT.com, under the tools section. The following is a sample of the
output provided by the tool.
\Windows\System32\keylgr.exe
\Windows\System32\sdsini.ini
\Windows\Internet Logs\IAMDB.RDB
\Tools\WebHistorian.msi
A0000628.exe
A0000629.ini
A0000630.RDB
A0000631.msi
Table 3: Sample Change Log Parsing Script Output
Solving the Case
Solving this case requires us to address the following objectives.
1. Confirm or dispel the laptop’s compromise.
2. Determine if compromise lead to loss of credentials.
3. Identify attacker’s method of entry.
4. Identify any malicious code used by the attacker.
5. Construct a timeline of events.
Objective 1&2: Confirm or Dispel Laptop Compromise and Loss of Credentials
Knowing what we now know about System Restore points, we can apply that knowledge to the
case. The forensic examiner had found the sdsini.ini file. Since the file extension used to hide
the keystroke log file was “.ini”, a file extension that is monitored by System Restore, our
investigation takes us to reviewing the contents of the system restore points.
We list all the files in the System Volume Information directory and find a few hundred files with
the .ini extension. To complicate things further, these files are all following the naming scheme
of System Restore, so they are all numbered files starting with the letter A. We have two
options. The first is to guess which .ini files are the keystroke log files. The second is to search
all the change.log files for sdsini and find out which of the numbered files were named sdsini.ini
before they were copied and renamed. You choose to search the change.log file and discover the
following:
Figure 5: Change.log file in a hex editor showing key logger log file renaming.
We know that change.log files are created for each restore point. Searching all the change.log
files in every restore point for the sdsini.ini string enables us to generate a complete mapping of
sdsini.ini files that have been renamed by the system restore process, and now exist under an
obscure name which follows the restore point naming convention. Using the MAC times and the
-9-
RP# folder names, we determine the order in which they were created, and reconstruct the logs
from top to bottom. The end result is over 400 pages of keystrokes spread across 25 files, but
specifically, the key piece of evidence. The following is a portion of the data found on the
compromised machine. Actual information has been changed to protect the identity of the user.
Figure 6: Keystroke log file captured from sdsini.ini file.6
The formatting and content of this file is indicative of a sophisticated keystroke logger output.
This log depicts targeted data collection and complex filtering of unwanted keystrokes to present
only the usable keystrokes to the attacker. The log even shows backspaces (Bsp), Enters (Etr)
and mouse clicks (MC) ensuring data accuracy for the attacker. This piece of information has
confirmed the laptop’s involvement in this case.
Objective 3: Identify Method of Entry
Now that we have confirmed the involvement of the laptop, the search begins for the method of
entry which will hopefully lead us to the malicious code used in the attack.
Part of the incident response process includes a review of Windows event logs and Dr Watson
logs for unexplained crashes and service related errors. Windows event logs contain information
about specific events that have occurred inside windows. These include logons, restarts, and
application installs to name a few. Dr. Watson logs are generated by a Microsoft program
designed to provide information about crashes for debugging purposes. They are both an
excellent source of information when trying to understand past events on the computer.
- 10 -
This time, there was no relevant data in the Windows event logs, but the Dr.Watson log showed
the following:
Figure 7: Dr Watson log file entry showing an application exception. 6
This entry shows us that on 4/29/2006, an application exception occurred in Internet Explorer.
Application exceptions can be attributed to buffer overflows. Dr. Watson logs are accompanied
by the creation of a user.dmp file which captures the process space in memory when an
application crashes. We find the user.dmp file in the %SystemRoot% directory and use the
MAC times from the Dr.Watson log file to verify the user.dmp file is related to the application
exception. The following is an entry from the user.dmp file.
Figure 8: Entry from user.dmp file showing memory space of the application during the exception. 6
The entry above shows us an HTTP GET request was in the process space at the time of the
application exception. The contents of the request show us the user was checking their inbox at
the url http://logicmail.logic.bm . The conclusion can be drawn that the overflow came through
the user’s e-mail account. The method of compromise has been identified.
Objective 4: Finding the Malicious Code
Now that we have identified the method of compromise, we begin the search for the malicious
code. Remember that a review of the normal file system didn’t show any signs of malicious
code. It’s likely that the attacker cleaned up after he transferred the money out of the bank
account, so it’s going to be a challenge to find any relevant data. We did find some evidence in
restore points so it’s best to start with our leads and see where they go.
- 11 -
Logically, the keystroke logger must be executing before it can create logs, so we begin our
search at the restore point directory with the earliest created log file and work our way through
the earlier restore points. Our search reveals several executables. Through static and dynamic
analysis of the unknown binaries, the search is narrowed to one potentially malicious executable
named A0000628.exe, but running it receives no response. Looking for as much information as
possible, we search the change.log file of the restore point where we found the executable. We
determine the programs original name to be keylgr.exe located in C:\WINDOWS\System32\.
Figure 9: Change.log file in a hex editor showing keylgr.exe and its restore point translation.
The above is the relevant contents of the change.log file, which associates the directory and
original name of the file to the obscured file name specified by the System Restore process. We
can see that A0000628.exe is located directly after the c:\windows\system32\ keylgr.exe entry.
We have now confirmed the original location and name of the key logger.
Now that we have the name of the key logger, we do a search for that file name across the drive
and a separate search on the extracted registry, including those from all the restore points. We
do this to acquire additional knowledge about keylgr.exe. We don’t find any references to
keylgr.exe in the current registry, but registry snapshots in the restore points do have findings,
specifically in the
HKEY_Local_Machine\SOFTWARE\Microsoft\Windows\CurrentVersion\Run key. The Run key
is checked during boot by the operating system and executes all the programs listed in the key.
This trick provides the key logger persistence through reboots of the computer. It also indicates
that keylgr.exe was definitely executed.
The fact that references to the Run key were not found in the computers current registry and
keylgr.exe was not found on the file system anywhere except in the restore points, leads us to
believe that the key logger was uninstalled from the computer before the acquisition of the hard
drive took place.
Objective 5: Time Line Creation
With the information above, the time line creation is now trivial. We are now able to associate
times and dates with the following events.
- 12 -
System Exploitation:
To determine the date and time of exploitation, we use the documented time inside the
application exception error located in the Dr.Watson logs. Figure 7 shows this to be 4/29/2006 at
18:17.
Key Logger Installation:
The time keylgr.exe appeared on the file system is the creation date associated with the
executable. Figure 3 gives us a directory listing with the file creation dates. We have
determined through the change.log analysis that keylgr.exe is also A0000628.exe. This file has a
creation time of 4/29/2006 at 14:12 which indicates the time keylgr.exe was uploaded to the
compromised computer.
Keylgr.exe Execution Time:
The first time keylgr.exe was run is identified by the restore point with the lowest number, whose
registry snapshot contained a reference to keylgr.exe. Figure 8 shows a directory listing of the
registry. This is the registry that contained the first existence of this key. The date is shown to
be 4/29/2006 at 22:12. This is not an exact time of execution, but provides us a window of time
between this restore point, and the last.
Keylgr.exe Uninstall Date:
Because the attacker cleaned up his tools after stealing the information he needed, getting the
actual removal time of the executable off the file system is not possible. What can be done is an
analysis of restore points registry snapshots to see when the next snapshot is taken that doesn’t
include the Run key, therefore providing us a time frame instead of the exact time.
Progression of the Key Logging:
The progression of the attack can be seen clearly through the correlation of the creation dates for
the sdsini.ini files in the restore points. They confirm the continuation of the attack from the
period of key logger installation through the uninstall.
Incident Conclusion
Utilizing our incident investigation knowledge and knowing the capabilities of restore points, we
have answered questions about this incident that otherwise seem unanswerable. Without restore
point analysis, the timeframe of attack, and solid proof of the attack method could not have been
identified. As the complexity of systems we protect increases, and the sophistication of attacks
rise, it’s important to continually educate ourselves on every resource available to us during
investigation.
- 13 -
Endnotes
1
The fictional case study used to illustrate the author’s research is loosely based on an actual
investigation conducted by Red Cliff Consulting, now MANDIANT, in 2004. The Senior
Forensic Examiner noted in the text is MANDIANT VP of Research, Curtis Rose. Specifics
about the case have been changed to protect the identities of the parties involved.
- 14 -
References
2
Microsoft Windows XP Restore,
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnwxp/html/windowsxpsystemrestore.asp
3
“Monitored File Extensions” http://msdn.microsoft.com/library/default.asp?url=/library/enus/sr/sr/monitored_file_extensions.asp .
4
Russinovich, Mark, and Solomon, David. Microsoft Windows Internals Fourth Edition.
Redmond: Microsoft Press, 2005.
5
“The Registry Keys and Values for the System Restore Utility”
http://support.microsoft.com/kb/295659/
6
Rose, Curtis. “Limited Forensic Analysis Report in Response to Suspected Computer
Intrusion,” Mandiant. 2004.
- 15 -