Wednesday, 23 May 2012

Timelines continued: Log2Timeline for Beginners

I've had a great response from the community in regards to my last tutorial posted 'Forensic Timeline for Beginners: Part 3'. Thanks go out again to Harlan and the SANS Digital Forensic Blog for bringing attention to my posts. For quite some time now I've wanted to learn the tool Log2Timeline which is written by Kristinn Gudjonsson and is highly regarded within the community for producing timelines. One of the reasons why I've preferred the WFAT Timeline tools written by Harlan so far is because they can be run against a live machine, with the use of some additional tools, and it provides the analyst with the ability to add only required information to their timeline.

Through the post today I'll investigate how we use Log2Timeline and hopefully we'll also be able to address some of the issues above and identify some methods for gaining more granularity over the input into our timeline. I'd like to begin by using Log2Timeline to create a timeline of the image that we've been using in the previous tutorials and that way we have the ability to compare the two tools. At this point I'll be following a great guide posted by Rob Lee on the SANS Digital Forensics blog (here) on how to use Log2Timeline and at the end we'll have a timeline output file. This output file will however be a dump of everything Log2Timeline discovers, based on the input it accepts, and I'm interested to see whether as an analyst this is overwhelming or whether it adds some benefit and context to our investigations.

For this tutorial I'll be using the SANS Investigate Forensic Toolkit or SIFT for short which is available here. I've also installed Log2Timeline on my windows machine using the guide provided on the official website. At this point I don't believe there are any differences but I haven't extensively tested either, if you'd like to use windows then you can follow the guide posted here.

Firstly I copied across our downloaded forensic image to the SIFT virtual machine I have running. In order to mount the drive the SIFT virtual machine provides us with a tool called mount_ewf. This tool allows us to mount EWF files even if they are compressed of split. I ran the following command to mount the drive.

 mount_ewf.py WinXP2.E01 /mnt/ewf  
 Using libewf-20111015. Tested with libewf-20080501.  

Once the above command runs successfully you can navigate to the mount location using the following commands. I also ran the ls command to show the contents of the mount location.

 root@SIFT-Workstation:/home/sansforensics/Desktop# cd /mnt/ewf/  
 root@SIFT-Workstation:/mnt/ewf# ls  
 WinXP2 WinXP2.txt  

Running the 'more' command over the WinXP2.txt file will output the contents to standard output.

 root@SIFT-Workstation:/mnt/ewf# more WinXP2.txt  
 # Description: WinXP  
 # Case number: Case 1  
 # Examiner name: Mueller  
 # Evidence number: WinXP  
 # Acquiry date: 2008-01-17T01:05:46  
 # System date: 2008-01-17T01:05:46  
 # Operating system used: Vista  
 # Software version used: 6.8  


At this point we are ready to run Log2Timeline over our mounted image. From the same directory I ran the following command

 root@SIFT-Workstation:/mnt/ewf# log2timeline-sift -z EST5EDT -i WinXP2  
 Image file (WinXP2) has not been mounted. Do you want me to mount it for you? [y|n]: y  
 No partition nr. has been provided, attempting to print it out.  
 Is this a disk image file? Or is it perhaps a partition image?  
 This doesn't look like a disk image file, if this is a partition image (which it looks like), please re-run the tool with the parameter -p 0.  
 Example: log2timeline-sift -p 0 -i IMAGE_FILE  

As you can see from the output above Log2Timeline has determined that we're running against a partition based image file instead of a disk image file and has offered us the example solution using the -p command instead.

I ran the command above again using the -p option istead. The command is as follows.

 root@SIFT-Workstation:/mnt/ewf# log2timeline-sift -z EST5EDT -p 0 -i WinXP2  
 Image file (WinXP2) has not been mounted. Do you want me to mount it for you? [y|n]: y  
 This is a partition image, let's attempt mounting it directly.  
 Image file mounted successfully as /mnt/windows_mount  
 [LOG2TIMELINE-SIFT] MFT directly callable, no need for special parsing.  
 [PreProcessing] Unable to determine the default browser for user vmware  
 [PreProcessing] Unable to determine the default browser for user administrator  
 [PreProcessing] Unable to determine the default browser for user default user  
 [PreProcessing] Unable to determine the default browser for user networkservice  
 [PreProcessing] Unable to determine the default browser for user localservice  
 [PreProcessing] Hostname is set to REG-OIPK81M2WC8  
 [PreProcessing] The timezone according to registry is: (PST) Pacific Standard Time  
 [PreProcessing] The timezone settings are NOT overwritten so the settings might have to be adjusted.  
 [PreProcessing] The default system browser is: : IEXPLORE.EXE ("C:\Program Files\Internet Explorer\iexplore.exe" -nohome)  
 Loading output file: csv  
 Unable to open /mnt/windows_mount/$Extend/$ObjId  
 Unable to open /mnt/windows_mount/$Extend/$Quota  
 Unable to open /mnt/windows_mount/$Extend/$Reparse  
 Unable to open /mnt/windows_mount/$Secure  
 umount: /mnt/windows_mount: device is busy.  
     (In some cases useful info about processes that use  
      the device is found by lsof(8) or fuser(1))  

At this point I was slightly confused as I saw a number of errors in the output of log2timeline and automatically presumed that the tool had not completed successfully. It was only until I went and read the SANS tutorial again that I realised this was normal output of the tool and an analyst should expect to see a number of errors while parsing their image. Also from the output above I'd realised that I'd entered in the incorrect time and I needed to amend my command once again to ensure I entered the correct timezone otherwise it could confuse our investigations.

I wasn't sure at this point what the correct option was for PST so I used the following command to identify an appropriate -z option.

 log2timeline -z list | more  

I tried to use the log2timeline-sift version with the -z list option however it didn't accept this command. I then decided to try the standard log2timeline -z list option and I successfully produced a list of the accepted timezones. Again I piped my output to the more command so that I can slowly review the output.

I ran log2timeline again in the hope of producing our a bodyfile output file. I used UTC as my timezone. I was still a little confused on the correct timezone to use at this point but decided to move on and compare times against my original timeline created in the previous tutorials. That is one of the benefits of using a number of tools in your investigations so that you can clarify the results from both and identify any issues you might have with the tools or the commands you've run. Below is the output of this command.

 root@SIFT-Workstation:/mnt/ewf# log2timeline-sift -z UTC -p 0 -i WinXP2  
 [LOG2TIMELINE-SIFT] MFT directly callable, no need for special parsing.  
 [PreProcessing] Unable to determine the default browser for user vmware  
 [PreProcessing] Unable to determine the default browser for user administrator  
 [PreProcessing] Unable to determine the default browser for user default user  
 [PreProcessing] Unable to determine the default browser for user networkservice  
 [PreProcessing] Unable to determine the default browser for user localservice  
 [PreProcessing] Hostname is set to REG-OIPK81M2WC8  
 [PreProcessing] The timezone according to registry is: (PST) Pacific Standard Time  
 [PreProcessing] The chosen timezone does NOT match the one in the registry, changing values.  
 [PreProcessing] Time zone changed to: PST8PDT.  
 [PreProcessing] The default system browser is: : IEXPLORE.EXE ("C:\Program Files\Internet Explorer\iexplore.exe" -nohome)  
 Loading output file: csv  
 Unable to open /mnt/windows_mount/$Extend/$ObjId  
 Unable to open /mnt/windows_mount/$Extend/$Quota  
 Unable to open /mnt/windows_mount/$Extend/$Reparse  
 Unable to open /mnt/windows_mount/$Secure  
 Could not open the restore point file: /mnt/windows_mount/System Volume Information/_restore{00D8A395-89D5-46B8-A850-E02B0F637CE5}/RP0/rp.log  
 umount: /mnt/windows_mount: device is busy.  
     (In some cases useful info about processes that use  
      the device is found by lsof(8) or fuser(1))  


At this point we have a body file and the sift workstation places the output of the above command in the following folder '/cases/timeline-output-folder/'. I navigated to this folder and then ran the following command.

 root@SIFT-Workstation:/mnt/ewf# cd /cases/timeline-output-folder/  
 root@SIFT-Workstation:/cases/timeline-output-folder# l2t_process -b WinXP2_bodyfile.txt > WinXP2_bodyfile.txt.csv  
 Total number of events that fit into the filter (got printed) = 182943  
 Total number of duplicate entries removed = 114822  
 Total number of events skipped due to whitelisting = 0  
 Total number of events skipped due to keyword filtering = 0  
 Total number of processed entries = 182943  
 Run time of the tool: 9 sec  

l2t_process in my limited knowledge at this point seems to do the same as Harlan's parse.pl script. It will process our bodyfile and produce our CSV ready for analysis. If you'd like to specify a date period to review then you can do that also however in this case we'll just parse the complete file. Now that we have our file lets take a look at it and see what we find.

Tracing back to the events we found in the previous tutorials I've posted the following screenshot to see how this would look from the perspective of log2timeline.


I traced through and began highlighting the suspicious entries where the malicious files were discovered. I also highlighted entries that I felt were related to the suspicious files such as the firewall changes that we had identified as modified.

I followed my timeline entries through but was surprised to see that at the bottom of my timeline file there were a large number of date entries that didn't seem to be in order after parsing with l2t_process. I've attached the screenshot but I haven't had time to troubleshoot why this might be. Does anybody else understand the reasons behind this?


I'm going to stop this blog entry at this point as my week schedule has been fairly crazy and I need to focus on some other training that I'm undertaking. This tutorial is really just scratching the surface of what log2timeline can do. While writing about log2timeline I also found a number of sites explaining how to enter individual log sources to our timeline in the same way we used WFAT Timeline tools. We also have a pcap file that we could potentially introduce to our timeline using log2timeline and I'm keen to see how this would look and again what context it might add to our investigation. The amount of information that log2timeline provides can be overwhelming from a learners perspective and its important that you can understand the entries within our timeline and not just create the output. I do like the large amount of inputs it can deal with. In particular firefox history, ie history and chrome history I believe might be beneficial when using WFAT Timeline and I'd be interested to see whether this could be completed on a live system. I'll try to cover these topics in future posts.

Once again I hope you gained something from this tutorial and I'll attempt to post more as soon as I find some more time.



Friday, 11 May 2012

Forensic Timeline for beginners - Part 3

Firstly I wanted to apologise for the long delay since I posted Part 2 of the Forensic Timeline for beginner series. As you all understand life is busy at the best of times and unfortunately while you're learning at the same time that you're posting tutorials it can be quite challenging to keep up with regular posts.

Secondly I'd like to thank Harlan Carvey for highlighting Part 1 and 2 of the series and my blog received a large number of hits because of this, so thank you Harlan! To any new readers that may be visiting on a regular basis welcome to the blog and I hope you can get something out of my posts.

Tracking back now to Part 2 of our series we finished up by creating our first timeline in CSV format and in this tutorial we were about to focus on analysing the Timeline. We had identified a number of suspicious files already using RegRipper to assist our investigation and these were going to be used as a starting point for our timeline analysis. Now I have to say that its one thing to be able to understand how to create a timeline and dump as much information into that timeline as possible. However all of that information is worthless if you're unable to make sense of the information within the timeline. At this point I think thats why we're all here to learn how to create timelines and hopefully with practise and experience learn how to better understand the results and identify the actions that have occurred. So on that note lets get started with Part 3.

The two files we discovered were the following

C:\WINDOWS\System32\inetsrv\rpcall.exe
 
UEME_RUNPATH:C:\System Volume Information\_restore{00D8A395-89D5-46B8-A850-E02B0F637CE5}\RP2\snapshot\Repository\FS\sms.exe (1)



I already had the drive mounted with FTKImager, see Part 2 if you need this information, and I quickly navigated to the locations above to see if I could gather a copy of the files. I was unable to find sms.exe however I was able to find rpcall.exe. I copied this to a location on my hard drive and then checked the folder of the exported file. I was unable to see the file that I'd exported so I decided to check the windows folder settings that I had within my Windows 7 virtual machine.


As you can see from the screenshot above I had selected the option to 'hide protected operating system files'. I unchecked this setting and then pressed OK and then I could see the file listed clearly within the directory I'd exported to. I then attempted to upload this file to VirusTotal to confirm whether I'd had any hits on this however I was unable to upload the file as I was told that I did not have access to the file. I ran into some problems at this point as no matter what I attempted I was unable to gain enough access to this file to be able to upload it to Virus Total. Some of the options I tried were
  • Taking ownership of the file
  • Adding additional privileges to the file the account I was logged on with
  • Running command prompt as administrator
  • Running firefox as administrator
I then ran the following command to attempt to remove the system and hidden attribute

 attrib -S -A -R -H rpcall.exe  

Regardless of the above options I was still unable to upload this file successfully to VirusTotal. Any comments on this would be appreciated as I'm sure its something simple. In the meantime I copied the files across to the SANS Forensic Toolkit which realistically was the best place to conduct my examination in the first place. So this is something I'll most likely do in the future. I uploaded the file to both VirusTotal to confirm it was malicious and these are the results. Once I'd determined that the file was malicious I decided to upload the files to Anubis. Anubis is an online sandbox for running files and determining the actions they complete once an executable is run. This can be a fantastic source of information for an analyst trying to identify what might have occurred on the system and also identify other malicious executables. To view the Anubis report click here

Listed below is a summary of the Anubis report



Now that we'd confirmed that the file is malicious we obviously know that we have an incident. One of the areas I noticed in the Anubis report was that the file rpcall.exe modified the firewall permissions. I was hoping that RegRipper would have a plugin that I could use to rip the files that are currently configured within the windows firewall. I tried the following command

 rip.exe -r <MountLetter>:\WINDOWS\system32\config\system  
 -p fw_config > fw_config.txt  
 Launching fw_config v.20080328  
 ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile not found.  

For some reason RegRipper said this registry entry was not found. I'm not sure why this was at this point and decided to move on and try the application ProDiscover. After recently reading Windows Forensic Analysis Toolkit 3rd Edition (WFAT3e) author Harlan Carvey recommends using the tool ProDiscover to view Internet Explorer history and view the registry. I installed the basic edition and used this as an opportunity to play with this tool. I navigated to the entry that RegRipper had identified was not available.




We can see from the screenshot above that RPCALL.exe is an authorised application in the firewall so I presume that the network traffic capture that was listed at ForensicKB will provide some further information on what RPCALL does once connected to the network. At this point I'm going to leave the packet capture for a future tutorial because I believe it deserves its own tutorial.

Lets start by opening our timeline and begin investigating how the file may have become present on the machine. Lets create a quick summary of the information we have so far.


Vmware user ran the following executable


 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)


The run registry key was written at the same time as the above

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


Within my timeline I scrolled down until I found all the entries relating to Friday Jun 18 23:49:49 and start working my way back to the top of my timeline. Each time I discovered an entry associated with the file I highlighted it in orange. I also highlighted any entry that listed a directory that was associated with the malicious files above.



I could see a number of prefetch file entries for SMS.exe and RPCALL.exe. Prefetching enables a system to operate faster by monitoring an application as its executed. The prefetch file is created to identify the components that the application requires and saves this information. When the file is run for a second time it knows where to find the components that the application requires and thefore allows the executable to launch faster and provide the user with a better experience.

Lets take a look at the some of the artifacts of interest within the SMS.exe prefetch file



From the prefetch file I can see that SMS.exe accessed RPCALL.exe when it was executed. I can also see a file called DEL10.bat. I searched for this file through FTKImager however I could not find it. I presume it might be the reason for why I'm unable to find the SMS.exe file and that it most likely deletes the file once its executed sms.exe

Now lets take a look at the RPCALL.exe prefetch file.



I didn't see anything significant in this file except for the fact that the file accessed
.\Temporary Internet Files\Content.IE5\Index.dat
.\History\History.IE5\Index.dat

I presumed there might be some activity within these files that I might be able to view. I decided to use ProDiscover again and this time use the view Internet activity features. I opened the forensic image and navigated to the directories listed above. I right clicked on the folders and selected 'Find Internet Activity'. I then navigated the left hand side menu until I found the option 'Internet History View'. I clicked on each of the results and viewed the Internet history. Below is the screenshot of my results.


The results I found were inconclusive. I couldn't see anything that highlighted itself to me as something a malicious application might attempt to access. What I didn't understand at this point is why the user vmware would have run the sms.exe file from the system restore location and how the file manage to be there in the first place. Was the user trying to do something malicious or was this a case of some malware downloaded or transferred through a USB drive maybe.

I wanted go back to RegRipper and rip the userassist for the administrator user also and see if I could find anything of interest happening with that account. I ran the following command.

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

I retrieved the following output

UserAssist (Active Desktop)
Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{75048700-EF1F-11D0-9888-006097DEACF9}\Count
LastWrite Time Fri Jun 18 19:19:27 2004 (UTC)
Fri Jun 18 19:19:15 2004 (UTC)
    UEME_RUNPATH (1)
    UEME_RUNPATH:C:\RESET5SETUP.EXE (1)
Fri Jun 18 19:17:09 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)


This command highlighted another file, C:\RESET5SETUP.EXE, that gained my interest. I decided to follow the previous process and run the file through VirusTotal and then run the file through Anubis. Click on the links for the results of each. Both of the reports confirmed my suspicion that the files are malicious. Reviewing the Anubis report a number of other files were created when this file was executed.

C:\WINDOWS\system32\REGOBJ.DLL
C:\WINDOWS\system32\reset5.dll
C:\WINDOWS\system32\reset5.exe
C:\WINDOWS\system32\resetservice.exe
C:\WINDOWS\system32\srvany.exe


I decided to review the prefetch files again for each of these files. The prefetch file for reset5.exe had the most interesting artifacts. See the highlighted screenshot below.



There were a number of files again that were of interest which I've highlighted in the screenshot above. I decided to go back and review my timeline and begin highlighting some more entries. Reset4setup.exe ran on Friday June 18 19:19 which is before the initial files we investigated. We have a suspicious file run by the Administrator and suspicious file run by the user vmware user but no real context to why they might have done this.

I thought that I might be able to search my timeline for each of the files and see that earliest time they were created




You can see from the above screenshot that some of the files we have identified have been on the system for a while however this may be due to timestomping. Here are some of the file dates

srvany.exe has been on the system since 3rd of May 2002.
rpcall.exe has been on the system 7th of July 2003

Harlan Carvey has written a tool for the purpose of identifying timestomping called MFT.pl. I started by first exporting the $MFT file from the root of the image using FTKImager. Once again I noticed that the file was a system file and it was hidden so I was able to see it immediately. I ran the following command to change the file attributes.

 attrib -S -H $MFT  

Now that I could view the file I decided to run MFT.pl across the file. I ran the following command


 mft.pl $MFT > mft.txt  

I searched the output of this file for rpcall.exe


We can see that from the section highlighted in orange that we have Modified time of Mon 7 Jul 11:59 and the Born time of Mon Jul 7 2003. The section highlighted in orange from what I can understand is the $Standard_Information ($S_I) attribute which can be modified by the operating system. If we review the section highlighted in red we can see that all of the MACB times have a date of Friday Jun 18 23:49. This section is the $File_Name ($F_N) attribute which supposedly cannot be modified by the OS and you can tell this is the section we are looking at by the FN before the rpcall.exe. So If I understand the output correctly it seems that timestomping has occured because the two sections have different and inconsistent dates. Lets move on.

I've also noticed that when C:\RESET5SETUP.exe was executed the file CACLS.exe was also run immediately afterwards. CACLS can be used to modify permissions and you can view what this application does at the following location here.

So by the end of this tutorial I can see that we have identified malicious files however we don't have a real understanding of how the files came to be present on the workstation and why both users are running malicious files. If anybody has any further views on this I'd love to hear them.

With any luck some of the readers of this post might be able to assist me with some other areas I might have missed and can point me in the right direction. If that does happen I'll continue with Part 4 however if that is not the case I've decided that I'll use tcp dump and wireshark in the next tutorial to analyse the traffic that was generated by rpcall.exe and see if we can identify anything further.

Thanks everything for reading the post and as always I hope you gained something from it.


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.