Helpful Navigation Toolbar

Friday, February 21, 2014

Using Prefetch Files to Perform Triage Analysis

The topic of today's post is one of the methods that I use to help determine which system(s) are possibly infected with malware as quickly as possible. I will not cover the basic structure and formatting of the Windows Prefetch files, as there are PLENTY of topics on that. If you want to learn more, I highly recommend starting with the Prefetch entry on the ForensicsWiki if you are not familiar with the structure of Prefetch files. To be very brief, when an executable is run on a system, the Windows operating system usually creates a Prefetch file associated with that executable and records everything that the executable accesses within 10 seconds of starting. Admittedly there are MANY factors that can change what data is recorded in the Prefetch files, including malware itself, and, in some cases like systems with solid state drives, sometimes Prefetch files don't exist at all.

But once again, this post is not going to be focusing on that. This post is going to go through a quick-walk through of collecting data from a system and using some tools to help parse out data that we want. This post will cover analyzing Prefetch files to determine when applications were run and what possible files of interest that the application(s) accessed. For this scenario I pulled the Prefetch files from a system that was infected with a ZeuS variant (md5: 611614c95937e1a53394d31a3c6e18be)

After we gather the Prefetch files from the system(s), we can start our analysis. In order to accomplish this, I wrote a small Perl script, which you can download here. (md5: 3f5f48f5bfe52d97a71d01b7874e94b8)(SHA1: c166f04b8130760ead947fb49d2919e40c65a93a)

The only non-standard module required to run it is IO:All, which is a great file system module that you should be using if you are not! Please feel free to make any modifications or adjustments to my code as well, but if you have any ideas for improvement please share!! I decided to take the time to write this script, rather than relying on other tools, for two reasons. The first is that I wanted to be able to try to pull out files of interest (files in user directories, temp directories, files ending in .txt and .dat, etc.) quickly rather than having to sort through lots of text. For example, the output of the raw data (954KB) is quite a bit more than the possible files of interest data (160KB). 

File size comparison of all Prefetch file data (-alldata), compared to files of interest (-foi), run with no flags (which happen to be the same size in this case) and Prefetch file metadata (-pfmetadata). Hooray data reduction!

The second reason is that I often try to carve Prefetch files from unallocated space in an effort to try to determine historical execution times and I haven't found a tool that will parse partial Prefetch files that well (you can run my script with the -pfmetadata flag and it will only pull out filenames, OS version, times run, and last run time(s)). This can be useful when trying to determine possibly how long something had been present without solely relying on system timestamps.

My Excel Prefetch entries on a Windows 8.1 laptop

As we go through the output of the script, one item in particular interest jumps out as being strange. There is a file named "PO.exe" that was executed one time under the file path "\DEVICE\HARDDISKVOLUME1\USERS\ROCKET_RACCOON\APPDATA\ROAMING\TUTMGIFSFYPBW\PO.EXE". file of interest output for "PO.exe"

This seems like an oddly named folder, so I browsed to that directory and, sure enough, I found a file named "PO.exe" under that path.  I also found a registry entry for "PO.exe", under the "HKCU\Software\Microsoft\Windows\CurrentVersion\Run\PO" path, which is a method of persistence that both malicious and non-malicious programs can utilize on a Windows machine. Additionally, a check of the hash on VirusTotal shows that the file is indeed malicious. 

38/48 detection ratio, from 5 months ago!

Taking a look at Prefetch files can lead an examiner in the right direction of trying to determine if a device is compromised or not. While it is not always a 100% definitive answer, looking at Prefetch files can be a another method that an examiner can use when trying find the evil that may reside on a device. It is part of the reason that I included Prefetch file copying in my Windows Live Response tool set. I hope that this quick walk through has been insightful and hopefully you can try to use a similar methodology on cases you may encounter! 

PS: Be sure to make a copy of the contents of the Prefetch folder and run the script against that location. It will not work against the contents of the Prefetch folder on a live machine. Once again, why I included Prefetch copying as part of the Windows Live Response tools!

Tuesday, February 11, 2014

Small update to Windows Live Response tools

Good news everyone!! I added PeStudio 8.06 and Last Activity View to the latest version of the Windows Live Response tools. Last Activity View runs without any user interaction when run as an Administrator, so I put it in that section of the batch script rather than having it run in the non-Administrative privileges portion.

For more about PeStudio please click here
For more about Last Activity View please click here

Last Activity View seems to add some additional Unicode characters into the output from time to time so it is not 100% reliable, but it can help give you some insight to what activities occurred on the system(s) prior to running the Windows Live Response tools.

Browsing to the Chewbacca malware, as seen with Last Activity View - download here 

MD5: 8603e36be474e8b69c652e5dc86adc2e
SHA-256: ec79422ce2e7218a7bc57b0caf52a5eae2eca98810ac466dddac1115aade493e 

Updated: December 12, 2016

Thursday, February 6, 2014

Chewbacca vs. Open Source Tools (maybe this should be a theme?)

You have probably heard of the "Chewbacca" POS malware that uses TOR (The Onion Router) (aka "anonymous web traffic") as a way to exfiltrate data from the system. If you have not read the Securelist blog post I definitely recommend it. It is, by far, the best post that I have seen on this malware to date. While the development of another way of exfiltration is interesting, the RAM scraping and persistence method that the malware used is very basic, and in testing, it did not even run "properly". Attackers will use tactics that are only advanced as they need to be in order to exfiltrate data. In most environments, attackers can probably gain remote access to the system(s) and exfiltration is often nothing more than uploading files to an online storage site like Mega, Dropbox, Box, WeTransfer, etc. Attackers will not use advanced exfiltration mechanisms if they can simply remotely log into a system and upload data to a site like WeTransfer.

I was able to get my hands on a sample of malware thanks to Brian Baskin (malware reverse-engineer extraordinaire, Ghetto Forensics creator, all around good guy, and a HUGE contributor to a lot of the details in this post). After snagging the sample, I performed some basic analysis (using the same methodology that I used for the Target malware). Interestingly enough, the malware would not fully run on my Malware Box of Evil (MBE), which currently runs Windows XP, as consistently got the exception error listed below. It is possible that this is because the malware was designed for a later version of Windows, as both the esteemed Brian Baskin and myself performed a variety of tests and determined that the malware would work on other versions of Windows, including Server 2003, Server 2008, Vista, and Windows 7. (AUTHOR NOTE: Please see "Additional Research" at the end of the post that covers more details of how the malware works on XP/WEPOS.)

I first loaded the malware into PeStudio and found, beyond the basic items of interest, the regular expression the malware uses for searching for Track1 and Track2 data. This regular expression varied slightly compared to previous versions of malware that I have seen (most likely to account for more non-US track data (shorter credit card numbers starting with only 13 digits)) but it still performs the same basic function. 

Chewbacca file info in PeStudio. Note the hashes, as they are the same as in spoolsv.exe

Chewbacca searching for Track1 and Track2 regular expressions. Note the hard-coded URL as well!

Only this time, when the data is found, it is supposed to exfiltrate the data to the hard coded URL automatically via TOR, using tor.exe, which is included with the malware. 


Once again, because of the unhandled exception I could not get the malware to fully run on the MBE, all it did is made an exact copy of itself  to "%AllUsersProfile%\Start Menu\Programs\Startup\spoolsv.exe"

Windows XP spoolsv.exe startup location
PeStudio 8.05 file information. Hashes are the same on Chewbacca and spoolsv.exe

The expected keylogger file "system.log" was not created (in fact no additional files were created) and there did not appear to be any attempted outbound connections. I verified this by running Noriben (created by the aforementioned Brian Baskin).

Noriben created processes and created files of partially run Chewbacca malware

I even allowed the MBE to connect to the interwebs (through an anonymous connection, of course) in an effort to see if an actual connection was needed and I got the same unhandled exception error.

Unhandled exception error message on Malware Box of Evil when trying to run Chewbacca. RUUUUUrhrGUGUGHRhghghghrRURURUghGHrrrrrr!


On Windows 7, the output was more along the lines of what was originally expected after reading the Securelist post. In this instance, the executable again copied itself to spoolsv.exe under "%AllUsersProfile%\Start Menu\Programs\Startup" (which performs the same persistence functionality, but the path is different on newer Windows systems), deleted the original "chewbacca.exe" file (a very common malware characteristic), attempted to connect to "", and created the keylogger file, in the %TEMP% folder (on Windows 7 it is "C:\Users\<USERNAME>\AppData\Local\Temp"). All of this data was easily presented to me, with my limited malware reverse engineering background, by Noriben (thanks again Brian!)

Noriben output of Chewbacca on Windows 7

Windows7 spoolsv.exe startup location
Chewbacca is gone!
Attempted to connect to
system.log keylogger location and file contents

PeStudio Update: I shared some of the strings information with Marc yesterday and he updated PeStudio so now the Track1 and Track2 data regular expressions (and other strings of interest) present in this sample are blacklisted. PeStudio also now pulls out the default icon of a possible malware sample as well, which is one of my "quick triage" tricks to try to determine if any executables on a system might be malicious. Definitely go and download PeStudio 8.06 if you haven't already!!

PeStudio 8.06 blacklisted strings. Some (but not all) of the key ones from Chewbacca are highlighted


Additional research shows the unhandled exception error may have a combination of the malware not running properly and as a result of DeepFreeze, which I run on the MBE in order to get the system back to an original state after looking at malware and other test environment fun! When Chewbacca was run on a Windows XP virtual machine and the WEPOS virtual machine, the malware ran, made a copy of itself named spoolsv.exe the Start Menu folder, attempted to connect to, however, it did not start the system.log keylogger or delete the original chewbacca.exe. After rebooting the systems the keylogging did start, which was saved in system.log, however the original executable remained. Brian also noted that "when the malware sample is run, it does a check to see if it is run with an argument (a file path). If there is no argument, it copies itself to spoolsv.exe and runs the new copy of itself with an argument of the original file's path. If there is an argument, the malware will delete the argument (file path) and continue. It could be crashing before the original running of the chewbacca.exe is complete, or it could be crashing before the deletion of the original file (or argument) is complete."

Thanks to this malware, I also acquired the WEPOS and POSReady2009 operating systems to install on the MBE in order to better replicate a POS environment and watch how malware performs in those environments. It will definitely be interesting to see if more malware is created specifically to target newer operating systems as Windows XP nears the end of life (WEPOS is supposed to be supported through 2020, although Windows XP Embedded and Server 2003 Embedded are supposed to have support only through 2016 and 2018, respectively).

Based on the testing that Brian and I performed, if the environment was running Windows XP or the original Windows Embedded Point of Service (WEPOS) version 1.0 through 1.3, the malware will not fully work (delete the original chewbacca.exe file, start scanning memory for Track1 and Track2 data, etc.) until the system is rebooted. It will only create spoolsv.exe in the "%AllUsersProfile%\Start Menu\Programs\Startup" location, but the system has to be rebooted in order for the malware to create the keylogger and begin scraping memory for Track1 and Track2 data.

Brian also made an interesting comment while reviewing this piece of malware. In his long and illustrious career of reverse engineering malware samples, this is the first piece of malware he has ever personally encountered that was created using Free Pascal Compiler (that used actual Pascal) and was, quote, "definitely weird". So Chewbacca has that going for it, which is nice :) 

Angry Birds Chewbacca, Lego Chewbacca, and dog chew toy Chewbacca.

Tuesday, February 4, 2014

Automating Initial Data Gathering for Windows Live Response

This blog post will cover something that I have often encountered throughout my career in the DFIR field and my (small) contribution to try to alleviate the issue. The typical commercial incident response scenario kind of follows this order:

1) Receive frantic call along the lines of "we have been hacked"
2) Calm <client> down, try to determine what all they know
3) Ask <client> what the size of their environment is
4) Explain size will likely determine cost/length of engagement
5) Attempt to have client do initial data gathering of volatile data 
6) ..... <awkward silence>

Well, good news everyone!! I've been working for quite some time on trying to automate the initial data gathering in a client environment and I finally think it is ready to be widely shared, especially since it is just a collection of tools and a batch script that runs the tools. I present to you <drum roll please> ... the Windows Live Response collection!

That is right! Now, you can simply send your client a zip file or point them to a download link, have them put the file(s) onto an external drive of some sort, let them run the batch script, and allow them to sit back as the data is gathered automagically! I am quite sure that there are similar programs out there, I know Michael Ahrendt did quite a bit of work on Triage-IR in the past, and I am sure that some of you may have something similar, so by no means am I trying to re-invent the wheel. I am merely sharing what I have been working on automating/collecting during my incident response process. The batch script automates the collection/creation of:

  • Memory dump (using Belkasoft RAM Capture) (if run with Admin privileges)
  • Prefetch file copying (if run with Admin privileges)
  • Network connections
  • Default gateway correlation (more on this in a future blog post)
  • System versions
  • Time/date settings
  • Running processes
  • Loaded dlls
  • Runs (and cleans up after) some SysInternals tools
  • And many, many more! - download here 

MD5: 8603e36be474e8b69c652e5dc86adc2e
SHA-256: ec79422ce2e7218a7bc57b0caf52a5eae2eca98810ac466dddac1115aade493e 

Updated: December 12, 2016

(Thanks to @The_IMOL for pointing out I didn't include the hashes for comparison sake!)

Outside of the tools the scripts uses, I also included several other utilities including PeStudio from Marc Ochsenmeier. Once again, please feel free to add additional tools/methods as you see fit!

Fortunately, the collection comes with the "Compromised Windows System Live Data Gathering Checklist" which details each of the commands, and the command syntax, that the script runs. (ONE IMPORTANT NOTE: In order to run nmap, winpcap is installed on the system. I originally included the script to uninstall it, but that requires user interaction, which I wanted to limit. You can take it out if you wish, or you can uninstall it manually (or keep it on there for future use, the choice is up to you.)) 

My typical usage scenario is I first put the tools on an external drive, usually a large capacity flash drive, or if I am also going to create a disk image, an external USB hard drive. (If the system is using Comodo or other sandbox/isolating AV, I will ensure that it is not sandboxed/isolated)(I love that Comodo tries to protect me from myself!) Then I run the script either as Administrator or with normal privileges (which the script determines for you), and then sit back while the data collection happens. I've had the best success using the Belkasoft RAM Capture tool, as I highlighted in my RAM collection tool post, plus it is free and works on every Windows system that I have ever encountered, including Windows 8.1.

I did not attempt to conceal what the script does or anything like that and would very much enjoy hearing additional items to include, exclude, or hearing about modifications that you make to it in order to make it more suited for your environment. 

My eventual goal is to include all of the executables themselves in this collection, so if for example "ipconfig.exe" has been replaced with a malicious executable, you don't have to worry about additional issues. I would also like to create a script that parses through the results of the data and attempts to identify possible areas of interest to focus on (more on that in a future post too, specifically Prefetch files). I am also working on creating similar scripts/collections for the OSX and *nix environments, but since I encounter Windows more often than the other operating systems, I decided to focus my efforts more on the Windows side, for now.

I chose the Mega site for hosting this download because it has the widest available "free" bandwidth that I could find (10GB every 30 minutes). I used this script while running through my Target malware research as well as several "real-world" cases that I have worked. I have been tweaking and making adjustments ever since the first basic version I threw together, and based off of feedback will continue to add new features and make improvements.

I want to again thank Mari DeGrazia and Adrian Leong for the extensive testing that they performed on this script and dealing with my emails and chats at odd hours with bug/issue fixes. By all means please feel free to make any changes and/or modifications to the script and add any additional tools that you want. If you would like to know a little bit more there are plenty of great resources, one of the online resources that was recommended to me was Rob van der Woude's Batch scripting pages.

I hope that you find this post and the tool useful and insightful. If you have any questions/comments/feedback/grumblings/gripes/etc. please feel free to reach out to me through the comments, drop me an email, or however you with to communicate! This collection will also be one of the topics that I will be discussing on this weeks Forensic Lunch, so be sure to tune in on Friday afternoon!