Techzone/Defense: MAC Randomization

Defense: MAC Randomization

4 min readArticle

MAC randomization is a privacy feature built into modern operating systems that causes devices to send probe requests and associate to networks using randomly generated MAC addresses instead of the real burned-in hardware MAC. This directly undermines wardriving, probe-request tracking, and some deauth-based attacks.

How It Works

Every WiFi device has a burned-in MAC (OUI + device identifier). Historically, devices broadcasted this real MAC in every probe request — even when not connected — making passive tracking trivial. MAC randomization generates a random locally-administered MAC per scan cycle or per network.

Bit 1 of byte 0 in the MAC is the "locally administered" flag. If set, it's a randomized/spoofed MAC. Legitimate OUIs always have this bit clear.

shell
Real MAC:    d4:38:9c:12:34:56   (OUI d4:38:9c = Apple, globally unique)
Random MAC:  f2:a1:3b:77:cc:01   (f2 has bit 1 set = locally administered)

Platform Behavior

Platform Behavior
iOS 14+ Randomizes per network by default; stable per SSID
Android 10+ Per-network random MAC by default
Windows 10+ Random MAC for scanning; can enable per-network
macOS Big Sur+ Per-network randomization; off by default but available
Linux (NetworkManager 1.4+) Supports random MAC via wifi.cloned-mac-address=random

Effect on Attacker Tools

Probe Request Tracking / Wardriving

Tools like Kismet or the ESP8266 probe sniffer see different MACs every scan cycle from the same device. You can't track a person's movement across time because every probe looks like a new device.

bash
# Kismet shows randomly generated MACs — hard to correlate over time
# Probe flood illusion: one device can appear as dozens in airodump-ng
airodump-ng wlan0mon
# You'll see many entries cycling through random MACs with no connected state

Deauth Attacks

Deauth frames are sent to the client's MAC. If the client is associated to an AP, the association uses a stable MAC (some platforms randomize per-network but keep it stable during the session). So deauth still works during an active session — the attacker can read the MAC from airodump-ng while the client is connected.

bash
# In airodump-ng output, STATION column shows current MAC (may be random but stable for session)
# Deauth works against that session MAC — randomization doesn't protect during active connection
aireplay-ng --deauth 10 -a <AP_BSSID> -c <CLIENT_MAC> wlan0mon

Where Randomization Breaks Down

  • Probe requests for specific SSIDs (directed probes) — some older implementations include the target SSID in probes, revealing networks the device has connected to before
  • Timing correlation — if a device appears at location A, disappears, and a new random MAC appears at location B at the same time with the same signal strength pattern, correlation is still possible
  • Vendor-specific bugs — some Android OEMs randomize the MAC but keep the same sequence numbers or timing patterns, enabling fingerprinting without the MAC
  • WPS association — WPS exchanges sometimes reveal the real MAC

Detecting Randomized MACs

bash
# Check if a MAC is locally administered (randomized)
python3 -c "
mac = 'f2:a1:3b:77:cc:01'
first_byte = int(mac.split(':')[0], 16)
print('Locally administered (random)' if first_byte & 0x02 else 'Globally unique (real OUI)')
"

# In Wireshark: filter for locally administered MACs
# Filter: eth.src[0] & 0x02

Configuring MAC Randomization on Linux

bash
# Check NetworkManager version (need 1.4+)
nmcli --version

# Enable per-network random MAC
nmcli connection modify "MyWiFi" wifi.cloned-mac-address random

# Enable random MAC for all scanning (system-wide, /etc/NetworkManager/NetworkManager.conf)
# [device]
# wifi.scan-rand-mac-address=yes

# Manual temporary MAC change
sudo ip link set wlan0 down
sudo ip link set wlan0 address f2:$(openssl rand -hex 5 | sed 's/\(..\)/\1:/g;s/:$//')
sudo ip link set wlan0 up

Bypassing Randomization as an Attacker

  1. Wait for association — once connected, the session MAC is stable and visible in airodump-ng
  2. Exploit probe SSID leakage — listen for directed probes to known SSID names; correlate device to person by SSID list
  3. Signal strength fingerprinting — RSSI patterns, timing, and frame intervals can fingerprint a device without MAC
  4. Target the AP side — instead of tracking the client, attack the AP; clients have to reveal a session MAC upon association

Defense Checklist

  • Enable MAC randomization on all mobile devices (iOS, Android — on by default in modern versions)
  • Disable "auto-join" for old networks to prevent directed probe leakage
  • On Linux: configure NetworkManager with wifi.cloned-mac-address=random
  • Don't rely on MAC filtering as a security control — it's easily bypassed by spoofing a visible MAC

Reference

techzonesite.comUnlock Your IT Potential