Tutorial — investigate an unknown device

Your AirLeak fires an alert. A new device — not in your library, not matching your expected vendors. What is it? This tutorial walks through the standard "unknown device" investigation flow.

Setup

You have:

• An AirLeak running, ideally with an active session.
• An alert that fired on a device you don't recognise (or you noticed it in the live view).
• Authorisation to investigate (your own space, your own engagement, your own infrastructure).

Step 1 — Capture the basics

Click the alert (or the device in the live view). The detail panel opens. Note:

• MAC address — first 3 bytes are the OUI (vendor).
• Vendor — Companion's lookup of the OUI.
• Best RSSI — current signal strength.
• First seen — when this device first appeared.
• Device type — Wi-Fi station / AP, BLE.
• Apple model (BLE only) — when applicable.
• Class label — Companion's behavioural classification.

Pin the device to your watch list. You want it visible across the rest of the investigation.

Step 2 — Check the library

Switch to the Library view. Search the MAC.

Three outcomes:

• Match — the device is in your library from a previous session. Click into the entry; the cross-session history tells you when you've seen it before. Often this resolves the investigation immediately ("ah, it's the printer in the closet").
• No match, but Apple model is known — Apple devices broadcast Continuity model identifiers. The library may not yet have this MAC but may have this Apple model. Search by Apple model.
• No match at all — first-time-ever observation. Continue.

Step 3 — Watch the device's behaviour

Return to the live view. Watch the device's row for 1-2 minutes:

• Does the RSSI change? Stable RSSI means the device isn't moving. Climbing / falling RSSI means it is.
• What channel is it on? A device that hops channels behaves differently from one that stays on a single channel.
• Are there bursts of activity or a steady stream? Bursty = something happening intermittently. Steady = continuous service.

These observations narrow the device class:

• Wi-Fi station, bursty, low RSSI → probably a phone, often someone walking by.
• Wi-Fi AP, steady, low RSSI → a neighbour's router.
• BLE, steady, advertising every few hundred ms → a wearable or smart-home device.
• BLE, very low duty cycle, infrequent broadcasts → a battery-powered tracker.

Step 4 — Check probed SSIDs (Wi-Fi)

If the device is a Wi-Fi station, look at its probed SSIDs:

• Probed SSIDs are Wi-Fi networks the device "remembers" being connected to.
• A device with no probed SSIDs has been idle or is using MAC randomisation that hides them.
• A device probing for "iPhone-Joe" or "AndyAndroid-AP" gives you a strong identity signal — the device's owner deliberately or accidentally named themselves.

The probed SSIDs alone often resolve the investigation: "this device probed for home-wifi, office-secure, gym-network — that profile fits a person who lives, works, and exercises in those places, and right now they're walking past my AirLeak."

Step 5 — Look at the Apple Continuity payload (BLE)

If the device is BLE Apple, the Continuity payload often distinguishes:

• iPhone (specific model when distinguishable).
• iPad.
• MacBook.
• AirPods variant.
• Apple Watch.
• AirTag.

A device showing "AirPods Pro 2" tells you a lot more than "Apple Inc." on its own.

Step 6 — Check timing

When in the day did the device first appear? When did it disappear? The pattern of presence is informative:

• 9 AM weekday — commuter / colleague arriving for work.
• Late evening — could be a guest in an apartment building, a delivery driver, etc.
• Continuous 24/7 — fixed-location IoT or infrastructure.
• Random sporadic — could be a passerby on a street.

Check the per-device detail's first-seen / last-seen timeline.

Step 7 — Walk the space

For a device you can't identify by metadata alone, mobility helps:

1. With the AirLeak in hand, watch the device's RSSI in the live view.
2. Walk through the space. Note where RSSI peaks.
3. The peak indicates the device's general location.

Sometimes "I don't know what device this is" becomes "ah, that's the smart light in the kitchen I forgot about" once you localise.

Step 8 — Compare with the OUI

Companion's vendor lookup uses the OUI (first 3 bytes of the MAC). The vendor is informative:

• Apple, Samsung, Google, etc. — consumer mobile devices.
• Sonos, Bose, Sony — audio equipment.
• Amazon, Google (Nest), Eufy, Ring — smart-home.
• Cisco, Aruba, HP — enterprise networking.
• Espressif, Texas Instruments, Nordic Semi — DIY / IoT chipsets.

For devices using locally-administered MACs (the second-least-significant bit of the first byte is set), the OUI is not a real vendor — it's whatever the firmware or random allocation chose. Companion flags this on the device row.

Step 9 — Cross-reference with sessions

Look at this device's history across other sessions:

• If the device has been around in past sessions: pattern of presence is the answer ("it's around every weekday morning").
• If this is the first appearance ever: it's new to your environment. Could be a visitor, a new neighbour, a recently-installed device.

Step 10 — Tag and document

Whatever you concluded:

• Identified positively — assign a friendly name in the library. ("Alice's AirPods", "kitchen Sonos", "neighbour's printer".)
• Identified by class — tag the library entry with the class. ("unknown-airpods", "unknown-iot-likely-light".)
• Could not identify — tag with "unknown" and a date. Document what you tried.

The act of writing it down is the discipline that prevents you re-investigating the same device three weeks later.

Step 11 — Decide whether to escalate

Some unknowns are worth escalating:

• A device probing for a sensitive SSID (your corporate Wi-Fi) from outside the building.
• A device with very high RSSI in a space where you wouldn't expect any guest.
• A device that appears at suspicious times.

Escalation depends on context — your security team, your landlord, your local resources. The toolkit's role ends at the documented unknown; the response is yours.

What you have at the end

• The device identified, classed, or documented as unknown.
• A library entry tagged appropriately.
• A pattern of presence understood (when it appears, when not).
• Optionally, an alert rule configured for future appearances.

This is the standard "weird device" investigation. After ten of these, the patterns become familiar — most "unknown" devices resolve within a few minutes.

Where to go next

• Library — for the cross-session aggregate view.
• Tracking — when the device deserves continued attention.
• AI triage workflow — when you want the AI assistant to summarise across many devices.