Wednesday, August 7, 2013

Daily Blog #45: Understanding the artifacts: User Assist

Hello Reader,
              Turns out Gmail is very complicated so I need more time to parse through the javascript and css to find the right code that is rendering the array of emails to view-able text. If you've already done this feel free to leave me a note in the comments below or via email dcowen@g-cpartners.com. So to buy myself some time I am going to fill in with a blog series I plan to interject through the year called 'Understanding the artifacts'.

If you remember from the the milestone series I talked about the importance of understanding now only what an artifact means but why its created, in these posts I will go into detail on what I understand the original intent of these data structures are. If you understand why a developer create an artifact that you rely on you can better predict not only what data should be stored in it but what other artifacts may exist.

This post will focus on the 'User Assist' artifact. There are alot of good posts that explain how to interpret the User Assist registry keys, such as http://windowsir.blogspot.com/2007/09/more-on-userassist-keys.html. http://www.4n6k.com/2013/05/userassist-forensics-timelines.html,  http://sploited.blogspot.com/2012/12/sans-forensshic-artifact-6-userassist.html,  http://forensicsfromthesausagefactory.blogspot.com/2010/05/prefetch-and-user-assist.html and http://forensicartifacts.com/2010/07/userassist/ are just a few examples of the dearth of information available on what it contains, how to parse it and how to interpret it. What most posts fail to address is why is it there at all?

Most times when someone first gets introduced to digital forensics their first thought is 'my computer is spying on me!'. This may seem to be true but the facts are much more simple, the developers who created the operating system and applications you rely on want to give you the best experience possible. In trying to create a good experience they want to make it easy for you to access the documents and programs you use the most.

The User Assist key was created to fulfill one purpose, to populate the start menu list of recently executed programs so you can quickly load them again. This is why it tracks the last time of execution, the full path to the executable and the amount of times the program has been executed. All so when you click on the start button a dynamically sorted list can show the approximately 15 (excluding the possibility the user pinned an application) programs that the user executes most frequently.

In order to be more efficient the developer decided not to limit the amount of entries that could be stored in the User Assist key as you don't want false statistics if a program drops off for a couple months and then gets frequent usage again. For instance the user went on vacation and started playing games daily and not executed Microsoft Word when the user goes back to work the start menu would only display games and not his work tools if the developer limited the number of entries rather than just storing all of them and shorting by number of executions and time of last execution.

This is also why there are two sets of registry keys for User Assist one for program execution and the other for shortcut execution as they are displayed at different points to the user.

Joachim Metz points out there can be more than two though:
" There can be more than 2. I've seen at least 3 different UserAssist subkeys on XP and Vista, and about 8 different ones on Win 8."
Each separate subkey should be divided by purpose, it will be interesting to see for Windows 8 what they are.

So what can we learn from this?

1. We can debunk the idea that something is 'spying' on the user
2. We can explain to clear terms why an artifact is created to a judge and jury
3. We can explain that these artifacts exist by default and have to exist unless disabled and the functionality disabling it removes
4. We can predict what data should be contained within it

I'll see if I can get my code review done this evening and continue the Web 2.0 forensics series tomorrow.