Tuesday, 1 May 2012

Forensic Timeline for beginners - Part 2

This is a continuation of the Part 1 tutorial located here where we'd begun the process to produce our first timeline. Currently we have an events file which has the file system meta data, event logs and prefetch files included within it. We had some information provided to us in regards to abnormal activity on a workstation and I'd mentioned that we may be able to identify some 'quick wins' in regards to finding areas that malware commonly uses to maintain persistence.

In Part 2 of this tutorial we'll be using RegRipper and a continuation of the WFAT Timeline tools to gather some information from the registry and add this to our events file. By the end of this tutorial we should have created our first timeline file and we can begin focusing on major events that may have occurred within the workstation and hopefully identify some malicious activity and files. I'll attempt to analyse the files and identify how this malware came to be present on the system.

Firstly we do not have any information in regards to which user was logged onto the system and which account the user described in the scenario summary was using. So I'd like to use RegRipper to pull out some of this information and identify the accounts that we'd like to start investigating before we attempt to pull out areas of registry that relate to the areas of persistence. We are able to identify users that have logged onto the system by browsing the 'Documents and Settings' folder within our mounted drive but for this tutorial I believe RegRipper will provide a more valuable and detailed source of information. So lets begin by running RegRipper against our mounted drive from Part 1 of this tutorial.

Once you've downloaded the RegRipper tools located here and extracted them to a directory of your choice I ran the following command to list a summary of each of the plugins that RegRipper has preloaded.

 rip.exe -l | more 

This lists each of the plugins within RegRipper and provides a short summary to let you know what the plugin will do. I've also piped the command to the more command on windows so that I can list just a few items at a time. Press either space or enter to work your way through the list. RegRipper also provides you with options to output the summary of each to csv or you can of course pipe the output to a text file. Some examples of the following

 rip.exe -l > plugins.txt   rip.exe -l -c > plugins.csv  

Going through the plugins quickly I've listed a number of plugins that I'm interested in using for this particular incident. Lets go through each of the plugins and have a look at the output. The first command I decided to use was the SAM plugin file to rip the information from the SAM hive which, as we learnt in our previous registry tutorial,  contains user information. This can be an area of confusion for a beginner as when I first ran the command I tried to use the -p option for using a specific plugin module however I realised that there was the more useful -f option which runs a series of plugins against the SAM hive. In this case the -f option is the same as the -p samparse option however against other hive files the -f option will run a large number of plugins.

 rip.exe -r <MountLetter>:\WINDOWS\system32\config\SAM -f SAM >> sam.txt   Parsed Plugins file.   Launching samparse v.20110303   samparse complete.  

The plugin produced an output file which showed that we have five accounts on this workstation. I've provided a summary of the output and the accounts below including the last login date for each of the accounts.
  • Administrator [500] - Last Login Date : Fri Jun 18 19:18:47 2004 Z
  • Guest [501] - Last Login Date : Never
  • HelpAssistant [1000] - Last Login Date : Never
  • SUPPORT_388945a0 [1002] - Last Login Date : Never
  • vmware [1004] - Last Login Date : Fri Jun 18 23:51:52 2004 Z
From this output the points of interest for me are the Administrator account and the vmware account as the other accounts have never logged onto the system. In particular I'm interested in the vmware account as it has the latest last login date to the system. Also within the previous output file listed are the local security groups within the workstation and in particular I'd like to focus on the built in Administrators group. I'd like to know if the vmware account is also a member of the Administrators group.

Group Name    : Administrators [2]
LastWrite     : Fri Jun 18 18:59:27 2004 Z
Group Comment : Administrators have complete and unrestricted access to the computer
Users :
  S-1-5-21-1123561945-606747145-682003330-1004
  S-1-5-21-1123561945-606747145-682003330-500

I received the above output which shows two accounts. At this point I know the SID for the account ending in 500 is the local administrator account and I'm presuming that account ending 1004 is the vmware account. Looking back at the RegRipper plugins I decide to run another plugin to confirm my assumption.

I decided to run the profilelist plugin against the SOFTWARE hive using the following command

 rip.exe -r <MountLetter>:\WINDOWS\system32\config\SOFTWARE -p profilelist > software_profilelist.txt   Launching profilelist v.20100219  

From the above command I reviewed the output and found the following information

Path      : %SystemDrive%\Documents and Settings\vmware
SID       : S-1-5-21-1123561945-606747145-682003330-1004
LastWrite : Fri Jan 18 00:53:39 2008 (UTC)
LoadTime  : Fri Jun 18 23:51:53 2004 (UTC)

This proved my above assumption and I decided to start focusing on the vmware account. In doing so I decided to look at some of the areas of persistence that I'd spoken about previously and in particular I wanted to review the autorun locations for the vmware user account and see if there was anything of interest. Reviewing the plugin summary output again I found a plugin that I felt would provide this information. I ran the following command using the user_run plugin

 rip.exe -r "<MountLetter>:\documents and settings\vmware\ntuser.dat" -p user_run > user_run-ntuser-vmware.txt   Launching user_run v.20080328  

The command produced the following output.

Software\Microsoft\Windows\CurrentVersion\Run
LastWrite Time Fri Jun 18 23:49:49 2004 (UTC)
    RPC Drivers -> C:\WINDOWS\System32\inetsrv\rpcall.exe


Software\Microsoft\Windows\CurrentVersion\Run has no subkeys.


Based on the output above I was immediately suspicious about the rpcall.exe account due to its location as an autorun. This is not to say that all autoruns are malicious but any executable listed within this location should be treated with a higher priority in your investigation. I decided to quickly google the executable file name and see what was returned within google. The first result I found was one from Threat Expert which showed that rpcall.exe had been involved in two cases and had a 100% strike rate in terms of being a threat (see the report here). So at this point I'm highly suspicious of this file and will conduct further analysis on this a later point but this also provides us with a start point in our events file.

Continuing our investigation of the vmware user account I decided that I wanted to attempt to gather some further information on other activities the account completed. The userassist key has been well documented, by Harlan Carvey and many other industry professionals, to provide a great deal of information on users activity and in particular applications that have been launched. Lets go ahead and run the userassist plugin against our ntuser.dat hive for the vmware account.

 rip.exe -r "<MountLetter>:\documents and settings\vmware\ntuser.dat" -p userassist > vmware-ntuser-userassist.txt   Launching UserAssist (Active Desktop) v.20080726  

The output gathered from the following command is listed below

UserAssist (Active Desktop)
Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{75048700-EF1F-11D0-9888-006097DEACF9}\Count
LastWrite Time Fri Jan 18 00:53:33 2008 (UTC)
Fri Jan 18 00:52:42 2008 (UTC)
    UEME_RUNPATH (7)
    UEME_RUNPATH:C:\WINDOWS\System32\cmd.exe (2)
Fri Jan 18 00:52:34 2008 (UTC)
    UEME_RUNPATH:C:\Program Files\Internet Explorer\iexplore.exe (2)
    UEME_RUNPIDL (2)
    UEME_RUNPIDL:::{2559A1F4-21D7-11D4-BDAF-00C04F60B9F0} (2)
Fri Jan 18 00:52:24 2008 (UTC)
    UEME_RUNCPL (4)
    UEME_RUNCPL:timedate.cpl (4)
Fri Jun 18 23:49:49 2004 (UTC)
    UEME_RUNPATH:C:\System Volume Information\_restore{00D8A395-89D5-46B8-A850-E02B0F637CE5}\RP2\snapshot\Repository\FS\sms.exe (1)
Fri Jun 18 19:17:05 2004 (UTC)
    UEME_RUNPATH:C:\WINDOWS\system32\NOTEPAD.EXE (1)
Fri Jun 18 19:16:36 2004 (UTC)
    UEME_RUNPATH:D:\setup.exe (1)
Fri Jun 18 18:58:37 2004 (UTC)
    UEME_RUNPIDL:C:\Documents and Settings\All Users\Start Menu\Set Program Access and Defaults.lnk (14)
    UEME_RUNPIDL:%csidl2%\MSN Explorer.lnk (13)
    UEME_RUNPIDL:%csidl2%\Windows Media Player.lnk (12)
    UEME_RUNPIDL:%csidl2%\Windows Messenger.lnk (11)
    UEME_RUNPIDL:%csidl2%\Accessories\Tour Windows XP.lnk (10)
    UEME_RUNPIDL:%csidl2%\Accessories\Windows Movie Maker.lnk (9)


As I read through the following output a number of entries stand out to me. Firstly the execution of a file called sms.exe from within a system restore point seems highly unlikely and suspicious as this, to me, does not seem like normal user activity. Secondly I noticed the timedate.cpl is run which can be used to change the time of the computer. This also seems to match the dates I see within this log as sms.exe is run in the year 2004 and soon after timedate.cpl is run and the year changes to 2008. Our timeline file may also show this difference when we review it.

I feel the userassist information would be valuable to our timeline. Fortunately for us Harlan provides us with a secondary plugin to do this called userassist_tln. As you'll see I pipe the output using the '>>' and send the output to our events.txt file that we created in original post.

 rip.exe -r "<MountLetter>:\documents and settings\vmware\ntuser.dat" -p userassist_tln >> events.txt   Launching userassist_tln v.20110516  

I believe I now have enough information to create my initial timeline file. There is however one further command that I'd like to mention which is the regtime_tln plugin. The regtime_tln plugin has the following summary 'Dumps entire hive - all keys sorted by LastWrite time'. The command to use the plugin is the following

 rip.exe -r "<MountLetter>:\vmware\ntuser.dat" -p regtime_tln > vmware-ntuser-regtime_tln.txt   Launching regtime_tln v.20080324  

At this point I've decided to dump the output to its own file instead of our events file. I'd rather focus on a smaller amount of data, as Harlan recommends, and come back to this at a later stage if I feel I need it. If I did decide that this information was important to my investigation I could run the following command to add it to my events file

 type vmware-ntuser-regtime_tln.txt >> events.txt  

In order to create my first timeline I want to run the parse command using the WFAT Timeline tools. As previously mentioned one of my goals is to be able to create a forensic timeline from a live system as well as an offline system. Currently parse is only available as a perl script but no executable is provided. A great tool to convert a perl file to an executable is Perl2Exe which is available here. In order to convert parse.pl to parse.exe run the following command from the Perl2Exe extracted folder

 perl2exe.exe <Directory_Path_For_Timeline>\timeline\parse.pl  


The tool is provided free however the only issue with the free version is that it adds the following output to your file and takes a few seconds longer to run. Keep this in mind when you're reviewing your timeline if you do choose to use this method.

This exe file was created with the evaluation version of Perl2Exe.
For more information visit http://www.indigostar.com
(The full version does not display this message with a 2 second delay.)
...


Lets go ahead and create our timeline file. In this instance I'm going to use the perl script as I have the events file on my local computer and I'm not running it from a batch script.

 parse.pl -f events.txt -c > timeline.csv  

You'll now have your first timeline file created and a number of malicious executables that we can use as a starting point to identify what might have occurred on the workstation.

I'm going to leave the tutorial at this point. In the next tutorial I'm going to review our first timeline file and begin to investigate some of the executables I've found above.  I'm also interested in the large difference between time values from 2004 to 2008 and whether this may be for malicious purposes.

Once again I hope you enjoyed this post and please feel free to comment. As mentioned I'm only a beginner in this field and any advice or comments are appreciated.


No comments:

Post a Comment