What is it all about?

Bluetooth Low Energy incorporates device pairing and link-layer encryption. However, significant amount of devices do not implement these features. They either do not provide transmission security at all, or ensure it by own means in application layers. The vendors promise “128-bit military grade encryption” and “unprecedented level of security”, not willing to share technical details. We have seen such declarations before, and many times they did not withstand professional, independent evaluation and turned out to be “snake oil” security. It is about time to verify these claims, what is now possible with the help of our new open-source tool .

We share several already identified example vulnerabilities. We hope the community will come up with more, helping to develop new tool's features, cooperate with vendors, and in effect improve the security for end-users.

What attacks are possible?

There devices can be attacked in various ways - starting from simple denial of service, by spoofing, passive and active transmission interception, up to abuse of excessive and improperly configured device's services. In effect, the attacks can result among other thins in: You can find example identified vulnerabilities in the attached whitepaper.

What devices are vulnerable?

The attack is most effective against devices that do not implement Bluetooth security features (pairing). We have examined a handful of devices, including: Only about 2 out of 10 (mostly smart watches) did use Bluetooth security features correctly.

How can I check if my device is affected?

First, you can check in Bluetooth settings of your phone if the device is paired.

What hardware is necessary to perfom the attack?

The whole functionality of our tool is was tested on Raspberry Pi and other Linux systems with Bluetooth 4 adapters. Some of the attacks may be performed using a smartphone or other embedded devices. It is technically possible to implement the attacking device in a tiny, beacon-sized (a few square cm), battery-powered module.

What risk is associated with the attack?

The simplest answer is: that depends. For example, the current pulse indication from a smart wristband of a regular person rather will not be of interest for by-passing people. The situation may change dramatically if the person is a highly ranked official, and an adversary would like to know her pulse during important negotiations. Or - the wristband pulse indication is used as a biometric authentication in a banking application. Most attacks require close physical presence, so the risk is limited.

But, the attacker has to be close to the victim's mobile and device?

As the Bluetooth operating range is limited, in order to perform “Man-in-the-middle” attack, an attacker has to be close to your smartphone and the device.

However, some mobile applications have proximity features, which - improperly implemented - may be abused by approaching your smartphone away from the device and original location.

Also, devices may have vulnerabilities possible to exploit directly, without the need to interact with mobile application or intercept the transmission. In such case attacker needs to approach only the vulnerable device.

You can also imagine a mobile malware attacking BLE devices in range of the infected smartphone. Such malware is operated remotely, and the attack is theoretically possible on a mass-scale.

Additionally, there quickly emerges a new “Web Bluetooth” standard, that allows access to nearby BLE devices for web pages: here. Some attacks could be performed using javascript invoked from remote website.

But simple Denial of Service was possible before, using RF-jamming?

Yes, but performing such attack using generic RF-jammer was not straightforward nor discreet, as BLE is designed to be very robust against interference. With the new tool, which works in application layer, it is a magnitude easier - using simple tricks it is possible to enforce the victim's mobile phone to connect to impersonated device instead the original one, and then - for DoS scenario - just stall the further actions.

Why vendors choose not to use Bluetooth security?

One of commonly mentioned reasons is that vendors struggle to comply with various requirements: usability, multiple users or devices, cloud backup etc. The Bluetooth security features are handled by operating system, and the mobile application does not have full control over this process. That is why they decide to create own security mechanisms on top of the unencrypted Bluetooth LE link.

Will you publish a list of vulnerable devices?

We do not aim for that. Following responsible disclosure manners, we inform the vendors on our findings, and help them to fix, as we want to improve security of end-users. Disclosing vulnerability details straight away, before vendor releases patch, may expose users to attacks, and will usually not help to achieve this goal.

How does the tool work?

The tool creates exact copy of attacked device in Bluetooth layer, and then tricks mobile application to interpret its broadcasts and connect to it instead the original device. At the same time, it keeps active connection to the device, and forwards to it the data exchanged with mobile application. In this way, acting as “Man-in-the-Middle”, it is possible to intercept and/or modify the transmitted requests and responses.

Why does the application connect to “cloned” device instead the original?

Most mobile applications initiate connection to device by looking for advertising packets broadcasted by device. Usually battery-powered devices optimize advertising intervals in order to minimize power consumption. The attacker however can broadcast the relevant advertisements with minimal intervals (much “quicker”). The mobile application will interpret the first received advertisement - and in this case it will most probably be the spoofed one.
Additionally, as most devices do not broadcast advertisements during active connection, the attacker can just constantly keep connected to original device and thus prevent it from broadcasting.

What about Bluetooth encryption, pairing and bonding?

Depending on how the devices are paired, it may still be possible to attack such connection by abusing weaknesses in implementation and social-engineering. Details are in attached whitepaper.

Will the tool be available free of charge?

Yes. The tool is open-source, public, MIT-licensed. We count on you to help improve it.


We concluded growing Bluetooth Smart adoption and interest in it does not correspond with adequately growing interest of its security.
We believe end-users should be aware of possible attack scenarios and risks, and the vendors' claims on security should be reviewed by independent assessment.

What is the origin of a name “GATTack”?

The mobile application “talks” to device's “attributes” using Bluetooth LE GATT (Generic Attribute Profile) specification . The introduced attack scenarios and example vulnerabilities concern this layer of Bluetooth stack.

Will you publish more information?

Yes. Stay tuned.

I want to work with you!

We're hiring!

Other questions?

You can find us: more@gattack.io


You can download the white paper here


You can download the Black Hat USA slides here


A few videos here


Following initial research on Bluetooth Low Energy security by Mike Ryan:
the BLE hacking is on the rise.

Another very similar BLE MITM tool was presented at Defcon 24 IoT Village by Damien Cauquil.
Source code:

Defcon 24 "Picking BLE Locks from quarter mile away", "How do I BLE Hacking" by Anthony Rose, Jose Gutierrez and Ben Ramsey. Slides, source code:

We will soon update more details and other available tools (including blue hydra).

If you are aware of other research worth noting here, let us know!



The GATTacker tool is available on Github:

You can install it using npm:
npm install gattacker.