Helpful Navigation Toolbar

Thursday, May 22, 2014

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



*****SUPER IMPORTANT DISCLAIMER*****

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.



***BEGIN NON-TECHNICAL POST SUMMARY***



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.

***END NON-TECHNICAL POST SUMMARY***





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) 








1 comment:

  1. "I used RegRipper 2014014 and pointed it at both the NTUSER.dat hive and the UsrClass.dat hive..."

    Your findings may change after further research. Keep in mind that the power of RegRipper comes not from running it, but from folks like you who are doing research adding plugins to it. At the moment, there are no Win8.1 Bluetooth plugins that I'm aware of...my own Win8.1 test system doesn't have BT. If you're willing to dig into the Registry via some sort of timeline analysis, you may find artifacts not yet addressed by RegRipper.

    ReplyDelete