Chomping on BlueTooth

I had a difficult task recently: try to determine who was the likely operator of a netbook.  The netbook was used to download and store ATM card numbers that had been illicitly collected with a skimmer.  The operating system was Windows XP, and the sole user account was a pseudonym that I could not link to anyone in particular.

I tried a few obvious tactics: I looked for installed software (Program Files and Windows Registry), hoping to get registration names and/or email addresses for registered applications.  Nothing.  In fact, it appeared little extra software had been installed on the system except for the software and driver's to communicate with the skimmer.

I decided to boot the image in a VM to get a 'lay of the land.'  In dead disk analysis, its quite easy to see what files are on the desktop, for example, but not nearly so easy to see how objects are arranged, the wallpaper, running applications, etc.  Sure, you can discover these things, but you have to look several locations and then synthesize the information... sometimes a picture is just plain better.  I used xmount, VirtualBox, and opengates, a technique I've previously detailed.

I immediately noted something after the system booted: the BlueTooth (BT) service was running.  I have never seen BT running by default in a Windows system, but that doesn't mean it wasn't configured to run on boot by the netbook's manufacturer.  But still, I was intrigued.  The BT application windows did not show a history of connected devices, but I wondered if such a history was available.  Maybe the paired device might lead me to the suspect?

I'm in the habit of imaging devices with forensics-oriented Linux boot discs such as CAINE, DEFT, or those of my own creation.  The benefits can be quite substantial, including the ability to easily collect hardware information.  I use lshw for this purpose, but in this case, I saw no BT hardware listed in the report, just ethernet and wifi.  Did this netbook support BT, or was an external adapter used?  In this case, I no longer have the hardware in front of me to inspect, but it doesn't appear to have a built-in adapter.

However, I am able to detect third-party bluetooth software with a quick registry search in the mounted disk image:

$ reglookup -i software | grep -i bluetooth
/Widcomm/Install/INSTALLDIR,SZ,C:\x5CProgram Files\x5CWIDCOMM\x5CBluetooth Software\x5C,2010-11-28 03:01:19

The tool I used, reglookup, is an efficient and useful command line registry parser.  The -i option causes subkeys to inherit the timestamp of the parent key.  The date may not reflect the modification date of the specific key since the parent key modified date is updated whenever a subkey is modified.

Inspecting The Widcomm (Broadcom) software keys, I found a "Devices" subkey that organized remote devices by their MAC addresses:

Widcomm/BTConfig/Devices,KEY,,2010-11-28 03:04:14
/Widcomm/BTConfig/Devices/00:02:72:e2:05:7a,KEY,,2010-11-28 03:10:08
/Widcomm/BTConfig/Devices/00:23:3a:e5:1f:53,KEY,,2010-11-28 03:04:45
/Widcomm/BTConfig/Devices/78:ca:39:41:40:e1,KEY,,2010-11-28 03:04:05

Each "device" subkey, among other things, contained a name key.  This was the 'text' name of the device, and one of the devices stood out:

/Widcomm/BTConfig/Devices/78:ca:39:41:40:e1/Name,BINARY,badguy\xE2\x80\x99s MacBook Air\x00,

The data in the Name key is in a python bytes format, which displays ASCII text where possible and otherwise the hex in the form \x00.  It can be converted in python3 rather simply with:

b'badguy\xE2\x80\x99s MacBook Air'.decode()

'badguy’s MacBook Air'

I redacted the Name key data for this article, but from it I learned the name of the MacBook Air with which the netbook had been paired.  The name of the MacBook was the name of a suspect in the case.  Proof positive that the named suspect was the operator of the netbook?  No, certainly not.  But helpful in light of the totality of the circumstances, to be sure.