Map PAN, addressing and devices from cleartext headers

Mechanism

Zigbee runs on IEEE 802.15.4, which carries security at the MAC and (for Zigbee) NWK/APS layers but does not encrypt frame headers — the MAC header and the Zigbee NWK header are always in the clear, even when the payload is AES-128-CCM* protected [akestoridis2020zigator] [ieee802154-2024] [zigbee-spec-csa]. A listener that parks an 802.15.4 radio on the target channel can therefore read, with no key at all: the 16-bit PAN ID, the short (16-bit) and extended (EUI-64) source and destination addresses, and the frame control fields [kabibo2025securelist]. The Securelist industrial assessment states it plainly: “Even when Zigbee payloads are encrypted, the network and MAC headers remain visible. That means we can usually read things like source and destination addresses, PAN ID, short and extended MAC addresses, and frame control fields” [kabibo2025securelist].

Two kinds of finding follow from those cleartext fields. First, identifier enumeration: the PAN ID and extended PAN ID name the network, the operating channel locates it (Zigbee pins a PAN to one 2 MHz channel, 11–26, and stays there), and each device exposes a short address and — when it sends frames with extended addressing — its globally-unique EUI-64, a stable per-device identifier that supports tracking [zigbee-spec-csa] [kabibo2025securelist]. Second, topology inference: the Zigator work shows that by pairing the cleartext short MAC addresses of source and destination across captured packets, an attacker infers which devices communicate with which — reconstructing the coordinator/router/end-device relationships of the mesh without ever decrypting a payload [akestoridis2020zigator] [akestoridis-zigator-repo]. ZLeaks extends the point to the application level: from encrypted traffic alone, addressing and periodic-reporting metadata identify in-home devices and infer user events [shafqat2022zleaks].

Device discovery has an active counterpart worth knowing: a joining device broadcasts a beacon request across channels, and nearby coordinators/routers answer with beacons that advertise PAN ID, extended PAN ID, the coordinator address and stack profile in cleartext [kabibo2025securelist] [zigbee-spec-csa]. An assessor can provoke this with an active scan (KillerBee zbstumbler transmits beacon requests while channel-hopping [killerbee-repo]) — but transmitting beacon requests is an active step and must be authorised. The purely passive path is to listen for the beacons that occur naturally and the data frames that reveal addressing.

Procedure

Authorised testing only: capture on a network you own or are explicitly permitted to assess. Steps 1–4 are fully passive (receive-only). Step 5 (active beacon-request scan) transmits into the band and must be separately authorised — skip it if you only have passive authorisation.

1. Find the channel. Identify the operating channel before capturing. Use a passive survey rather than transmitting:

   kismet -c nrf52840_154-0:channels="11,15,20,25,26"

   Kismet channel-hops the 802.15.4 band and logs every PAN, coordinator and device it hears to pcapng without ever transmitting. Note which channel(s) show Zigbee PANs. (Channels 15, 20, 25 and 26 sit in the Wi-Fi gaps and are common Zigbee choices.)

2. Park and capture on the target channel. Pick the capture path for your radio. On an nRF52840 dongle with the nRF Sniffer 802.15.4 firmware, capture straight into Wireshark via its extcap; on a CC2531:

   whsniff -c 20 | wireshark -k -i -

   -c 20 selects channel 20; frames stream live into Wireshark. With KillerBee instead:

   zbdump -f 20 -w capture.pcap

   zbdump is a tcpdump-like tool that writes 802.15.4 frames to a libpcap file [killerbee-repo]. On a CatSniffer, catnip streams 802.15.4/Zigbee frames into Wireshark over its extcap.

3. Read the identifiers in Wireshark. Open the capture; the 802.15.4 and Zigbee dissectors decode the headers with no key [wireshark-802154]. Filter to the target PAN and list the addressing:

   wpan.dst_pan == 0x1a62 || wpan.src_pan == 0x1a62

   Read off, per frame: wpan.src16 / wpan.dst16 (short addresses), wpan.src64 / wpan.dst64 (EUI-64 when present), wpan.src_pan (PAN ID), and zbee_nwk.src / zbee_nwk.dst (NWK short addresses). Beacon frames (wpan.frame_type == 0) carry the PAN parameters and, for Zigbee, the extended PAN ID and stack profile.

4. Build the inventory and infer topology. Collect the distinct short addresses and EUI-64s into a device list, then pair source↔destination short addresses across data frames to infer who talks to whom — the coordinator (short address 0x0000) sits at the root; routers relay; end devices talk only to their parent [akestoridis2020zigator]. The Zigator tool automates this parsing and pairing over a pcap:

   zigator parse-pcap-file capture.pcap

   Inspect the produced tables for the address pairings and inferred relationships [akestoridis-zigator-repo].

5. (Active, authorised only) Provoke device discovery. If passive listening did not surface every device, an active scan elicits beacons:

   zbstumbler -c 20

   zbstumbler transmits beacon requests while channel-hopping and prints summarized information about the devices that answer [killerbee-repo]. This transmits — only run it with explicit authorisation on your own/permitted network.

Field case

Walkthrough against Zigator’s shipped test capture (akestoridis/zigator, zigator/tests/data/03-nwk-testing.pcap; the decoded result is documented in the project’s integration test, zigator/tests/test_integration.py) [akestoridis-zigator-repo]. These are crafted test fixtures, not a live network, but they reproduce exactly what a passive listener recovers from cleartext headers with no key: parsing the pcap and reading off PAN IDs, short and extended addresses, beacon parameters and the inferred topology. To reproduce against your own consenting network, substitute the identifiers you capture for the ones below.

Running zigator parse-pcap-file 03-nwk-testing.pcap over the fixture and inspecting the produced tables — with no network key loaded — resolves every header. The capture carries two PANs. In the larger cluster (PAN 0x7777) the coordinator announces itself at short address 0x0000 and discloses EUI-64 77:77:77:00:00:00:00:01 in extended-addressing frames; the short_addresses table lists 5 devices — 0x0000 (Zigbee Coordinator, FFD), routers 0x1102 and 0x1101 (both FFD), and leaf devices 0x2201 and 0x2202 — each bound to a globally-unique EUI-64 (7777770000000001–7777770000000005), a stable per-device identifier that persists across rejoins [akestoridis-zigator-repo]. Pairing source/destination short addresses across the captured frames recovers the topology directly from Zigator’s pairs table: leaf devices 0x2201 and 0x2202 each talk to router 0x1102, which in turn talks up to coordinator 0x0000 and across to router 0x1101 — i.e. 0x2201→0x1102, 0x2202→0x1102, 0x1102→0x0000, 0x1102→0x1101. That marks 0x1102 as a router relaying for its children, exactly the parent/child structure of a Zigbee mesh, derived without ever decrypting a payload. The second PAN (0x99aa) is named by a beacon whose extended PAN ID is facefeedbeefcafe, recovered from the cleartext nwk_beacon_epid field, with source extended address 1122334455667788 exposed in the clear. The integration test asserts these decoded values verbatim — PAN 0x99aa with extended PAN ID facefeedbeefcafe in the networks table, and the 0x7777 short-address/EUI-64/role rows in short_addresses — confirming that this is precisely what the dissector yields [akestoridis-zigator-repo]. None of it required the network key, only the capture on the right channel, which is the finding the control verifies: topology and persistent identifiers leak in the clear [akestoridis2020zigator] [akestoridis-zigator-repo] [kabibo2025securelist].

Remediation

The header exposure is inherent to IEEE 802.15.4 — MAC and NWK headers are not encrypted by design — so remediation is about limiting what those identifiers reveal and how usable they are, not eliminating the leak [ieee802154-2024] [akestoridis2020zigator].

• Developer (stack/firmware). Prefer NWK addressing that minimises extended-address (EUI-64) disclosure on air: once a device has a short address, avoid sending frames with the full EUI-64 in the clear where the spec allows the short form, to reduce the stable-identifier footprint [zigbee-spec-csa]. Do not place any sensitive identifier (serials, user IDs) in cleartext header or beacon fields. Where the platform supports MAC-layer source-address randomisation or topology-obfuscation features, expose and document them.
• Integrator (product/hub). Treat the network as observable: assume an unauthorised listener already knows the PAN ID, channel, device count and topology, and design so that knowledge alone grants nothing — keep all command authority behind the encrypted APS/ZCL layer with a properly provisioned network key and per-device install codes (not the well-known default Trust Center link key) [zigbee-spec-csa] [kabibo2025securelist]. Avoid encoding device function in predictable address patterns.
• Operator (deployment). Recognise that metadata leaks even under encryption: device presence, count and activity (event timing) are inferable passively [shafqat2022zleaks]. For sensitive sites, factor this into siting and shielding decisions, monitor for unexpected beacon-request scans (an active discovery attempt), and prefer the highest-assurance join model (install-code-only joining) so that observing the network yields reconnaissance but no path to join or decrypt.