Live Response Tool collection update (BONUS FEATURE) Searching the Windows Hashes file(s) using VirusTotal

Hello again readers! First off, I want to start the post by announcing that the latest update to the Live Response collection of tools is up; you can download it here:



LiveResponseCollection-Cedarpelta.zip - download here 

MD5: 7bc32091c1e7d773162fbdc9455f6432
SHA256: 2c32984adf2b5b584761f61bd58b61dfc0c62b27b117be40617fa260596d9c63
Updated: September 5, 2019

The main highlight of this update is the inclusion of a Linux script that gathers data from a live system. I still want to add quite a bit of features and functionality to the script but I wanted to get a version out that automates most of the items listed in the Malware Forensics Field Guide to Linux Systems. Some of the items that the script collects are:

• Copy contents of “log” folders
• Determine date on the system
• Determine hostname of the system
• Determine logged in users on the system
• Determine running processes on the system
• Determine process tree (and arguments)
• Determine mounted disks/items
• Review output of disk utility
• Determine loaded kernel extensions
• Determine system uptime
• Determine system environment
• Determine (more detailed) system environment
• Determine OS kernel version
• Determine running process memory usage
• Determine running services
• Determine all loaded modules
• Determine “who” logged in user is
• Review .bash_history for each user
• Determine current network connections
• Determine socket statistics
• Determine list of open files and network connections
• Determine routing table
• Determine ARP table
• Determine network interface information
• Review allowed hosts
• Review denied hosts


This version includes a "Triage" version of the Windows script, but it does not collect a memory dump and it does not run WinAudit, to save some time (creating memory dumps and running WinAudit can take a long time). I still recommend running the full script whenever possible, but sometimes you don't need a memory dump or have the ability to create one with a different tool. I don't want to force you into using something else, so I took those two specific items out.


I also included checklists for each of the operating systems covered by the collection (Windows, OSX, and Linux) and updated a couple of items in the Windows collection like PEStudio and the latest version of FTK Imager. I kept the old version of FTK Imager as well which is why the size is roughly double what the previous size of the zip file was. I will phase out the older version in the next release but I wanted to keep it in case there is an imaging issue with the latest version. Please do not hesitate to provide any feedback (positive or negative) regarding the use of these freely available tools!



SUPER AWESOME BONUS FEATURE!!

I also try to ensure that the data from the tools can be use by other, already existing tools, and last week I encountered a prime example of using the output with a tool to get data that I was looking for.

As you may know, the Windows Live Response script attempts to identify executable files and hash those files which are located in the %WINDIR%\system32 folder, the %SYSTEMDRIVE%\Temp" folder, and ALL files in the %TEMP% folder. The script uses the program md5deep to perform these activities. My goal for this output was to search for the hashes on VirusTotal (or your malware repository of choice) and try to identify possibly malicious files that were on the system(s). 

Fortunately for all of us in the community, Didier Stevens already wrote "virustotal-search.py", a small Python script to perform queries using your own VirusTotal API key, with the added bonus of writing the script so that it can process data that kind of follows a specific format! So rather than having to re-parse the output data, if take the output from md5deep and you run his script with the "-c" flag (for "Comment"), it will look up the hashes and save them to a nice CSV formatted file for you. Then you just have to import the file into Excel, choosing the semi-colon (";") as your delimiter, and you have a nice view of what files have already been scanned to VirusTotal. It even takes into account the API query limits for the standard (free) API keys. Pretty cool!!

Contents of "Hashes_md5_User_TEMP_WindowsPE_and_Dates.txt" file created by the Windows Live Response script using md5deep

Running "virustotal-search,py"

Formatted results of the script. How awesome is that?!?!

Analysis of a Windows 8 Memory Dump with Volatility 2.4 ("The New Hotness")

Hello again readers! Today's blog post is going to cover my initial experiences working with the newest release of volatility (version 2.4) and a Windows 8 memory dump I created using Belkasoft RAMCapture64 (part of the Live Response collection) during my Windo while working on my Bluetooth for data exfiltration series. 

I set this up on a Windows system, so if you are using a *nix system or OSX your set up details will be a little different, but the overall theme is the same.



1) SETUP

First of all, I had to download the 32-bit version of ActiveState Python (currently 2.7.8.10, which you can download here). Once that was downloaded and installed, I navigated to the volatility page to read more about the latest version (version 2.4, which you can read more about here here) which, among other things, now has support for Windows 8. I downloaded both the Volatility 2.4 Windows Standalone Executable and the Volatility 2.4 Windows Python Module Installer. Although I personally prefer to use the Python version that is usually found under "<PYTHONINSTALLPATH>/Scripts/vol.py", I grabbed the standalone version for eventual testing and comparison purposes. Installing the Python modules took just a few seconds and I was ready to move onto the next, but perhaps the most important, steps. According to the volatility website "the distorm3 python module is a requirement for analyzing 64-bit Windows 8 and 2012 raw memory images". So, I had to visit the distorm Google code page and download the latest version and install it. The last setup step was to visit the PyCrypto page and download the latest pycrypto modules to ensure that all of the volatility plug-ins can run with no problem. Without installing PyCrypto I kept getting messages like "The module "Crypto.Hash" is not installed" and "no module _MD4". Installing PyCrypto seemed to alleviate all of those error messages.

To summarize the tools and steps you must perform in order to run the Python version of volatility on a Windows system, you need (at the bare minimum):

ActiveState Python (32-bit)
Volatility 2.4 Windows Python Module Installer
Distorm3 Python Module
PyCrypto Python Module
 -- plus any additional modules that you desire, based off of plugins you run


-----or if you just prefer to use the standalone executable-----
Volatility 2.4 Windows Standalone Executable


2) ANALYSIS

With the release of Windows 8, quite a few changes were made with regards to "how" Windows memory is handled and "how" tools can work with the dumps. Fortunately for us, the volatility crew is keeping a Windows 8/2012 page updated with their findings. 

For the purposes of this post, I only wanted to perform some of the basic analysis steps, so I only cover running the plug-ins "imageinfo", "kdbgscan", and "pslist". However, I will be making another post in the Bluetooth for data exfiltration series as I dig into the memory dump to see what other artifacts that I can extract, so be sure to watch for that!

imageinfo

Time to complete: 1 hour, 53 minutes
Query:
vol.py -f "C:\Users\Brian\Desktop\Memory\ADMIN_LAPTOP_20140520_153701_mem.dmp" imageinfo
Although I already know what the OS profile is from the system that the memory dump came from (Win8SP1x64), I am treating this as if I had no idea and needed the information from "imageinfo" to make the profile determination.

The "imageinfo" results gave me 4 possible suggested profiles and it gave me the kdbg address. However, since I know that with Windows 8/2012 I have to pass the virtual address of the KdCopyDataBlock rather than the address of the kdbg, thanks to the documentation by volatility crew, I need to run kdbgscan against my image.

The 2nd entry under best practices is probably the most important to note when dealing with Windows 8/2012 memory dumps

In order to save some time I would recommend running only "kdbgscan" and waiting for the results from that before running the "imageinfo" plugin if you absolutely need something from "imageinfo" that you cannot get from another plugin. You are going to get more of the information that you need to perform additional analysis from "kdbgscan" than you are from running "imageinfo" on Windows 8/2012 images (and at least in my case, it would have saved nearly two hours of work).

Running the volatility 2.4 and the"imageinfo" plugin against my Windows 8 memory dump

kdbgscan

Time to complete: 1 hour, 30 minutes
Query: 
vol.py -f "C:\Users\Brian\Desktop\Memory\ADMIN_LAPTOP_20140520_153701_mem.dmp" kdbgscan

Running the "kdbgscan" plugin took just over an hour and a half to complete. However, it did find all of the data that I was hoping to find and then some. The plugin provided a total of four results. The results looked to be completely identical except that for each result it used a different profile (Win2012x64, Win8SP0x64, Win2012R2x64, ad Win8SP1x64). I was hoping that I could tell if some of them were incorrect or not based off of the PsActiveProcessHead and the PsLoadedModuleList results (covered in the Art of Memory Forensics book on page 64) but unfortunately this was not the case. I could take a guess and run through each of the profiles, but fortunately the Windows Live Response batch script in the Live Response collection collects a file named "Windows_Version.txt". Based off the data in that file, I know from that my version of Windows is 6.3.9600 (which is the version associated with the profile Win8SP1x64). So using the Live Response collection to help with your incident response/digital forensics case that requires memory dumps might be useful.... (hint hint!)

Running volatility 2.4 and the "kdbgscan" plugin against my Windows 8 memory dump (1 of 2)

Running volatility 2.4 and the "kdbgscan" plugin against my Windows 8 memory dump (2 of 2). My machine was running Windows 8.1 (6.3.9600) so my profile will be "Win8SP1x64" and my kdbg will be "0xf802b65e66d8" (KdCopyDataBlock virtual address)

pslist

Time to complete: 27 seconds
Query: 
vol.py -f "C:\Users\Brian\Desktop\Memory\ADMIN_LAPTOP_20140520_153701_mem.dmp" --profile=Win8SP1x64 --kdbg=0xf802b65e66d8 pslist

Now that I have both the profile and the kdbg (which, remember, is the virtual address of the KdCopyDataBlock on Windows 8/2012 dumps) I can begin my "normal" method of running plug-ins against the memory dump in an attempt to extract data from it. The response time is more along the lines of what I have seen with volatility in the past (just a couple of seconds) once you specify the proper profile and the proper kdbg (which in Windows 8/2012 is really the KdCopyDataBlock location (I really hope you remember that with as many times as that has been said in this post!))

Running volatility 2.4 and the "pslist" plugin against my Windows 8 memory dump. I specified the profile as "Win8SP1x64" and kdbg as "0xf802b65e66d8" (KdCopyDataBlock virtual address)

In my research so far, the main thing that users should be aware of is the processing time that it takes to analyze a Windows 8 memory dump in order to get the information you need to speed up additional analysis. But once you get the information you need from "kdbgscan" (REMEMBER, with Windows 8/2012 you need the pass the kdbg as the virtual address of KdCopyDataBlock) it should increase the processing time of your queries considerably.


3) ????


4) PROFIT



SUMMARY

I am not certain if the longer processing time is with all Windows 8/2012 dumps or just those that are created using Belkasoft RamCapture. I will eventually get around to doing some memory dumps with other tools and seeing how volatility works against that format to see if there is a speed increase. I am also planning to give the standalone executable a more thorough testing but in my initial results the speed of using the executable only compared to the python script looks to be better by a few seconds. I don't know the reasoning for that, but if 

1. I can reliably use the standalone executable to perform some of the functions and don't have to worry about Python dependencies (which seems to be the case),
2. I can script the "standard" memory analysis, and
3. It is faster,

then I will definitely use that more often. I have had better luck using the Python version in the past but that could change, I will keep you updated as my usage continues!! I'd like to thank everyone that has been and is involved with the development of the volatility framework for offering such an awesome tool for the absolutely low cost of free. And pick up your own copy of the "The Art of Memory Forensics" if you haven't already!!

Parsing Windows Live Messenger data from iOS devices

Good afternoon readers, the past couple of weeks have been pretty busy with case work, but thankfully I finally had some time to dig in to some messaging data that I extracted from an iOS device that never seems to have been addressed previously and does not appear to be recognized by any mobile device forensic tools that I have used.

The application I will be covering in this blog post is Windows Live Messenger for iOS devices, which seems to have been discontinued some time in 2013. Unsurprisingly, the application is VERY poorly written and stores data on the device itself in a variety of different ways, which probably explains part of the reason that no one has really dug into this data. As the below image shows, there does not appear to be specific time stamps or even a definitive structure as to how data appears within the application itself, which makes extracting data MUCH more difficult.

Screenshot of Windows Live Messenger on an iOS device. Retrieved 7 August 2014 from http://news.softpedia.com/news/Microsoft-Discontinues-Windows-Live-Messenger-for-iOS-324028.shtml#

I would like to note though, that with all of the research, time, and effort that I put into this post and parsing the data from, I only have one device that has the application on it, so the data stored on a device you encounter may be slightly different. If you have a case where you have access to this data and are willing/able to share it I would much appreciate it in an effort to make the small Perl script that accompanies this blog post. Likewise, if you encounter issues with the script please reach out to me and I will try my best to help! So, now that all of the formalities are out of the way, shall we begin?



The Messenger data itself is stored in a standard location, under the "/private/var/mobile/Applications/com.microsoft.wlx" folder (or the applicable SHA value, if you have not used a tool/method to reconstruct file paths). 

Messenger application folder from iOS device when viewed in X-Ways

There is quite a bit of data in here, but for now we are most interested in files that are stored under the "Documents/cache/Messenger" and under the "Library/Caches/cache/Messenger" folders. It should look something like this:

Contents of "Messenger" folder. The files stored in "Documents/cache/Messenger" and "Library/Caches/cache/Messenger" following the same naming conventions, but contain different data.

The first thing that I want to point out here is that all of the files in these folders have a ".cache" file extension. But of course Microsoft does not follow a standard format for exactly what a ".cache" file should be, so the file header and footer for each of these files are different. The files seem to follow the naming convention of "MSN User ID_filename.cache". The data in the Message History of the files also appear to bring up the possibility that 7-bit encoding is in use, so that opens up an entirely new can of worms for parsing the data. Rather than reverse engineer the entire file structure format, I decided to focus on areas from which I could extract data and have relative confidence in the results.

No discernible, repeatable, standard file header. Foiled again! 

This seems to suggest 7-bit encoding might be in use, at least a little bit. Maybe. I don't know to be 100% honest. 

Thus far I have identified three files that contain chat and/or chat associated data of interest. The files contain "ChatConversations", "MessageHistory", and "Status" in the filename. The "ChatConversations" file seems to contain a listing of the most recent chat sessions, the "MessageHistory" file seems to contain most of the message data, and the "Status" file seems to contain email addresses and usernames of individuals involved in chat sessions as well as the username and email address of the individual who used the Windows Live Messenger application on the device itself. I will cover each of the files individually, but I would also like to note that the script can be given the "-folder" option and it will attempt to recursively (meaning all of the subfolders as well) search to find these files for you.


"Message History"

The message history files seem to follow the format of storing the data in the following format

• User "Friendly Name" (if present)
• Hex character 00 (can occur 1 or 2 times (usually if friendly name is present, but not always))
• Number 1 
• Colon
• Hex character 00 (can occur 1 through 4 times)
• Email Address
• -- sometimes additional printed and non-printed characters --
• Message
• Variety of characters
• Hex character 00 five times in a row

Since I have not found a reliable way to account for if the "Friendly Name" is present or not, I am going to focus on starting the pattern match with the number 1 and the colon, and then greedily match everything up to where the hex character 00 occurs at least five times in a row. The Perl regular expression that the script uses for this matching is:

"\x31\x3A([\w\W]+?)\x00\x00\x00\x00\x00"

Once the script matches that pattern, it then attempts to format the data structure by replacing the "1:" with the term "Email Address", and tries to find the beginning of the message by matching the various patterns that occur after the ".com"  that I have seen in my data. It then attempts to clean up non-printable characters that occur in the message itself as well and then prints the chunks of data out one by one. This method is not 100% foolproof, however if should be more than sufficient in order to allow you to at least get an understanding of the message conversations that have occurred on the device. 

The contents of a modified "Message History" file that match our regular expression that we search for, since the data structure is currently unknown.

The parsed contents of the above file. Different programs recognize different encoding schemes, in this case Notepad translates \x84\x00 as ",,".

"Chat Conversations"

Initially I thought that this file would contain the same data as found in Message History, but interestingly enough, it did not. This seems to contain a list of what appears to be (guessing here, based on the limited amount of data I have to work with) the most recent chat message that was received from an individual that is listed in the Message History file(s). What this means is that if there is a Message History file associated with the username "peter_quill_88@hotmail.com", there will be an entry in the chat conversation folder with that user name and the message as well. So in order to try to be as complete as possible, the script can also handle this file. Fortunately, the data in this file seems to follow a very rough structure, and the data format of this file appears to be:

• Hex characters \xE8\xFF\xFF\xFF
• Variety of characters
• Number 1
• Colon
• Email Address
• Message
• Variety of characters
• Hex characters \x00\x00\x00\xBC

Using this, our regular expression to extract the data is going to be

"\xE8\xFF\xFF\xFF([\w\W]+?)\x00\x00\x00\xBC"

As stated above, the script matches that pattern, it then attempts to format the data structure by replacing the "1:" with the term "Email Address", and tries to find the beginning of the message by matching the various patterns that occur after the ".com"  that I have seen in my data. It then attempts to clean up non-printable characters that occur in the message itself as well and then prints the chunks of data out one by one. I think it bears repeating again that this method is not 100% foolproof, however if should be more than sufficient in order to allow you to at least get an understanding of the message conversation that is stored in this file. 


"Status"

The file containing the term "Status" seems to be the most well-structured file within the data. The data itself seems to be stored in a similar structure as the Chat Conversations file, although there are differences in the data itself.

• Hex characters \xE8\xFF\xFF\xFF
• Variety of characters
• Number 1
• Colon
• Email Address
• Username (if present)
• Microsoft Object (if present)
• Variety of characters
• Hex characters \x00\x00\x00\x01

Just like the above examples, the regular expression that we use to extract data is:

"\xE8\xFF\xFF\xFF([\w\W]+?)\x00\x00\x00\x01"


As with the above examples, the script then takes this data and attempts to clean it up in a user readable fashion. The script replaces the "1:" with the term "Email Address", it attempts to identify is a Username is present and if it is, label it accordingly. It also attempts to digest the embedded Microsoft Object, if present, and format that data into a more easily readable format.


The Script

The script, which is written in Perl (insert obligatory coding language debate comment here), runs by either specifying a "file" or a "folder", which should be used after identifying the Windows Live Messenger application on your iOS device or iOS backup file(s). The application attempts to digest the file based on the fully restored filename (i.e. having "Status", "MessageHistory", or "ChatConversations" in that file). In other words, pointing the script at a raw iOS backup folder will not yield any results since it is looking for specific patterns in the file name, rather than opening every single file and trying to find the data structure(s) the script is looking for.

The output is just regular text, so you can copy/paste from the command prompt or you can save it to a file of your choosing. Be advised that the formatting is not 100% perfect, so it might require some cleanup before presenting the "final" version of the output but it should allow you to get a much better idea of any messages that are stored in the application data since no other mobile forensic tool on the market currently seems able to handle this data.

If you have any questions or issues please do not hesitate to let me know. You can download the script here.


Filename: "wlm_ios_parser.pl"
MD5: c6f3f7d09bea79d69dc3cd60da1fc17a
SHA256: 99380423520b16385dde1493bb46ad439459a221346b65e62451b9a2d7c17bac