Daily Blog #425: How I Use It: Userassist

Hello Reader,
             I'm currently teaching in Abu Dhabi and hanging out with my family at night which means I'm not investing the time to do the next level of MAPI testing I need to do. Instead after the warm reception yesterdays post received I thought I would follow it up with a new series I will add to over time called ' How I Use It'.

Often times we talk about artifacts and evidence sources and how to interpret them, in fact there are so many that most people often forget what they know about them. What we don't often talk about is how we as examiners use that data within their casework to make conclusions or points.

So in this first post in this series of how I use different artifacts I want to talk about the Userassist key. This isn't a new key, it's been around since I first saw it in 2002 and wrote about it in the first Hacking Exposed Computer Forensics book in 2004 but people seem to overlook its usefulness.

Userassist records those programs that a user has executed from the GUI, that I would hope is well known at this point. I've posted about it once in 2013 (https://www.hecfblog.com/2013/08/daily-blog-45-understanding-artifacts.html) and even earlierin 2009 (https://www.hecfblog.com/2009/03/what-did-they-take-when-they-left-part_25.html) both times I didn't really go into detail of what I use it for.

So here are my main analysis points from reviewing this artifacts:

1. What kinds of programs is my suspect executing?

It's difficult to judge the technical proficiency of a suspect from the statements of the people who knew them as their frame of reference in judging their technical abilities is usually focused around how well they use Excel or Outlook. So rather than letting their statements of their abilities to be 'master hackers'  I like to see what kinds of GUI programs they've been executing.

Is it just Office, Outlook and IE?  Or are they loading regedit, going into the command prompt and looking into different system mmc's.  The difference in what they are executing helps me judge the types of artifacts I should expect to find and how closely I need to inspect the dates and artifacts the system is showing me.

In addition I can look for evidence of encryption tools (Veracrypt/Truecrypt), wipers (eraser/bcwipe) and even anti forensics tools (Ccleaner, everyone's favorite). All from one helpful key that will even tell me how many times they've executed it.

2. How far back does the Userassist go? Is it complete?

The Userassist key starts populating data when your first profile is first created and you've logged in for the first time. That means that the history of programs within the key should go back as far as the user profile creation. If there is a gap, especially if it is a large gap, you could be seeing evidence of anti forensics. Start looking for what happened immediately before the gap began to see what could have cleared the data.

Also remember that deleted registry keys, just like deleted files, are not gone just because we delete them. So make sure to use a tool that will show you any potential deleted userassist keys or values. tools like Registry Explorer, YARU and others can expose this data to you while exploring the keys.

3. What email clients is my suspect using?

I'm often looking for my suspects email archives. Rather than guessing what Email client they are using (yes some people don't use Outlook) I can just go to the Userassist key to find out. Unless you have a very interesting suspect using a command line based email reader (pine in windows subsystem for linux?)  the rest are GUI based and should be recorded. If I find no email clients I need to look for what web mail services my suspect is using in their browser history.

4. What web browsers is my suspect using?

Lastly in my normal inspection of the Userassist I'm looking to understand what web browsers by suspect is using. It is not uncommon now for a suspect to be using 2, 3 or even 4 different web browsers on their system during one day. So I use this as a sanity check to make sure:

1. I'm looking for history from all of those browsers, its easy to miss one and focus on the others
2.  I need to make sure my forensic tools support the browser being used, I'm looking at you Maxthon, as its easy to miss a whole browser history cache because you didn't realize the limits of your tool.

So that's the first 4 questions I would answer when reviewing this key and I review this key early in my investigation along with other basic artifacts (execution history, file access and device usage) to start understanding what to expect from this system.

Also Read: Daily Blog #424

Read More

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.

Also Read: Daily Blog #44: Forensic Tips - Shadow Access

Read More

What did they take when they left? Part 2 – Finding out what they ran before they left

Hello Reader,

        In Part 1 we discussed how to determine if a CD was burned. Knowing what application it was burned with and what other tools they ran before they left is also important.

1. User Assist
   

One way to determine this is with the user assist registry keys. Over the years since the user assist registry keys were first discovered (they were included in our windows analysis chapter in 2005) many people have realized the impact it can have on their case. The User Assistance functionality has existed since Windows 2000 and is a registry key divided into two parts that keeps track of recently used programs and files for the start menu.

The user assist registry key exists in each user's ntuser.dat under the key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist

Of which there are multiple keys depending on the version of windows you are examining, two for windows 2000, xp, 2003 and three for windows vista, server 2008, under which you will find a count key that contains the actual data we are looking for. Entries are encoded in rot13 and if you are not using one the tools listed in this blog you will need to decode them yourself to read the entries.

There are multiple tools that support the user assist registry keys for analysis (Accessdata's registry viewer and Didier Stevens tool for instance) that will quickly allow you to see:

1. What program or file was accessed
   
2. How many times the program or file has been accessed through windows explorer
   
3. The last time the program or file was accessed through windows explorer
   

As a simple example, I use Microsoft Office a lot. In fact I write my blog posts in it as it can directly post them to blogger (hopefully catching all my typos). So a decoded user assist entry for Office in my registry looks like this:

"{75048700-EF1F-11D0-9888-006097DEACF9}","20","UEME_RUNPATH:C:\Program Files\Microsoft Office\Office12\WINWORD.EXE","","54","37","3/22/2009 9:25:59 PM"

This entry was found in:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{75048700-EF1F-11D0-9888-006097DEACF9}\Count

Decoding the entry section by section we see:

1. {75048700-EF1F-11D0-9888-006097DEACF9} - the registry key under user assist that this belongs to, data appears to be grouped into categories based on these id's.
   
2. 20 – The index number this number increments as entries are added to this key. In this case this is the 20^th entry logged. If you have a program executed multiple times, such as my Word 2007 program, sorting by the index number will give you an idea of when it was first executed.
   
3. UEME_RUNPATH:C:\Program Files\Microsoft Office\Office12\WINWORD.EXE – This is two pieces of info combined into one:
   
   1. UEME_RUNPATH – This is the prefix for all entries that will give you a full path to the program or file being accessed
      
   2. C:\Program Files\Microsoft Office\Office12\WINWORD.EXE – this is the full path to the program or file executed
      
4. 54 – This is the session, its use is still unknown
   
5. 37 – This is the number of times the program has been executed
   
6. 3/22/2009 9:25:59 PM – This is the last time the key was updated and should be the last time it was executed
   

Going through the user assist then allows us to find out what programs where being executed around the time that for instance a CD was burned. Sorting the entries for that time we can see what was being executed around that time. If there is no corresponding entry you may want to look at the restore points for backups of the ntuser.dat close to time of the burn to find the program executed.

If the user assist keys is missing two things could have occurred

1. The user disabled them, there will be a registry key created showing this if true.
   
2. The user has deleted them, this can be an indication of some type of 'cleaning' tool being run such as Crap Cleaner.
   

Now the user assist registry keys are not the only place to look for what programs have been executed. We don't want to rely solely on access times as they change so easily and don't prove that a program was actually executed. We want to focus on artifacts created because of an execution of which there are two other well documented sets of artifacts that show the actual execution of a program.

1. Shortcut/Lnk Files
   

Stored in several locations depending on its function LNK files so named because of the extension '.LNK' that is given to them. We will discuss LNK files in more detail in the next post as they are an extreme wealth of information but for the purposes of this post it can suffice to say that we can use LNK files to determine if a program was executed through it.

The start menu for each user stored from windows 2000 and on is under the user's profile directory (\documents and settings\<user>\start menu in xp and \users\<user>\start menu in vista and 2008) contains a LNK file for each of the files listed in the user's start menu when the click the start button. So each time a user loads a program through it the modified date of the LNK file will change to reflect it. This also applies to any other instance of the lnk file such as in the quick launch bar or on the desktop.

So for instance my Office 2007 LNK file in the start menu shows a created time of 11/24/2008 which is when I installed office 2007 on this computer. The modification date is 3/22/09 9:25pm which is the last time I used the LNK file to load up office 2007. You can see that the prefetch reference below says 9:26pm, it takes a couple second between the time I clicked the LNK and when the prefetch file gets created.

1. Prefetch Files
   

Stored in the \Windows\Prefetch directory there is one .pf file for each of a max of 128 programs and the last modified time is updated each time the program is executed. The Forensic Wiki has a nice write up on prefetch files. There are several tools out there for parsing prefect files, one that is free is part of the Windows File Analyzer program. If I were to analyze the prefetch file for Office 2007 I would see the following:

File name: WINWORD.EXE-6AC9169C.pf

Last loaded: 3/22/09 and 9:26PM

This is when I started writing this blog post, it's been a couple days of research catching up on old topics to see what people have figured out.

So the prefetch file is a third correlation point we can use to determine if and when a program has been executed.

1. Conclusion
   

So we now have three separate sources on a typical Windows system that we can use to determine what programs had been executed (the first and last times), when and how many times they have been executed. These are not the only places we can look for this information but they are three of the most reliable due to the nature of their creation and use. If you find that all of this data is missing then it becomes almost certain that either

1. The system is being reimaged each time it reboots/logs in (some public access terminals do this)
   
2. A cleaning/wiping tool has been run
   

I plan to make a post on how to determine what a user has wiped after this series but if a cleaning tool has not been run one or all of these sources will allow you to state for a fact what program was executed to:

1. Run a backup program (such as the ones that are packaged with some external hard drives like retrospect)
   
2. Burn a CD
   
3. Run an ftp program
   
4. Access some kind of archiving or copy tool
   

Which will then lead to the next question and our next post in the series : Part 3 - Where did it go and what did they take?

Also Read - Links to All parts: 

What did they take when they left? Part 4 (External Devices) - Where did it go and what did they take?

What did they take when they left? Part 3 - Where did it go and what did they take?

What did they take when they left? Part 2 – Finding out what they ran before they left

What did they take when they left? Part 1 - Detecting CD Burning

Read More