BLE eavesdrop + replay → smart lock open

§ Context

Assumed environment: target deployment uses a BLE-only smart lock (no internet companion). The pairing is unauthenticated (Just Works) and the unlock command is not nonce-protected.

§ Steps

1. 01
   Physical entry to target areaInitial Access

   T1078— Valid Accounts
2. 02
   Extract write to unlock characteristicDiscovery

   T1083— File and Directory Discovery
3. 03
   Fingerprint BLE service + characteristic UUIDsReconnaissance

   MOB-APK-REVERSE— APK Reverse Engineering
4. 04
   Sniff legit unlock (Sniffle / Ubertooth)Credential Access

   IOT-BLE-EAVESDROP— BLE Eavesdropping
5. 05
   Replay from attacker deviceLateral Movement

   IOT-BLE-REPLAY— BLE Replay

§ References

• T1078Valid Accounts
• T1083File and Directory Discovery

§ Frequently asked

What is the "BLE eavesdrop + replay → smart lock open" attack path?

Smart lock uses BLE Just-Works pairing + plaintext 'unlock' opcode. Sniff once with a nRF52 in monitor mode, replay later from a $10 device. It chains 5 steps drawn from real-world offensive-security techniques.

What starting position does this attack require?

The first step is Physical entry to target area (T1078) — a initial access primitive. Assumed environment: target deployment uses a BLE-only smart lock (no internet companion).

What is the final impact of this kill-chain?

The final step lands on Replay from attacker device (IOT-BLE-REPLAY), which falls under Lateral Movement. From here, an operator typically pivots into post-exploitation or maintains persistence.

How can defenders detect or prevent this attack?

Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.

§ Related dossiers

• Shared techniques3

  Exported ContentProvider → private data leak

  App exports a ContentProvider for legitimate inter-app integration but forgets to enforce grantUri / signature permissions — a rogue installed app reads private auth tokens.

• Shared techniques2

  Deeplink abuse → in-app account takeover

  Exported activity registers a custom URL scheme that triggers an OAuth-style 'confirm reset' action without validating the source — phishing URL clicks reset another user's password.

• Shared techniques2

  iOS URL scheme hijack → OAuth code theft

  Multiple apps register the same custom URL scheme — a rogue app installed alongside the target receives the OAuth callback containing the authorisation code, then exchanges it for tokens.

• Shared techniques2

  User foothold → keychain dump → cloud creds

  Standard user shell on macOS. Brute the login.keychain master via ChainBreaker / a keylogged password; dump all entries — Safari saved creds, AWS keys, Slack tokens, SSO cookies.

• Shared techniques2

  SUID binary → root via GTFOBins

  Find an unusual SUID binary (find / nmap / vim / awk / less), check GTFOBins for the privilege-escalation primitive, spawn a root shell.