Helpful Navigation Toolbar

Monday, August 18, 2014

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: - download here
md5: 399a705c226f6cde37885b8dc07ae4bc
SHA256: 36af4f5aa8a6f738e87725848b03e397e5faa8eb20f9ee2127f2d808250eadca

Upload Date: 15 August 2014

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!


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 "", 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?!?!

Wednesday, August 13, 2014

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.


First of all, I had to download the 32-bit version of ActiveState Python (currently, 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/", 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


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!


Time to complete: 1 hour, 53 minutes
Query: -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


Time to complete: 1 hour, 30 minutes
Query: -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)


Time to complete: 27 seconds
Query: -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 KdCopyDataBlockit should increase the processing time of your queries considerably.

3) ????



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!!

Friday, August 8, 2014

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

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/" 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:


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 "", 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


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. 


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:


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: ""
MD5: c6f3f7d09bea79d69dc3cd60da1fc17a
SHA256: 99380423520b16385dde1493bb46ad439459a221346b65e62451b9a2d7c17bac

Thursday, May 29, 2014

Bluetooth for data exfiltration. Say what?!? Part 4: Some Registry artifacts

Hello again readers and welcome back to another post regarding evidence left behind during Bluetooth data "exfiltration". Today's post is going to focus primarily on Registry artifacts. 

First of all, I want to point out a post made by Russ Taylor regarding Last Modified time updates. The "Last Modified" time stamps on Windows system files are no longer updated like they "used" to be and it is entirely possible to have time stamps from Registry hives and Event Logs (among other files) that are in the past, but the files themselves will have entries from the "future" For example, my NTUSER.dat timestamp was 05/19/2014 at 14:45:17, but the hive had entries from 05/20/2014 15:20:55. Great Scott! <cue Back to the Future music>

NTUSER.dat timestamp shows the "Last Modified" time 05/19/2014 14:45:17

Software-Atheros-VistaAddOn-Devices NTUSER.dat key updated at 05/20/2014 15:20:55. Great Scott!

The issue of "normal" time stamp updating seems to have been first noticed with Windows 7 and  underscores the fact that a forensicator cannot simply rely on file system time stamps alone. In fact, with a couple of lines in PowerShell, you can change timestamps with ease: 

$file = (gi malware.exe);
$file.CreationTime = '8/1/14 12:00AM';
$file.LastWriteTime = '8/1/14 12:00AM';

(Props to Brian Baskin for these exact commands. You may see these again some day....)

(NOTE: I want to test the time stamps out using a program like Triforce to see what additional data it can provide. It is on my list of things to do!)

So, now that we have covered the time stamps next up is covering some of the interesting data contained within the Registry itself.

The first example is in the aforementioned NTUSER.dat hive associated with my user account (which is cleverly named "Brian"). There is quite a bit of data located under the "Software-Atheros-VistaAddOn-Devices" path that looks to be associated with the connection of my Galaxy Note 2 via Bluetooth. I have to dig into the data more (when time permits) to try to figure out exactly "what" information can be determined from the Registry entry(ies). It still doesn't look like there is any evidence of actual "exfiltration" but it is nice to have another item that seems to match pretty closely to the connected device times. 

The Software-Atheros-VistaAddOn-Devices key screenshot, again!

X-Ways Forensics (my forensic analysis tool of choice) also has the ability to carve entries from Registry Hives. This also needs some more digging, as it looks like it is an entry regarding the command and the arguments needed to initiate the Bluetooth connection.

"Path unknown" Registry entry, with Win7UI.exe and the SCH-I605 Bluetooth MAC address

The SOFTWARE hive also had some entries associated with the Bluetooth connection under the path "Microsoft-Device Association Framework-Store" path. This also requires some more investigation, but once again, it does not appear that this shows anything along the lines of exfiltration, but only connections. These timestamps are prior to the timestamps entries that were created in the NTUSER.dat hive.

SOFTWARE entries regarding the Bluetooth connection

So at least we have a little more data that helps correlate some of the connection times, but we still have not found anything definitive that proves "exfil.doc" was indeed transferred from my computer to my phone via Bluetooth. But, the search continues...

Friday, May 23, 2014

Bluetooth for data exfiltration. Say what?!? Part 3: Do you want "TCP" with that?

Please read Part 1 and Part 2 prior to reading this post, as some of the items that are contained in this post are covered more in-depth in the previous posts. I wanted to dig a little deeper into the Bluetooth file transfer to see if I could find some more information. As Micah Norman pointed out, "Knowing Windows, there has got to be something else juicy...". I think that most members of the DFIR community are surprised that there isn't more information stored by the Windows with regards to Bluetooth file transfers. 

So I decided to treat it like malware, and used items like noriben and Process Monitor to try to dig deeper. While I still do not have definitive answers on finding evidence of file transfers, hopefully this can help "catch" and "detect" the possibility of Bluetooth file transfers in your environment.


I expected to have to go through a lot of data contained within the text file output of noriben and I was correct (the file size was 706KB). I could have taken the time to try to filter that data down more but it was just as fast for me to compare the text file with the data within Process Monitor itself, so additional filtering wasn't needed in this case. noriben showed the creation of the processes that I previously covered, but I was surprised to see how little "file" activity actually occurred during the transfer. This falls directly in line with the analysis findings on the disk image, and it appears that most of the data of interest is contained within the memory related files (pagefile, memory dump, etc.).

The cleverly named folder "Bluetooth folder" was created in "C:\Users\Brian\Documents" but there did not appear to be additional data stored in that folder. The file "BtvStack.exe" appeared to be involved with the creation of the "BT Devices" folder so that needed some more investigation too.

Filtered file activity from noriben

noriben also showed a TON of Registry activity, primarily regarding MRU, lnk files, and ShellBags (once again, it is what we kind of expected to see)

Snippet of Registry activity from noriben

Noriben did also show the TCP connections that cports highlighted, so I wanted to use the output of Process Monitor to dig into that a bit more.

Process Monitor

Having identified the main processes of interest in noriben (Win7UI.exe and BtvStack.exe) I filtered the ProcessMonitor output on those two process names. Using the timestamp correlation, it appeared just before the files were sent, a Registry value that is possibly associated with Bluetooth Quality of Service (if my acronym breakout is correct) occurred:

Contents of Process Monitor just prior to sending the file "pandamonium.gif" via Bluetooth

I know that there were TCP connections made from the cports output but ProcessMonitor allowed me to see the actual Send, Copy and Receive operations that were occurring. BtvStack.exe appeared to be reading the file "pandamonium.gif" 4096 bytes at a time. BtvStack.exe also appeared to be sending the data while Win7UI.exe appeared to be Copying and Receiving the data.

Totally Tantalizing TCP activity Batman!

Oddly enough, when I set up a Wireshark capture on my system (on all available interfaces)I did not see any evidence of this activity occurring. cports showed the open ports and Process Monitor showed the TCP transfers, but a Wireshark capture did not appear to see it.

So what does this mean? Quite honestly, I am not 100% certain, and I hope that someone more knowledgeable than I in the ways of network connectivity and protocols can shed some light on the subject. I have a hunch that since the TCP command appears to be from my device to my device Wireshark doesn't process it (once again, I am not certain) or it could be that Windows is misidentifying a Bluetooth connection as TCP, and what both Process Monitor and cports recognizes as a TCP connection is really a Bluetooth connection. Or maybe it is a combination of the two.

In-depth network protocol analysis is not a strong suit of mine and I would really love for someone else to try to dig into it and figure out exactly what is going on here. In the meantime, the "TCP" connection monitoring appears to be one of the most reliable ways to be alerted of a possible Bluetooth file transfer, but even then you may not be able to determine exactly "what" may have been taken. You can use a combination of Process Monitor, Registry/Shellbag analysis, Last Activity View, memory analysis, string searches, lnk file correlation and a whole lot of timeline analysis to try to make an educated best guess.

Thursday, May 22, 2014

Bluetooth for data exfiltration. Say what?!? Part 2: The results


The purpose of this blog post was an attempt to determine what artifacts are present when files are transferred between a Windows 8 laptop and a Samsung Galaxy Note 2. All items and data on this post are presented for educational purposes only.


Quite honestly, you should probably disable Bluetooth on every system and do everything that you possibly can to ensure that users/friends/enemies/nation states/etc have no way to initiate Bluetooth connections to anything in your environment (I would go so far as to uninstall the Bluetooth drivers, programs, etc.). There is VERY little evidence left behind of a Bluetooth file transfer and unless you have an extraordinary amount of oversight into your environment (let's be honest, that excludes 99.9999% of you) it is unlikely that you will be able to find concrete evidence that a Bluetooth file transfer took place. I knew EXACTLY what I "exfiltrated", exactly when I did it, and immediately created a memory dump, ran the Live Response collection, created a disk image, and honestly there are not a whole lot of artifacts present to definitively say I transferred anything from my laptop to my mobile device.


Hello and welcome to part two of a post that delves into the possibility of using Bluetooth for data exfiltration. This post is going to cover the evidence left behind when a user utilizes Bluetooth on a mobile device to exfiltrate data from a system. (I highly suggest reading Part 1 if you have not already).

Remember, this exercise was performed using a laptop (with internal Bluetooth) running Windows 8.1 and a Samsung Galaxy Note 2 (running Android 4.3). Your individual mileage and testing may vary.

The first thing that I would like to highlight on the Windows system is after a successful Bluetooth connection is established, a new folder titled "Bluetooth Devices" is populated within the "Programs" folder. This folder does not seem to appear to the user unless a device is connected. 

Bluetooth Devices folder on Windows 8 (Note the capital "BL" in Bluetooth.  Programmers don't use spell-check!)

Naturally this is interesting and clicking on the properties of the folder reveals the following "target" of the folder. It appears that the program "Win7UI.exe" (Full Path: "C:\Program Files (x86)\Bluetooth Suite\Win7UI.exe") was run on the system with the argument "50:32:75:98:af:0a" (which unsurprisingly, is the Bluetooth MAC address for my Galaxy Note 2)

Bluetooth Devices "Target" details. Again, Bluetooth starts with a capital "BL"

Upon connecting the device, Windows also creates a .lnk file (on my system, under the path "C:\Users\Brian\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\BT Devices" that appears to be the device name (once again, in my case SCH-I605.lnk). The description of the link file is Win7UI, which is the executable file in the Bluetooth Suite that was run along with the Bluetooth MAC address of the device. Although the created time was updated for the most recent connection, the modified time was the very first time that the connection was established. 

Properties of the .lnk file

Another very important item that I want to highlight is the "History" within the FileTaskManager. While I discussed in the previous post that a history is maintained, it appears that the History only lasts for each session in which the device is connected. In other words, once the Bluetooth connection is lost, the History option within the program itself is also lost. 

The history is cleared upon a new connection

Disk artifacts

I was more than a little surprised when I did not find much evidence in the way of artifacts on the disk itself, with the exception of two .lnk files and some items of interest within the pagefile. I am still working on going through all of the Registry data, but with the exception of showing evidence of files being accessed, there does not seem to be definitive evidence of file transfers.

Two .lnk files were created, both of which were named "SCH-I605.lnk".

"SCH-I605.lnk", found under the path "ProgramData\Atheros\Device link\18-67-b0-85-31-4b"

"SCH-I605.lnk" file under the path "Users\Brian\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\BT Devices" (remember, you may not see this file and file location unless Bluetooth is turned on. Even if you browse from the command line!)

I used RegRipper 2014014 and pointed it at both the NTUSER.dat hive and the UsrClass.dat hive in hopes of finding at least some good information. Unfortunately, outside of Recently Accessed documents, there was no evidence of my file "exfil.doc" or the phone "SCH-I605" (now granted, this may be due to the fact I did this on Windows 8.1 and something may have changed format-wise; truth be told I haven't dug into Win8 shellbags too much yet)

Searching for "exfil.doc" in RegRipper UsrClass.dat output
Searching for "I605" in RegRipper UsrClass.dat output

The pagefile is where the most interesting items on the disk itself were located. The first was several instances of what appeared to be the title of the GUI that Windows presented upon making a successful connection.

Lots of SCH-I605 and MAC address hits. It looks an awful lot like the header of the Windows 8 Bluetooth console!
The title of this window looks familiar....

The second item of interest was what appeared to be evidence regarding the initial connection setup. 

Possible references to the Bluetooth connection

Memory artifacts

Briefly covering some strings of interest in the pagefile sets up perfectly for transitioning into memory analysis. Volatility does not have yet support for Windows 8 memory dumps, so the amount of memory analysis that I can currently perform on the dump is limited to some archaic methods such as strings and contextual analysis. Once Windows 8 processing is supported I plan on revisiting the memory dump analysis, but for now the strings/contextual analysis will have to suffice.

I searched across the memory dump for "SCH-I605", "exfil.doc", "FileTaskManager" and the time stamps listed in the History tab of the FileTaskManager. Once again, I was a little surprised by how few results I got, but there was one item of particular interest that was not present in the pagefile.

There appeared to be a possible reference to sending the file "exfil.doc" at 5/20/2014 3:33:45. This is the only POSSIBLE (possible because it really doesn't give definitive proof) evidence that a file was sent. I couldn't find anything else regarding the other timestamps in the memory dump. I am kicking off a regular expression match across the entire contents of the disk image to see if anything else matches this particular timestamp pattern, but in order to keep this post at least relatively timely, the results will have to wait for a later post.

Possible begin to send file information on "exfil.doc"

Windows Live Response collection artifacts

I also ran the Windows Live Response collection against the drive and had some interesting results in three files, specifically cports (open ports), running processes (expected) and Last Activity View (expected). 

Running processes showed both FileTaskManager (BtTray.exe) and SCH-I605 (Win7UI.exe). I expected both of these to be seen based on the other data that we have uncovered so far

Running processes items of interest

Last Activity View showed that the system ran Win7UI.exe. It also showed the "Select file in open/save dialog-box" and "Open file or folder" descriptions without any additional activity occurring. Normally one would expect to see Word (or some other program) immediately following that selection, but in this case we see nothing. So perhaps the absence of "normal" items in Last Activity View may tip you off.

Last Activity View items of interest

The item that was most interesting is cports, but upon thinking about it more it makes total sense.  Honestly it might be the only indicator  you could reliably "catch". On top of transferring files, the basic, default, generic settings on Windows 8 allows the user to not only transfer files, but also to send SMS messages, make phone calls, sync contacts, etc. It seems that the system also uses a TCP connection with the phone to do this rather than relying solely on a Bluetooth connection. Some more testing is needed, but unless the phone is connected via Bluetooth I do not see any connections between my system and my phone.

Modified cports data. FileTaskManager and the SCH-I605 connections are of note!

Some Windows 7 items

Presently, I do not have access to a physical device running Windows 7, so I reached out to my good friend Mari DeGrazia who took some time out of her busy schedule to help see if similar items were on her Windows 7 device. One of her systems used a Broadcomm Bluetooth adapter (both of my Windows 8 boxes use an Atheros adapter) and the pathing and executable was slightly different. I am planning to take a similar in-depth look on a Windows 7 box as soon as time and resources permit, but here is a preview.

The creation of a .lnk file for a Bluetooth connected device is the same, however the location of the application is different. On this particular box it is C:\Program Files\WIDCOMM\Bluetooth Software" and the application is "BTWUIExt.exe". The application is run with the argument "/deviceADDR=001122334455", which is the Bluetooth MAC address. It looks like the link files follow the same time stamp format, with the modified time being the date/time of first connection and the created/accessed time stamps being the most recent time when a connection was established.

Windows 7 (Broadcomm adapter) link information. Device name and MAC address modified

The final takeaway

Unfortunately, it looks like it is going to be EXTREMELY difficult to detect actual data exfiltration via Bluetooth. However, there are a couple of items that you can look for on a system in an effort to try to determine if additional questioning and/or searching is required. The main items of interest to look for this far are:
  • The execution of "Win7UI.exe" (or BTWUIExt.exe, or a similar program on your system(s))

  • .lnk files containing mobile device IDs, especially those located in the "BT Devices" folder (and/or the applicable Bluetooth adapter folder)

  • Strings within pagefile/memory dump that contain the device ID and/or Bluetooth MAC address of the device (make sure you take into account different formats/regular expressions!)

  • Look for the filename(s) you think may have been transferred in the memory dump and Registry

  • Pay attention to "FileTaskManager" using higher TCP ports

  • Pay attention to TCP ports being used by a device model/MAC address combination

  • If you run Last Activity View, look for abnormal usage patterns such as Open/Save dialog boxes with no discernible idea of what opened/modified that file (or created the box to open in the first place) 

Tuesday, May 20, 2014

Bluetooth for data exfiltration. Say what?!? Part 1: The Setup

One of the things that I absolutely love about the DFIR community is the amount of communication and idea/information sharing that happens between members of the community. A few weeks ago Ken Pryor posed a question on Twitter regarding extracting data from a Tracfone. I shared my experience with using a Bluetooth connection to get a few files, and Harlan Carvey asked what experience we've seen with regards to Bluetooth data exfiltration. 

The Twitter conversation that started this post!

To date, I have not seen Bluetooth used for data exfiltration on a case that I worked, but since there is such a large crossover between personal mobile devices and the corporate environment, I was curious to see what evidence I could find of data exfiltration when I used Bluetooth to send a file from my laptop (running Windows 8.1) to my Galaxy Note 2 (running Android 4.3). 

I first had to pair the devices, which was accomplished by turning Bluetooth on (on both devices), and confirming on each device that I was indeed pairing the devices together. Once I paired the devices, Windows 8 presented me with the following console on my laptop:

Windows 8 Bluetooth console

For the purposes of this post, I created a TrueCrypt file named "exfil.doc" (for more on TrueCrypt, please visit my previous blog post). I opened the file in HexWorkshop to confirm the lack of a file header, the file size is cleanly divisible by 512, and the character distribution is 0.39%, which is exactly what I expected to see:

File header of "exfil.doc"

File size cleanly divisible by 512

0.39% character distribution in "exfil.doc"

Once I had my "document" ready to "exfiltrate", I had to choose the file to send using the "File Operations" option within the Bluetooth console

File Operations tab within Bluetooth console

I choose this one!

Once I chose the file, Windows queued it to transfer the file from my laptop to my phone. 

Bluetooth FileTaskManager waiting to transfer file

My phone presented me with a message that I had to first accept in order for the data to be transferred.

Bluetooth file transfer notification on Galaxy Note 2

And so it begins....

The file, which was 543MB in size, took about 55 minutes to transfer via Bluetooth. I was a little bit surprised that it took that long, but since I don't use Bluetooth on my laptop (in fact, with the exception of this post, I have it disabled) the slower speeds may have been caused because the drivers/software were not updated.  

Files sent to my Galaxy Note 2 via Bluetooth

On Windows 8, the "History" tab of the FileTaskManager window shows the history of files that are transferred. You can see my attempts to transfer files, and failed attempts as well. I am hoping to find this data either recorded on disk and/or within the memory dump from the system. This data can also be cleared by the user, so it may not always be populated.

FileTaskManager history

Part 2 of this post will include evidence related to the Bluetooth transfer that I find within the memory dump and drive image. As Harlan pointed out, at the very least there should be evidence of the Bluetooth connections in the Registry and within Shellbags. I am hopeful that there can be some evidence found on the device (and in the memory dump) of the actual file transfer itself, but I have to wait for the image to finish, load it up, and see what I can find!