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.


No comments:

Post a Comment