Bluetooth and IoT Wireless Threats
Learn the security weaknesses in Bluetooth (bluejacking, bluesnarfing) and IoT wireless protocols and how to minimize their risk footprint.
Bluetooth and IoT Wireless Threats is a free Cloud & IT Cert Prep lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Cloud & IT Cert Prep learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Bluetooth Security Fundamentals
Bluetooth is a short-range wireless technology (typically 10-100 meters) operating in the 2.4 GHz ISM band. It uses frequency hopping spread spectrum (up to 1600 hops per second) which provides some resistance to interference and casual eavesdropping. Bluetooth devices pair by exchanging a PIN or using Secure Simple Pairing (SSP). Security+ tests knowledge of Bluetooth-specific attacks, the security modes available in Bluetooth classic and BLE (Bluetooth Low Energy), and controls to minimize the attack surface of Bluetooth-enabled devices.
Bluejacking and Bluesnarfing
Bluejacking is a relatively benign attack that sends unsolicited messages to discoverable Bluetooth devices. It requires the target to have Bluetooth in discoverable mode and exploits the device's contact-sharing feature to push a vCard or message. More serious is bluesnarfing, which exploits vulnerabilities in the OBEX Push protocol to access contacts, calendar data, and files on a target device without pairing authorization. Bluesnarfing was a significant concern in early Bluetooth implementations (pre-2004) but has largely been patched in modern devices. Both attacks require proximity to the victim.
# Detecting discoverable Bluetooth devices:
hcitool scan
btscanner
# BlueZ tools for Bluetooth security testing:
hciconfig hci0 up
hcitool inq # inquiry scan
sdptool browse <BD_ADDR> # enumerate services
# Defense: disable discoverable mode when not pairing
# hciconfig hci0 noscanBluebugging and BIAS Attacks
Bluebugging exploits Bluetooth vulnerabilities to gain unauthorized control of a target device — making calls, reading messages, or intercepting communications — by abusing AT commands over Bluetooth. The BIAS (Bluetooth Impersonation Attacks) vulnerability (2020, CVE-2020-10135) affects the Bluetooth BR/EDR specification itself, allowing an attacker who has previously paired with a device to impersonate the remote device during authentication, bypassing the pairing process. BIAS affected almost all Bluetooth implementations until vendors released firmware patches. Keeping firmware updated is the primary defense.
Bluetooth Low Energy (BLE) Threats
Bluetooth Low Energy (BLE) is used in fitness trackers, medical devices, smart home gadgets, and beacons. BLE uses advertisement packets that devices broadcast continuously so other devices can discover them. These advertisements may contain device identifiers that can be used for tracking — following the physical location of a person based on their BLE devices. BLE connections with weak or no pairing (Just Works mode) can be sniffed and manipulated. Medical IoT devices using BLE with weak authentication pose particular risk because unauthorized commands can affect patient safety.
# BLE scanning and advertisement analysis:
blescan -d # scan for BLE advertisements
hcitool lescan # passive BLE scan
gatttool -b AA:BB:CC:DD:EE:FF --primary # enumerate GATT services
# BLE tracking mitigation:
# Use MAC address randomization (supported in iOS, Android, Windows 10+)
# Limits the ability to track devices across locations via BLE advertisementsIoT Security Challenges
IoT (Internet of Things) devices — cameras, smart thermostats, industrial sensors, medical monitors — introduce unique security challenges. They are often resource-constrained, running simple firmware that rarely receives security updates. Many ship with default credentials that users never change. IoT devices expand the attack surface dramatically: in 2016, the Mirai botnet compromised hundreds of thousands of IP cameras and DVRs using default credentials (admin/admin, root/root) and used them to launch massive DDoS attacks. Each unsecured IoT device is a potential entry point.
# Mirai botnet scanner pattern (educational reference):
# Scans internet for Telnet (port 23) and SSH (port 22)
# Tries common default credential pairs:
# root:root, admin:admin, root:admin, admin:1234, root:password
#
# Defense:
# Change default credentials immediately
# Disable Telnet; use SSH only
# Isolate IoT on separate VLAN with no internet access if possibleIoT Network Segmentation
The most effective network-level control for IoT devices is segmentation. IoT devices should be placed on a dedicated VLAN with highly restrictive firewall rules that allow only the specific outbound connections required for their function. Inbound connections from other internal network segments should be blocked entirely. For example, a smart thermostat may need outbound HTTPS to its cloud service but should never be able to initiate connections to internal file servers or databases. This limits the blast radius if a device is compromised.
# IoT VLAN firewall policy (conceptual):
# VLAN 40 (IoT): 10.40.40.0/24
#
# Allow outbound:
# ALLOW 10.40.40.0/24 -> ANY port 443 (HTTPS to cloud services)
# ALLOW 10.40.40.0/24 -> 10.30.30.5 port 1883 (MQTT to internal broker)
# Deny everything else:
# DENY 10.40.40.0/24 -> 10.10.10.0/24 (no access to corporate LAN)
# DENY 10.40.40.0/24 -> 10.30.30.0/24 (no access to servers)Zigbee and Z-Wave Security
Zigbee (IEEE 802.15.4) and Z-Wave are mesh networking protocols widely used in smart home and building automation. Zigbee uses AES-128 for encryption but security depends on key management: the trust center link key and network key must be protected. Early Zigbee implementations transmitted the network key in plaintext during device joining, allowing passive eavesdroppers to capture it. Z-Wave S2 (Security 2) improved this significantly. Researchers have demonstrated attacks including replay attacks on Z-Wave door locks that captured and replayed unlock commands.
# Zigbee security levels:
# Level 0: No security (no encryption, no authentication)
# Level 4: AES-128-CCM with 32-bit MIC
# Level 6: AES-128-CCM with 64-bit MIC
# Level 7: AES-128-CCM with 128-bit MIC (strongest)
#
# Key types:
# Network Key (NWK): shared by all devices in network
# Trust Center Link Key: used to securely deliver NWK keyNear Field Communication (NFC) Threats
NFC operates at 13.56 MHz with a range of about 4 cm. It is used for contactless payments, access badges, and device pairing. Despite the very short range, NFC is not immune to attacks. Eavesdropping on active NFC communication has been demonstrated at ranges up to 1 meter with sensitive antennas. Relay attacks use two colluding devices to extend the range of NFC, allowing an attacker near a victim (e.g., in a crowd) to relay the NFC signal to an accomplice at a payment terminal. This is a known threat to contactless payment systems.
RFID Security Issues
RFID (Radio Frequency Identification) is used in access badges, asset tracking, and supply chains. Passive RFID tags respond when powered by a reader's RF field and have no internal power source. Security issues include cloning (copying a legitimate badge to a blank tag using a Proxmark or similar reader), eavesdropping (capturing tag-to-reader transmissions from nearby), and replay attacks. Legacy HID cards at 125 kHz (EM4100, HID Prox) have no encryption and are trivially cloned. Modern smart card systems (13.56 MHz MIFARE DESFire, SEOS) use AES encryption and mutual authentication.
# RFID security comparison:
# HID Prox (125 kHz): No encryption, trivially cloned
# -> clone with Proxmark3 in seconds
# MIFARE Classic (13.56 MHz): Weak CRYPTO1 cipher, broken
# -> clone with low-cost readers
# MIFARE DESFire EV2/EV3: AES-128, mutual auth, secure messaging
# -> significantly harder to clone
# HID iCLASS SE / SEOS: PKI-based, strong encryption
# -> current best practice for physical accessSecuring Bluetooth Deployments
Practical controls for Bluetooth security include: set devices to non-discoverable mode when not actively pairing; use Secure Connections (Bluetooth 4.1+ with P-256 ECDH key exchange) instead of legacy Simple Pairing; require Numeric Comparison or Passkey Entry instead of Just Works pairing; enforce a minimum pairing PIN length; and apply manufacturer firmware updates promptly since many Bluetooth vulnerabilities are fixed via firmware. For corporate devices, MDM can disable Bluetooth entirely or restrict it to specific use cases.
# Enterprise Bluetooth controls via MDM policy:
# - Disable Bluetooth completely for high-security endpoints
# - Restrict to approved device pairing list
# - Require Secure Connections mode
# - Block Bluetooth file transfer (OBEX)
# - Log pairing events to SIEM
# Linux: control Bluetooth discoverable state
btmgmt power on
btmgmt connectable on
btmgmt discoverable off # not visible unless actively pairingIoT Lifecycle and Patch Management
IoT devices are often deployed for 5-15 years but receive firmware updates for only 2-3 years — leaving a large window of exposure. Organizations should include IoT in their asset inventory with model, firmware version, and end-of-support date tracked. When vendor support ends, devices should be replaced or isolated behind strict network controls. For critical systems, use IoT-specific security platforms (Azure Defender for IoT, Armis, Claroty) that passively profile device behavior and alert on anomalies without requiring agents on the devices.
Quick Check
Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.
Lesson Recap
In this lesson you learned: Bluetooth attacks including bluejacking, bluesnarfing, and BIAS exploit short-range wireless vulnerabilities and are mitigated by disabling discoverability and applying firmware patches, IoT devices pose significant risk due to default credentials, infrequent updates, and large deployment scale — mitigated with network segmentation and dedicated IoT VLANs, and RFID and NFC technologies used in access badges and payments face cloning and relay attack threats that require strong encryption and mutual authentication. Next up we explore phishing, spear phishing, and whaling attacks.
Frequently asked questions
Is the “Bluetooth and IoT Wireless Threats” lesson free?
Yes — the full text of “Bluetooth and IoT Wireless Threats” is free to read here on the web, and the Cloud & IT Cert Prep course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Cloud & IT Cert Prep course, upgrade to CoddyKit PRO.
What will I learn in “Bluetooth and IoT Wireless Threats”?
Learn the security weaknesses in Bluetooth (bluejacking, bluesnarfing) and IoT wireless protocols and how to minimize their risk footprint. You practise Cloud & IT Cert Prep with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Cloud & IT Cert Prep?
No prior experience is required. Cloud & IT Cert Prep on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Bluetooth and IoT Wireless Threats” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Cloud & IT Cert Prep lesson?
Yes. Every Cloud & IT Cert Prep lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Wi-Fi Security Protocols: WEP, WPA2, WPA3
- Wireless Attacks: Evil Twin, Deauth, and Rogue AP
- Enterprise Wireless: 802.1X and RADIUS
- Bluetooth and IoT Wireless Threats