Helpful Navigation Toolbar

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!

Monday, May 19, 2014

ZeroAccess, Windows command line code pages, alternate data streams, spaces in file paths, and more. Also an update to the Windows Live Response collection!

Good news everyone!! There is a lot to cover in this blog post, so please ensure your seat belt is securely fastened because it is going to be one heck of a ride!

All of the items in this particular blog post came about as I was messing around on the Malware Box of Evil with a ZeroAccess rootkit sample (you can read more about this sample here). Many months ago, back when I used EnCase to perform my analysis, I wrote an EnScript to digest file paths when searching for Unicode characters in file paths. (I have since moved on an use X-Ways pretty much exclusively as it is a MUCH better tool than EnCase. I, for one, welcome our new X-Ways overlords! ) I wanted the Windows Live Response script to perform similar functions to highlight files and directories of possible interest and save that output. What I didn't realize is how much research, frustration, alcohol, and eventual joy and happiness this process would involve.

Windows Code Pages

The first thing that I encountered was the Windows Code Page. There are many, many different code pages, but on US-based, English systems, the default code page used by the Windows command prompt seems to be 437 (MS-DOS Latin US). You can open a command prompt and see what code page it uses by typing the command 'chcp'. What this means for the typical user is, even if you have installed different language packs to view files/languages on your US English Windows system, when you view those files from a command prompt you are likely to see "????" instead of "папка" (a Russian word for "folder")

Command line view and Windows Explorer view of "папка"folder. The Active code page is 437.

So I updated the Windows Live Response batch script to perform a directory listing and then use the built-in Windows command "findstr" to look for anything with a "?" in the output. While it may produce a lot of results, especially if you have a lot of files/paths in other languages, it should help you to determine some areas of interest in which to look.

Alternate Data Streams

As I got to thinking about this particular ZeroAccess sample, the more that I realized simply finding Unicode in filepaths wouldn't be enough. What if the sample you are trying to detect doesn't use Unicode in the file path, such as the one in this writeup? What if it just utilizes one of the main indicators such as an Alternate Data Stream (ADS)? (I won't go into detail on Alternate Data Streams in this post but there are several posts, such as this one, that you can easily find if you want to learn more). Starting with Windows Vista, the built-in Windows "dir" command has a "/r" option that allows you view Alternate Data Streams. 

"dir" command options for Windows Vista and later. Retrieved 14 May 2014 from ""

This is an outstanding feature, however, the "dir" command on Windows XP systems (which I know are still in use <sad face>) does not have that option. Fortunately Mark Russinovich released a tool in the Sysinternals Suite called "streams" which works on Windows systems, including Windows XP. I have updated the Windows Live Response collection to include this tool and the script will now search the %HOMEDRIVE% for Alternate Data Streams. The output of streams.exe also includes the "." character to show that it is working. So be aware that you may end up with file paths that look like they contain Morse code (for example, the screenshot below contains "..." before the path). This is a result of the tool output and can easily be cleaned by the end user, if they so desire.

By combining the findstr "?" search and the Alternate Data Stream search, we can clearly see possible evidence of a ZeroAccess infection on the Malware Box of Evil.

Alternate Data Stream search and possible Unicode search results

Spaces in file paths and environment variables to help

As I was running/working on the script, I realized that the entire batch script had a potentially serious issue. I have always tried to save files connected by underscores or dashes and never until my most recent round of testing did I contemplate "what if the user had a space in the file path"? This was particularly highlighted by placing the collection on the "Documents and Settings\<USERNAME>\Desktop" of a Windows XP system. While a majority of the commands worked OK with the "%~dp0" variable, some did not, and one command not working properly makes me unhappy. So after quite a bit of trial and error, I realized two things about the Windows command line interface:

1) You can escape characters using the caret "^" symbol. However, if you use the caret symbol as an escape character, you cannot place that command in either single or double quotes.

What works and what doesn't work with space on the Windows command line

2) The variable "%~dps0" gives the file location of the batch script, but uses the "short" file/path name method. So it is a built-in way to allow for spaces in the name. I wish I would have figured that out early on before devoting a lot of time and effort, but it was a great learning experience and I learned a lot of  "what not to do" and hopefully sharing my experiences will help you during the course of your research/investigations.

Batch script output using %~dps0. Note the ~ in the paths instead of escaped spaces

Lastly, updates to the Windows Live Response collection

All of these items that I covered in this post have found their way into the updated version of the Windows Live Response collection. I also included the most recent version of PEStudio (8.26) which you can download from Marc's website - download here 

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