Microsoft introduced the concept of registry in its operating system Windows 95. It was introduced to accommodate the growing need of application and system settings that were kept in INI files prior to Win95. Instead of the slow consecutive search, the registry created a fast and robust database for configuration settings. Configurations are stored by applications in configuration files, INI files, or in most cases in the registry. Understanding and monitoring the registry is a crucial skill in digital forensics in order to validate findings and to research application behaviors. In this paper, we examine the process of searching of data and monitoring the results to locate artifacts that can identify if a user searched for keywords in the past and in what order. Knowing the structure of the registry and the concept of hives, we can predict that user typed keywords will be kept user specific, thus if the keywords are saved in the registry, they will be saved in the ntused.dat user specific registry hive. In this paper, we explore this assumption and show the process of locating answers to questions related to specific user activity on Windows 7 Professional operating system.
Value Characteristics: UNICODE encoded binary value
Registry Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery
Registry Hive:C:\Users\<UID>\ntuser.dat
Time of Last Search: Last written time to registry key \Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery
Search Order Determination:MRUListEX data value
Maximum Values Before Overwritten:100
Relevance: User Specific
Value terminator:UNICODE 00 or 0x00, 0x00
MRListEx Terminator:0xFF 0xFF 0xFF 0xFF
The last data value searched can be identified by its name ( index value ) since if the keyword is already in the list, only its index value moved into the first position in MRUListEx. If the keyword is not already in the list, a new name ( index value ) is created as the highest index value in the list.
|
| Index Value |
| Index Value ( 32 bits ) | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| Data | zero | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 |
| MRUListEx | 876543210 |
| Search for | 400 |
| MRUListEx | 487653210 |
| Search for | 700 |
| MRUListEx | 748653210 |
| Search for | 200 |
| MRUListEx | 274865310 |
If a user types in Windows Explorer a keyword, Windows seems to remember previously used keywords and suggest the user those keywords, see image below. That suggests that Windows keeps a list of previously used keywords in a list somewhere.
Figure 1: Suggested keywords as the search term is typed
If the keywords were saved in the registry, we could just do a simple keyword search and locate where Windows keeps these keywords. Unfortunately, it is not the case with these keywords.
Figure 2: Search registry for previously used keywords ( regedit ) If we search for these keywords, the result will be that these keywords are not located in the registry.
Figure 3: Searching for keywords in the registry result in no "hits" at all
In order to minimize the irrelevant data captured by this process, we need to stop any unnecessary processes and applications. Since the operating system can start tasks, updates, and applications can have triggered events, we do not want to capture those events that are not relevant to our tests. We can’t avoid capturing irrelevant events since the operating system needs to function and will make changes to the registry and file system without human interaction. We can only minimize this data and use heuristic approach to identify what is part of the “normal” operating system operation and what is part of the tested procedures. We can build procedures for a test platform as our baseline to use as a testing machine and to create a scientific base of all such tests.
In our case, we’ll be using InCtrl5 (http://www.hiren.info/downloads/freeware-tools/page/8 ). This application will allow us to take a basic snapshot of the operating system registry and file system, perform our test and compare the results to the original snapshot. This way, we will only capture our interaction with the operating system and changes saved as a result. Install InCtrl5 ( on Windows 7 or higher, you might have to run it in compatibility mode )
Figure 4: Set compatibility mode for InCtrl5 executable
Run InCtrl5 as administrator to get access to the whole system and registry.
Run InCtrl5 and adjust the drive list it will monitor. If you have the operating system on C:\ drive and the application will be installed onto the same drive, then only leave C:\ drive listed.
Figure 5: Remove drives from the list that will not be involved in the test procedures
Click GO! To take the baseline snapshot of the system. InCtrl5 will reform the snapshot and will terminate. After the application terminate only perform changes that you need to capture and do not perform any other functions since they will increase the “noise” in the captured data.
Figure 6: After the initial snapshot, the application terminates
Digital Forensics is about recognizing patterns and build hypothesis based on those patterns. So, when you type in keywords to search for in Windows Explorer, type words that have minimum difference and the difference is consecutive in ASCII values. In this case, I have chosen values that are text based, but a single digit is consecutively increasing. The values were typed in were exampleSearch1, exampleSearch2, exampleSearch3, exampleSearch4, exampleSearch5, and exampleSearch6. We can see that Windows must be keeping these keywords in order of type from the latest to the earliest.
After typing the keywords, we have to launch InCtrl5 again, but this time the interface will be different. This time, we have to tell the application that we are completed our installation process. Even though we have not installed anything, our interaction with Windows Explorer will be captured with other events that happened while we type our keywords. Even if we’ll have some “noise” in our capture, it will still be much less data to analyze than analyzing the entire registry.
Click on “Install complete” to finish the process.
Figure 8: After the user interaction, we have to take another snapshot and compare the results to the baseline
The results can be viewed as HTML, CSV, or text. I like to use the HTML for initial review and searching. Click on the HTM radio button and click Launch to open the report in your default browser.
This is where experience in pattern recognition can come handy, but we can see the simple consecutive pattern emerging in the report. I know, I selected digits as my consecutive variables and started it with 1 where 1 is represented as 0x31 in hex value. Therefore, the pattern was easy to recognize as something to do with the keywords that were typed in. We can see that we are looking at HKEY_CURRENT_USER top level key that is user specific and related to the ntuser.dat file of the currently logged in user.
Figure 10: Registry pattern recognized in report
We can take the identified sting and try to convert it to see if we can identify any more patterns. It does look like that each hex value is followed by a double zero that is a pattern for UNICODE characters. Using a quick search on the web, we can identify websites that can help us in this conversion. The results might not be exact, but as you can see below, the keyword string is visible and we can see that we located our keywords.
65, 00, 78, 00, 61, 00, 6D, 00, 70, 00, 6C, 00, 65, 00, 53, 00, 65, 00, 61, 00, 72, 00, 63, 00, 68, 00, 36, 00, 00, 00
Figure 11: Converting Hex to ASCII
Another method we can use is using Notepad++ or any other text editor were we can replace the pattern , 00, with : for other websites to convert for a better looking results.
Figure 12: Use Notepad++ to identify pattern to replace
We can use the software to help us quickly replace the pattern without removing anything relevant to our message.
Figure 13: Global replace of pattern
The result might not be very clean, but we will only have format discrepancies at the end of the string that we can easily correct by hand. This format will work better with tools to convert to ASCII format.
65:78:61:6D:70:6C:65:53:65:61:72:63:68:36
This time, the conversion will be cleaner without extensive extra work and the result is verifiable.
Figure 14: Clean conversion of Hex to ASCII
At this point, we can open the identified registry key and verify our findings by searching for more keywords and pressing F5 in regedit to refresh the screen. We can see that we have located the correct subkey that keeps track of typed keywords, but it keeps the keywords as UNICODE encoded binary string that was not identified by the built in regedit search feature. Now we know why.
Figure 15: Registry Subkey is identified and verified in regedit
We can select the values and delete them for further verification and to learn about the MRUListEx data values.
Figure 16: Clear the registry subkey for further test
Since the identified subkey HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery does not have any other subkeys, so we can identify by the last time this subkey was updated the last time the user searched for a keyword. In order to do that, we can export the registry subkey as text to see the time stamp the registry subkey was last updated.
Figure 17: Export the registry subkey as "text" to reveal the time stamp the user last search for keyword
Key Name: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery
Class Name: <NO CLASS>
Last Write Time: 7/25/2012 - 12:37 PM
Further testing established that index values start at 0 and extend to 99 at that point the list rolls over to itself and starts overwriting keywords at index 0.
Figure 18: Index maximum 99 ( 100 values are listed and then the old values overwritten )
MRUListEx shows 2,1,0 for values typed 1,2,3 where index 0=1, index 1=2, index 2=3.
Typed 1 again, the MRUListEx changed to 0,2,1 or equivalent value list of 1,3,2, moving the value 1 to the front as the most recently searched value.
Typed 2 again, the MRUListEx changed to 1,0,2 or equivalent value list of 2,1,3 moving the value 2 to the front as the most recently searched value.
This is a “blind” example to see if the prediction can be verified. In this case, MRUListEx shows index list of 4,7,6,5,3,…, therefore the last value search was the value at name ( index ) 4, that is 3400 3500 0000. Converting the hex values to UNICODE shows 45 was searched last time.
