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.

noriben

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.