BT Recon: How to Snoop on Bluetooth Devices Using Kali Linux

While many people may use Bluetooth every day, the majority don't know how it works or that it can be hacked. Bluetooth hacking gives a clear window into the world of the target. Nearly every device has Bluetooth capabilities, and people store a great deal of personal info on their phones and tablets. Hack their Bluetooth connection, and you may be able to access all of that data.

Although Bluetooth shares the same 2.4 GHz frequency as Wi-Fi, the properties are different because the protocols are not quite the same. There's enhanced security so that popular Wi-Fi hacking tools won't work on Bluetooth.

For one, they're continually hopping frequencies, so if you have two devices communicating over Bluetooth, they're both using an algorithm that shifts the frequency many times per second. That means we can't merely sit on one frequency and listen because they're going to be hopping all over the place. It makes it difficult for an attacker to listen in on the conversation in the first place.

• Don't Miss: How Mr. Robot Hacked Bluetooth

Another property is that Bluetooth doesn't negotiate a key every single time like Wi-Fi does, where it's easy for anyone to join and leave the Wi-Fi network. Instead, Bluetooth negotiates a key once at the beginning, stores the secret key, and then refers to it every time it sees the same device. That means it's impossible to sit there and sniff the key because you need to be there the first time these devices communicate. Otherwise, you're not going to get anything useful, and it's impossible to jump into the conversation the way you can with Wi-Fi.

However, we can still track nearby Bluetooth devices, read from them, and even write specific characteristics. Because of that, it's useful to do the reconnaissance in case we can either take control of the device, identify a vulnerability, or find a vulnerability later that matches up with one that's nearby.

What You'll Need for Bluetooth Recon

To begin Bluetooth surveillance, you'll need a fully updated version of Kali Linux installed because we're going to be using Bluetooth tools that are built-in. To keep things super basic, we're not installing anything extra, and we can just work with the Bluetooth tools that Kali Linux has by default.

The built-in tools we'll be covering below include hciconfig, hcitool, sdptool, l2ping, and btscanner. Many of these tools are included in BlueZ, the default Bluetooth protocol stack in nearly every version of Linux, including Kali. (We will also use some specialized tools for Bluetooth recon in Kali.)

Of course, we have to be in fairly close proximity to hack Bluetooth. With an excellent Bluetooth adapter, which is needed, you should be able to reach Bluetooth devices in a coffee shop, school classroom, office, and maybe even into a neighbor's house.

• Don't Miss: Using MultiBlue to Control Any Mobile Device via Bluetooth

Step 1: Enable Your Bluetooth Adapter with hciconfig

If you're familiar with ifconfig for Wi-Fi cards and adapters, there is another tool that is similar for Bluetooth devices. And it's called hciconfig.

~# hciconfig

hci0     Type: Primary Bus: USB
         BD Address: ██:██:██:██:██:██  ACL MTU: 1022:8   SCO MTU: 183.5
         DOWN
         RX bytes:574 acl:0 sco:0 events:30 errors:0
         TX bytes:368 acl:0 sco:0 commands:30 errors:0

In my example, we can see a Bluetooth interface. It's what we'll be using to do all of the things we want to do with Bluetooth. You can see that its current state is down, which means that it's not able to do anything, so the first thing we need to do to work with Bluetooth is to bring our interface up.

If we have a Wi-Fi interface that's plugged in, but it's not up yet, we can type ifconfig, then the name of the interface, and then up. Since hciconfig is basically the same thing as ifconfig, we can use a lot of the same commands, which you can see in its man page.

~# man hciconfig

HCICONFIG(1)              Linux System Administration             HCICONFIG(1)

NAME
       hciconfig - configure Bluetooth devices

SYNOPSIS
       hciconfig -h
       hciconfig [-a]
       hciconfig [-a] hciX [command [command parameters]]

DESCRIPTION
       hciconfig  is used to configure Bluetooth devices.  hciX is the name of
       a Bluetooth device installed in the system. If hciX is not given,  hci‐
       config  prints  name  and basic information about all the Bluetooth de‐
       vices installed in the system. If hciX  is  given  but  no  command  is
       given,  it prints basic information on device hciX only. Basic informa‐
       tion is interface type, BD address, ACL MTU, SCO MTU, flags (up,  init,
       running, raw, page scan enabled, inquiry scan enabled, inquiry, authen‐
       tication enabled, encryption enabled).

OPTIONS
       -h, --help
              Gives a list of possible commands.

       -a, --all
              Other than the basic info, print  features,  packet  type,  link
              policy, link mode, name, class, version.

COMMANDS
       up                   Open and initialize HCI device.
       down                 Close HCI device.
       reset                Reset HCI device.
       rstat                Reset statistic counters.
       auth                 Enable authentication (sets device to security mode 3).
       noauth               Disable authentication.
       encrypt              Enable encryption (sets device to security mode 3).
       noencrypt            Disable encryption.
       secmgr               Enable security manager (current kernel support is limited).
       nosecmgr             Disable security manager.
       piscan               Enable page and inquiry scan.
       noscan               Disable page and inquiry scan.
       iscan                Enable inquiry scan, disable page scan.
       pscan                Enable page scan, disable inquiry scan.
       ptype [type]         With no type , displays the current packet types. Otherwise, all the packet types specified by type are set.  type  is  a  comma-separated  list of packet types, where the possible packet types are DM1, DM3, DM5, DH1, DH3, DH5, HV1, HV2, HV3.
       name [name]          With no name, prints local name. Otherwise, sets local  name  to name.
       class [class]        With  no class, prints class of device. Otherwise, sets class of device to class.  class is a 24-bit hex  number  describing  the class  of  device,  as specified in section 1.2 of the Bluetooth Assigned Numers document.
       voice [voice]        With no voice, prints voice setting. Otherwise, sets voice  setting  to  voice.   voice  is  a 16-bit hex number describing the voice setting.
       iac [iac]            With no iac, prints the current IAC setting. Otherwise, sets the IAC to iac.
       inqtpl [level]       With  no  level,  prints  out the current inquiry transmit power level. Otherwise, sets inquiry transmit power level to level.
       inqmode [mode]       With no mode, prints out the current  inquiry  mode.  Otherwise, sets inquiry mode to mode.
       inqdata [data]       With  no  name,  prints out the current inquiry data. Otherwise, sets inquiry data to data.
       inqtype [type]       With no type, prints out the current inquiry scan  type.  Otherwise, sets inquiry scan type to type.
       inqparams [win:int]  With no win:int, prints inquiry scan window and interval. Otherwise, sets inquiry scan window to win slots and inquiry scan interval to int slots.
       pageparms [win:int]  With  no  win:int,  prints page scan window and interval. Otherwise, sets page scan window to win slots and page scan  interval to int slots.
       pageto [to]          With no to, prints page timeout. Otherwise, sets page timeout to .I to slots.
       afhmode [mode]       With no mode, prints out the current AFH mode.  Otherwise,  sets AFH mode to mode.
       sspmode [mode]       With no mode, prints out the current Simple Pairing mode. Otherwise, sets Simple Pairing mode to mode.
       aclmtu mtu:pkt       Sets ACL MTU to to mtu bytes and ACL buffer size to pkt packets.
       scomtu mtu:pkt       Sets SCO MTU to mtu bytes and SCO buffer size to pkt packets.
       delkey <bdaddr>      This command deletes the stored link key for bdaddr from the device.
       oobdata              Get local OOB data (invalidates previously read data).
       commands             Display supported commands.
       features             Display device features.
       version              Display version information.
       revision             Display revision information.
       lm [mode]            With  no mode , prints link mode.  MASTER or SLAVE mean, respectively, to ask to become master or to remain slave when  a  connection  request  comes  in. The additional keyword ACCEPT means that baseband  connections will be accepted even if there are no listening  AF_BLUETOOTH  sockets.  mode is NONE or a comma-separated list of keywords, where possible keywords are  MASTER  and ACCEPT  .  NONE sets link policy to the default behaviour of remaining slave and not accepting baseband connections when  there are no listening AF_BLUETOOTH sockets. If MASTER is present, the device will ask to become master if a connection  request  comes in.  If  ACCEPT is present, the device will accept baseband connections even when there are no listening AF_BLUETOOTH sockets.

AUTHORS
       Written by Maxim Krasnyansky <maxk@qualcomm.com>  and  Marcel  Holtmann <marcel@holtmann.org>

       man page by Fabrizio Gennari <fabrizio.gennari@philips.com>

BlueZ                             Nov 11 2002                     HCICONFIG(1)

Manual page hciconfig(1) line 147/169 (END) (press h for help or q to quit)

We can see in the man page that this is used to configure Bluetooth devices, so if you have that external Bluetooth device or something plugged in, you can also use that to see the devices that are connected and configure them appropriately.

Now that we know a little bit more about hciconfig, let's go ahead and press Q to quit. We'll need to take the Bluetooth device we've discovered and bring it up. Just type hciconfig, then the name of the device we found, and up.

~# hciconfig hci0 up

To see if it worked, run the hciconfig command again:

~# hciconfig

hci0     Type: Primary Bus: USB
         BD Address: ██:██:██:██:██:██  ACL MTU: 1022:8   SCO MTU: 183.5
         UP RUNNING
         RX bytes:1148 acl:0 sco:0 events:60 errors:0
         TX bytes:736 acl:0 sco:0 commands:60 errors:0

Step 2: Scan for Bluetooth Devices with hcitool

Now let's use hcitool to look for Bluetooth devices that are sending out their discover beacons (in discovery mode). First, let's check out its man page:

~# man hciconfig

HCITOOL(1)                Linux System Administration               HCITOOL(1)

NAME
       hcitool - configure Bluetooth connections

SYNOPSIS
       hcitool [-h]
       hcitool [-i <hciX>] [command [command parameters]]

DESCRIPTION
       hcitool  is  used to configure Bluetooth connections and send some spe‐
       cial command to Bluetooth devices. If no command is given,  or  if  the
       option -h is used, hcitool prints some usage information and exits.

OPTIONS
       -h     Gives a list of possible commands

       -i <hciX>
              The  command  is applied to device hciX , which must be the name
              of an installed Bluetooth device. If not specified, the  command
              will be sent to the first available Bluetooth device.

COMMANDS
       dev                  Display local devices
       inq                  Inquire  remote  devices.  For each discovered device, Bluetooth device address, clock offset and class are printed.
       scan                 Inquire remote devices. For each discovered device, device  name are printed.
       name <bdaddr>        Print  device  name  of  remote  device  with  Bluetooth address bdaddr.
       info <bdaddr>        Print device name, version and supported features of remote  device with Bluetooth address bdaddr.
       spinq                Start periodic inquiry process. No inquiry results are printed.
       epinq                Exit periodic inquiry process.
       cmd <ogf> <ocf> [parameters]
                            Submit  an  arbitrary HCI command to local device.  ogf, ocf and parameters are hexadecimal bytes.
       con                  Display active baseband connections
       cc [--role=m|s] [--pkt-type=<ptype>] <bdaddr>
                            Create baseband connection to remote device with  Bluetooth  address  bdaddr.   Option  --pkt-type  specifies a list of allowed packet types.  <ptype>  is  a  comma-separated  list  of  packet types,  where  the possible packet types are DM1, DM3, DM5, DH1, DH3, DH5, HV1, HV2, HV3.  Default is to allow all packet  types. Option  --role  can have value m (do not allow role switch, stay master) or s (allow role switch, become slave if the  peer  asks to become master). Default is m.
       dc <bdaddr> [reason]
                            Delete baseband connection from remote device with Bluetooth address bdaddr.  The reason can be one of the Bluetooth HCI  error codes.  Default is 19 for user ended connections. The value must be given in decimal.
       sr <bdaddr> <role>   Switch role for the baseband connection from the  remote  device to master or slave.
       cpt <bdaddr> <packet types>
                            Change packet types for baseband connection to device with Bluetooth address bdaddr.  packet types is a comma-separated list of packet types, where the possible packet types are DM1, DM3, DM5, DH1, DH3, DH5, HV1, HV2, HV3.
       rssi <bdaddr>        Display received signal strength information for the  connection to the device with Bluetooth address bdaddr.
       lq <bdaddr>          Display link quality for the connection to the device with Bluetooth address bdaddr.
       tpl <bdaddr> [type]  Display transmit power level for the connection  to  the  device with  Bluetooth  address bdaddr.  The type can be 0 for the current transmit power level (which is default) or 1 for the  maximum transmit power level.
       afh <bdaddr>         Display  AFH  channel  map for the connection to the device with Bluetooth address bdaddr.
       lp <bdaddr> [value]  With no value, displays link policy settings for the  connection to the device with Bluetooth address bdaddr.  If value is given, sets the link policy settings  for  that  connection  to  value. Possible values are RSWITCH, HOLD, SNIFF and PARK.
       lst <bdaddr> [value] With no value, displays link supervision timeout for the connection to the device with Bluetooth address bdaddr.  If  value  is given,  sets the link supervision timeout for that connection to value slots, or to infinite if value is 0.
       auth <bdaddr>        Request authentication for the  device  with  Bluetooth  address bdaddr.
       enc <bdaddr> [encrypt enable]
                            Enable  or  disable the encryption for the device with Bluetooth address bdaddr.
       key <bdaddr>         Change the connection link key for the device with Bluetooth address bdaddr.
       clkoff <bdaddr>      Read  the  clock  offset  for  the device with Bluetooth address bdaddr.
       clock [bdaddr] [which clock]
                            Read the clock for the device  with  Bluetooth  address  bdaddr. The  clock  can  be  0  for the local clock or 1 for the piconet clock (which is default).
       lescan [--privacy] [--passive] [--whitelist]  [--discovery=g|l]  [--duplicates]
                            Start LE scan
       leinfo [--static] [--random] <bdaddr>
                            Get LE remote information
       lewladd [--random] <bdaddr>
                            Add device to LE White List
       lewlrm <bdaddr>      Remove device from LE White List
       lewlsz               Read size of LE White List
       lewlclr              Clear LE White List
       lerladd [--local irk] [--peer irk] [--random] <bdaddr>
                            Add device to LE Resolving List
       lerlrm <bdaddr>      Remove device from LE Resolving List
       lerlclr              Clear LE Resolving List
       lerlsz               Read size of LE Resolving List
       lerlon               Enable LE Address Resolution
       lerloff              Disable LE Address Resolution
       lecc [--static] [--random] <bdaddr> | [--whitelist]
                            Create a LE Connection
       ledc <handle> [reason]
                            Disconnect a LE Connection
       lecup <handle> <min> <max> <latency> <timeout>
                            LE Connection Update

AUTHORS
       Written  by  Maxim  Krasnyansky <maxk@qualcomm.com> and Marcel Holtmann <marcel@holtmann.org>

       man page by Fabrizio Gennari <fabrizio.gennari@philips.com>

BlueZ                             Nov 12 2002                       HCITOOL(1)

Manual page hcitool(1) line 154/176 (END) (press h for help or q to quit)

Hcitool is used to both configure and perform various tasks like scans, inquiries, and pulling names. That's really useful to learn about the device, but some of these commands require a MAC address to use them.

Let's take a look at some of these commands. First, we'll do a scan. It will use the Bluetooth interface to scan for nearby Bluetooth devices and present their MAC addresses for us to do additional scans, inquiries, or attempt to get the name of the device.

~# hcitool scan

Scanning ...
        00:1D:A5:00:09:1D       OBDII

Above, we see an OBD2 connector which is connected to a vehicle. That's pretty interesting. With the MAC address, we can now we can do another command that required us to have a MAC address in the first place. Let's try getting the name of the device:

~# hcitool name 00:1D:A5:00:09:1D

OBDII

That should allow us to get the name of the device, but we already knew it from that first scan. If we didn't know it, however, it'll allow us to be able to learn more about it. To learn more, we can use the inq command:

~# hcitool inq 00:1D:A5:00:09:1D

Scanning ...
        00:1D:A5:00:09:1D       clock offset: 0x21c0    class: ox5a020c

Note that it also displays clock offset and the class. The class indicates what type of Bluetooth device it is, and we can look up the code by going to the Bluetooth site. Or, as we will see later, some tools will do it for us.

Step 3: Scan for Services with sdptool

To learn more about services, we can use a tool called sdptool to browse more about what's available on the device and learn about the properties — maybe what we can and can't do. We'll need to use the MAC address again, but first, let's check out its man page too:

~# man sdptool

sdptool(1)                  General Commands Manual                 sdptool(1)

NAME
       sdptool — control and interrogate SDP servers

SYNOPSIS
       sdptool [options]  {command}  [command parameters ...]

DESCRIPTION
       sdptool  provides the interface for performing SDP queries on Bluetooth
       devices, and administering a local SDP database.

COMMANDS
       The following commands are available.  In all  cases  bdaddr  specifies
       the  device to search or browse.  If local is used for bdaddr, then the
       local SDP database is searched.

       Services are identified and manipulated  with  a  4-byte  record_handle
       (NOT  the  service  name).  To find a service's record_handle, look for
       the "Service RecHandle" line in the search or browse results

       search [--bdaddr bdaddr] [--tree] [--raw] [--xml] service_name
                 Search for services.. Known service names are DID, SP, DUN, LAN, FAX,  OPUSH,  FTP, HS,  HF,  HFAG,  SAP,  NAP,  GN, PANU, HCRP, HID, CIP, A2SRC, A2SNK, AVRCT, AVRTG, UDIUE, UDITE and SYNCML.
       browse [--tree] [--raw] [--xml] [bdaddr]
                 Browse all available services on the device  specified  by  a Bluetooth address as a parameter.
       records [--tree] [--raw] [--xml] bdaddr
                 Retrieve all possible service records.
       add [ --handle=N --channel=N ]
                 Add a service to the local SDP database. You  can  specify a handle for this record using the --handle option. You can specify a channel to add the  service  on  using  the --channel option. NOTE:  Local  adapters  configuration will not be updated and this command should be used only for SDP testing.
       del record_handle
                 Remove a service from the local SDP database. NOTE: Local adapters configuration will not  be  updated  and this command should be used only for SDP testing.
       get [--tree] [--raw] [--xml] [--bdaddr bdaddr] record_handle
                 Retrieve a service from the local SDP database.
       setattr record_handle attrib_id attrib_value
                 Set or add an attribute to an SDP record.
       setseq record_handle attrib_id attrib_values
                 Set or add an attribute sequence to an SDP record.

OPTIONS
       --help    Displays help on using sdptool.

EXAMPLES
       sdptool browse 00:80:98:24:15:6D
       sdptool browse local
       sdptool add DUN
       sdptool del 0x10000

BUGS
       Documentation needs improving.

AUTHOR
       Maxim  Krasnyansky <maxk@qualcomm.com>. Man page written by Edd Dumbill <ejad@debian.org>.

                                                                    sdptool(1)

Manual page sdptool(1) line 60/82 (END) (press h for help or q to quit)

It lets us configure, control, and interrogate SDP (service discovery protocol) servers. So it's something that allows us to do queries on Bluetooth devices and figure out precisely what is going on with the permissions and what we can probably start to do with those services.

Quit the man page, and let's type sdptool then browse, followed by the MAC address we captured.

~# sdptool browse 00:1D:A5:00:09:1D

Browsing 00:1D:A5:00:09:1D ...
Service Name: SPP
Service RecHandle: 0x10001
Service Class ID List:
    "Serial Port" (ox1101)
Protocol Descriptor List:
    "L2CAP" (0x0100)
    "RFCOMM" (0x0003)
      Channel: 1

Here, we can see a little bit more information about the communications, the protocols, and perhaps we could even start to discover whether or not there's a vulnerability in the device or if we're able to communicate with it directly. We can maybe even find whether it's using MAC address randomization or something like that.

Step 4: Ping Bluetooth Devices with l2ping

Now that we have the MAC addresses of all the nearby devices, we can ping them with a tool called l2ping, whether they are in discover mode or not, to see whether they are in reach. For me, it's just one device. Before doing so, let's run the man page for the tool just to see everything available.

~# man l2ping

L2PING(1)                 Linux System Administration                L2PING(1)

NAME
       l2ping - Send L2CAP echo request and receive answer

SYNOPSIS
       l2ping  [-i  <hciX>]  [-s size] [-c count] [-t timeout] [-d delay] [-f]
       [-r] [-v] bd_addr

DESCRIPTION
       L2ping sends a L2CAP echo request to the Bluetooth MAC address  bd_addr
       given in dotted hex notation.

OPTIONS
       -i <hciX>        The  command  is applied to device hciX , which must be the name of an installed Bluetooth device (X = 0,  1,  2,  ...)   If  not specified, the command will be sent to the first available Bluetooth device.
       -s size          The size of the data packets to be sent.
       -c count         Send count number of packets then exit.
       -t timeout       Wait timeout seconds for the response.
       -d delay         Wait delay seconds between pings.
       -f               Kind of flood ping. Use with care! It reduces the delay time between packets to 0.
       -r               Reverse  ping  (gnip?).  Send  echo response instead of echo request.
       -v               Verify response payload is identical to request payload.  It  is not  required  for  remote stacks to return the request payload, but most stacks do (including Bluez).
       bd_addr          The Bluetooth MAC address to be pinged in dotted hex notation like 01:02:03:ab:cd:ef or 01:EF:cd:aB:02:03

AUTHORS
       Written  by  Maxim  Krasnyansky <maxk@qualcomm.com> and Marcel Holtmann <marcel@holtmann.org>

       man  page  by  Nils  Faerber  <nils@kernelconcepts.de>,   Adam   Laurie <adam@algroup.co.uk>.

BlueZ                             Jan 22 2002                        L2PING(1)

Manual page l2ping(1) line 32/54 (END) (press h for help or q to quit)

We don't need to do anything fancy here, just ping the Bluetooth device as so:

~# l2ping 00:1D:A5:00:09:1D

Ping: 00:1D:A5:00:09:1D from ██:██:██:██:██:██ (data size 44) ...
44 bytes from 00:1D:A5:00:09:1D id 0 time 37.57ms
44 bytes from 00:1D:A5:00:09:1D id 1 time 27.23ms
44 bytes from 00:1D:A5:00:09:1D id 2 time 27.59ms
44 bytes from 00:1D:A5:00:09:1D id 3 time 27.31ms
44 bytes from 00:1D:A5:00:09:1D id 4 time 40.99ms
44 bytes from 00:1D:A5:00:09:1D id 5 time 48.77ms
44 bytes from 00:1D:A5:00:09:1D id 6 time 59.93ms
44 bytes from 00:1D:A5:00:09:1D id 7 time 48.84ms
44 bytes from 00:1D:A5:00:09:1D id 8 time 67.59ms

This indicates that the device is within range and reachable.

Step 5: Scan for Bluetooth Devices with btscanner

Now it's time to move on to the last tool we're going to cover, which is a full-on graphic user interface used to discover Bluetooth devices. It's called btscanner, and once we start it, we can type btscanner. But before doing that, since we've looked at the man pages for the rest of the tools, let's take a quick look here too:

~# man btscanner

BTSCANNER(1)                General Commands Manual               BTSCANNER(1)

NAME
       btscanner - ncurses-based scanner for Bluetooth devices

SYNOPSIS
       btscanner [--help] [--cfg <file>] [--no-reset]

DESCRIPTION
       This  manual page was written for the Debian GNU/Linux distribution be‐
       cause the original program does not have a manual page.

       btscanner is a tool designed specifically to extract as  much  informa‐
       tion  as  possible  from  a Bluetooth device without the requirement to
       pair. A detailed information screen extracts HCI and  SDP  information,
       and  maintains an open connection to monitor the RSSI and link quality.
       btscanner is based on the BlueZ Bluetooth stack, which is included with
       recent  Linux kernels, and the BlueZ toolset. btscanner also contains a
       complete listing of the IEEE OUI numbers and class lookup tables. Using
       the information gathered from these sources it is possible to make edu‐
       cated guesses as to the host device type.

OPTIONS
       --help           Show a help text and exit.
       --cfg <file>     Use <file> as the config file.
       --no-reset       Do not reset the Bluetooth adapter before scanning.

BUGS
       Please report any bugs to Tim Hurman <tim.hurman@pentest.co.uk>.

LICENCE
       btscanner is covered by the GNU General Public License (GPL).

SEE ALSO
       kismet(1).

AUTHORS
       Tim Hurman <tim.hurman@pentest.co.uk>

       This manual page was written by Uwe Hermann  <uwe@hermann-uwe.de>,  for
       the Debian GNU/Linux system (but may be used by others).

                                April 22, 2006                    BTSCANNER(1)

 Manual page btscanner(1) line 23/45 (END) (press h for help or q to quit)

You can see there's not much to btscanner, and that's because it's a GUI tool, so all of the magic happens after running the tool, so let's do that now:

~# btscanner

Opening the OUI database
Reading the OUT database

The interface might look kind of similar to people who are familiar with the Kismet interface, which kind of allows us to do a lot of stuff in the command-line format with a GUI type of feel. It's beneficial and cool because it means that by typing i, we can start doing an inquiry scan and find nearby Bluetooth devices, and it could allow us to connect or set a command or something like that.

We found a device, and it's the same Bluetooth device we saw before, and I'm sure that we'll be able to find some other devices as they roll in. For now, we can go ahead and press Enter to learn about the device.

Here, we can see the name of the device when it's first seen, the owner, which is interesting, and then some more information about the various features that are being advertised.

To go back to the main window, press Q, and as other devices are discovered, or as they come in range, we can find them here and start to learn more about what these devices are doing, what they're communicating with, what else they are capable of, and more.

If you don't have Bluetooth on your computer, you can always plug in a Bluetooth adapter, but you might want to check to make sure that it's compatible before you go ahead and go through the trouble. I'm not sure that every Bluetooth adapter is going to work with every Linux program.

Above, you can see we found a second device, so let's go ahead and click on it.

We can see that this is a smartphone — a Samsung device — and it has a lot more capabilities and things we could do with it than our first device did. Already, we're able to reach out and start looking at different devices. We can begin to learn about them, maybe the software running behind them, and certainly see the services that they're advertising to understand whether or not it represents a good attack surface.

All of the above is done with a fully updated version of Kali Linux, and we didn't have to install anything. So if you're starting fresh with Kali Linux, it's a great way to use some of the built-in tools to reach out and touch Bluetooth devices around you and begin to learn more about what each one of these versatile and powerful tools is capable of.

What We've Learned So Far

Today, we explored Bluetooth reconnaissance, and there are some more advanced things we can do with this information. Many Bluetooth devices don't bother to randomize their MAC address, meaning it'll be the same all the time. That can be used to track a person from place to place.

For instance, Tile Bluetooth trackers, where you can find a lost item by anybody who has the app running. That means that a person is trackable, and there is no way to turn it off. If you want to opt-out of that kind of tracking, make sure to disable Bluetooth on devices like a cell phone. But for devices that naturally have it turned on, like a Tile tracker, there's no option other than to leave it at home.