Wardriving for OSINT: Reading the Wireless Layer Without Crossing the Line
Most people hear wardriving and immediately picture hackers driving around with antennas, laptops, stickers and WiFi passwords.
For me, wardriving is not about getting into WiFi networks. It is not about collecting authentication material from random access points. It is not about attacking infrastructure that is not yours.
That is a different world. It has different rules, different permissions and, if you get it wrong, very real consequences.
The OSINT value sits somewhere else.
The question is simple:
What does the wireless environment tell us about this place?
Almost every location has a wireless layer. We just do not see it with our eyes.
Walk past an office building and you will see the entrance, signs, vehicles, cameras, barriers, loading docks, visitors and people going in and out. Around that same building there may be WiFi networks, Bluetooth Low Energy (BLE) advertisements, printers, cameras, sensors, trackers, guest networks, temporary event infrastructure and devices that have been there for years.
That layer can tell a story.
Not a complete story. Not always a reliable one. And never a story that should be taken at face value. But it can create leads, expose inconsistencies, support geolocation and show change over time.
This article is about using that layer responsibly. The focus is a practical field workflow with the Biscuit Pro, Biscuit Manager and WiGLE. The method applies to other collection tools as well.
The aim is to observe, document, compare, validate and ask better questions.
It is not to attack, connect to or interfere with someone else's wireless environment.
Before anything else: this is not “open source” by default
An SSID being broadcast does not turn every possible collection method into OSINT. A BLE device advertising a short packet does not give an investigator a free pass to build a movement profile of the person carrying it. “It was visible to my device” and “I was entitled to collect, retain, upload and publish it” are not the same sentence.
Local law, contract, property rules, privacy law and the mandate for the work all matter. So does common sense.
Public space is not a magic exemption. A client engagement is not a blank cheque. If I am working for an organisation, I want the scope in writing: location, timeframe, systems in scope, collection modes allowed, who receives the data and how long it will be retained. If I cannot explain the method to the client, my employer, an editor or a court, I need to change the method.
This is not legal advice. It is an operational rule: do the legal and ethical work before the technical work.
A necessary line around the Biscuit Pro
The Biscuit Pro is a capable, phone-controlled wireless security device, and it is currently my go-to device. Its current documentation describes dual-band 2.4 GHz and 5 GHz WiFi, Bluetooth support, GPS-backed wardriving and WiGLE upload support. It also documents capabilities that go far beyond the scope of this article, including active testing functions and packet capture. Read the current product documentation before using it.
That is exactly why the boundary needs to be explicit.
For the workflow below, my collection scope is limited to the minimum information needed to answer an intelligence question. No joining networks. No credential capture. No deauthentication. No spoofing. No captive portals. No attempts to enumerate or track people through their devices. No publishing of sensitive raw identifiers.
Do not confuse a tool with a method. The device is capable of more than this article describes. That does not make those capabilities part of an OSINT engagement.
There is one technical caveat worth understanding as well. “Scanning” is not automatically synonymous with “receive-only.” Depending on the device, its configuration and the radio protocol, a scan may involve transmissions such as probe requests. If your assignment requires strictly passive, receive-only collection, confirm the actual collection mode in the current vendor documentation and test it in a lab you control. Do not assume that “I did not connect” means “my equipment transmitted nothing.”
That is not being pedantic. It is the difference between a defensible collection plan and a guess.
Start with an intelligence question, not a gadget
Do not start by pressing Start.
People buy a device, collect everything it can see and only then ask what the data means. That produces a large file, a long list of identifiers and very little intelligence.
The tool follows the question.
Here are a few questions where a carefully scoped wireless observation can make sense:
A company claims to operate from a particular address. Are there public-facing wireless indicators that support or challenge that claim?
A client is preparing for an event. What changes in the wireless environment occur before, during and after the event?
A photo, video or livestream contains a WiFi name. Does it support a geolocation hypothesis when combined with visual evidence?
An organisation wants an external exposure review of its own premises. What naming, legacy or vendor breadcrumbs are broadcast beyond its perimeter?
An authorised office, meeting room, vehicle, hotel room or event space has a possible tracking-device concern. Is there an unusual BLE advertisement that needs physical inspection by an authorised person?
A location matters to an investigation over time. Which radio observations are stable, and which are new or gone?
“What can I collect here?” is not an intelligence question.
“Which wireless observations could reduce uncertainty in this case?” is one.
It sounds like a small change in wording. It changes the entire workflow.
The wireless layer in plain language
You do not need to be a wireless engineer to use this material properly. You do need to know what the fields mean, what they do not mean and where the data is likely to lie to you.
WiFi
WiFi access points regularly advertise management information so devices can discover available networks. A field collection may show some of the following.
Field | What it is useful for | What it does not prove |
SSID | The human-readable network name. It may reveal a company, hotel, vendor, department, event or naming convention. | Who owns the network, the precise building it belongs to or who is connected to it. SSIDs are easy to reuse and easy to change. |
BSSID | The identifier for a specific WiFi basic service set; in practice, often a radio-related MAC address broadcast by an access point. It is more granular than an SSID and useful for comparing observations. | A permanent serial number or a guaranteed physical access-point identifier. Virtual BSSIDs, replaced hardware and configuration changes exist. |
Band, channel and frequency | Helpful context for comparison and for understanding why one network was seen from one position and not another. | Distance, ownership or the location of the access point. |
RSSI / signal level | A rough measure of received signal strength at your collector. It can help compare the same signal across a controlled walk. | Exact distance or a map pin for the transmitter. Walls, windows, vehicles, reflections, antennas and phone position all affect it. |
Security label | A clue about the network's advertised configuration and potential defensive hygiene. | Whether a network is “safe,” in use, owned by the named organisation or vulnerable. |
Time and GPS point | A record of when and where you observed the signal. | The exact location of the radio. The point follows the observer, not necessarily the access point. |
An SSID is a label. Treat it like a sign on a door: interesting, sometimes useful and never enough on its own.
A BSSID usually lets you be more precise. Several access points may broadcast the same SSID across a building, campus or hotel. One access point may broadcast more than one SSID. Consumer hardware can be moved. Enterprise hardware can be replaced. A BSSID is a strong pivot, not an identity document.
Technical sidebar: OUI and vendor enrichment
For a conventional, globally assigned MAC address, the opening part of the address can be looked up in the IEEE registration data. This is commonly called an OUI, although the current IEEE registry also uses the term MAC Address Block Large (MA-L). It may tell you which organisation received the address block.
That can be useful as a triage clue. A cluster of BSSIDs assigned to a known WiFi manufacturer may support a hypothesis about a site's hardware family. It may help explain why several seemingly unrelated BSSIDs belong together. It can also help an authorised organisation identify a forgotten class of equipment during an exposure review.
It does not identify the owner of the access point.
The organisation in the registry may be the hardware manufacturer, a radio-module supplier or a company that later sold or assigned the device. Locally administered and randomised addresses complicate this further. Treat an OUI result as “this identifier is consistent with hardware or an address block associated with X,” never “X operates this network.”
The IEEE Registration Authority public listing is the primary source for this type of lookup. Preserve the original BSSID before normalising it for a search, and record the date of the lookup. Registries and corporate ownership change.
BLE
BLE works differently. Devices can transmit short advertisements intended to be discovered by nearby devices. Those advertisements can be associated with tags, wearables, earbuds, sensors, beacons, smart locks, payment terminals, cameras, vehicles and many other things.
BLE is useful for patterns and anomalies in an authorised environment. It is not a licence to catalogue the movements of random people.
Privacy also gets complicated quickly. Many modern devices use rotating or randomised addresses. The name shown by a scanner may be generic, absent or misleading. A device category guessed by an app is a lead, not a conclusion.
If I see something tracker-like near a boardroom, I do not write “surveillance device found.” I write down where and when it was observed, whether it appeared on repeated sweeps, whether it can be explained by known equipment and whether an authorised physical inspection is required.
That is triage. Panic is not analysis.
Technical sidebar: why BLE needs a different standard of caution
Do not apply WiFi logic directly to BLE.
WiFi access-point BSSIDs are often stable enough to act as useful location pivots. BLE advertisers may use public addresses, static random addresses or privacy-preserving private addresses. The latter can rotate. A scanner may also show a product category or friendly name that is absent, generic or inferred rather than confirmed.
So a BLE hit is normally best read as a time-and-place observation: “an advertisement with these characteristics was received here, under these conditions.” It is not automatically a durable identity. The Bluetooth specification explicitly supports random and resolvable private addresses; that is a privacy feature, not a puzzle to work around. Bluetooth Core Specification
With a resolvable private address, the identity can only be resolved by a device that holds the relevant Identity Resolving Key (IRK). An RPA can only be cryptographically resolved to a known peer using the relevant IRK - typically exchanged and stored during a bonded relationship.” An IRK is not necessarily created by pairing; it is exchanged/stored there.. A passive OSINT collector does not have that key. The Bluetooth specification recommends a 15-minute timer for generating a new resolvable private address, though implementation choices vary.
This affects the data in a very practical way. An apparent rise in BLE addresses between two field passes does not necessarily mean more physical devices appeared. One device may have rotated its address. A stable address may be a fixed beacon, sensor or building system; it is not proof of a person. If the collection tool exposes it, record the address type alongside the raw address, timestamp, place, advertised name or service clue, RSSI, recurrence and the tool's classification. If it does not expose the address type, record that blind spot too.
For OSINT, that means BLE is strongest in narrow, authorised questions: is there a recurring, unexplained device category in this room, vehicle or event space? It is weak and ethically risky when the question becomes “where has this person been?”
A wireless observation is not attribution
This is the most important analytical rule in the article.
Wireless data can establish that a radio was observed. It can sometimes support an association with a location. It rarely establishes who owns, operates or carries the device without independent evidence.
Level | What the evidence can support | Reporting language |
1. Radio observation | A particular SSID, BSSID or BLE advertisement was received at a defined time and collection point. | “BSSID XX:XX:… was observed from the public pavement at 09:14.” |
2. Location association | The observation is consistent with a candidate site or area after considering range, repeated observations and historical context. | “The BSSID is consistently associated with the candidate area.” |
3. Entity or asset attribution | Independent sources connect the radio or naming pattern to an organisation, asset or operation. | “The combined evidence is consistent with an organisational asset at the site.” |
Do not skip levels.
An SSID using a company name is Level 1. A group of BSSIDs observed around a building, supported by WiGLE history and physical context, may reach Level 2. It becomes Level 3 only when other evidence - asset records, signage, supplier material, official photography, public filings or authorised internal confirmation - makes the association reasonable.
This model also gives you a clean way to explain uncertainty to a client. The radio is a source. It is not a witness.
Signal quality and false certainty
Wireless data looks precise because it has coordinates, timestamps and signal numbers. That precision can be misleading.
RSSI is not a range finder. A stronger signal can be a useful clue when you compare the same BSSID during a controlled walk, but it does not tell you an exact distance. Walls, glass, vehicles, antenna orientation, reflections, body position and the receiver itself all change the result. Use phrases such as “stronger at the northern entrance” rather than “the access point is 20 metres inside the northern entrance.”
Band is context, not proof. In ordinary conditions, 2.4 GHz WiFi often travels and penetrates obstacles differently from 5 GHz WiFi. That can explain why one BSSID is visible farther along a route than another. It cannot tell you who owns the radio or precisely where it is mounted.
A mapped point is an estimate. WiGLE works from contributor observations and uses accumulated observations to estimate a likely network location. It is not a professionally surveyed inventory of access-point coordinates. A point is useful for candidate ranking and route planning; it is not a pin you should copy into a report as the exact transmitter location. WiGLE has confirmed that network locations are recalculated as new observations arrive.
No result is not a negative finding. No WiGLE record may mean nobody uploaded from that area. No result in your own collection may mean the access point was off, moved, shielded, outside the received band, missed by the scan timing or simply beyond range. The correct phrase is: “not observed under these collection conditions.”
Dates are observation dates. “First seen” and “last seen” usually tell you when the database observed a radio, not the day it was installed, switched off or physically moved. They are useful boundaries for a hypothesis, not a facility timeline by themselves.
Why radio identifiers are getting less durable
Radio identifiers remain useful. The mistake is treating them as permanent labels.
Modern privacy features, mobile hotspots, changing hardware and wireless configuration mean that the reliability of an identifier depends on what is broadcasting. Start by separating four things that are too often mixed together:
Identifier | Usually represents | What can change it |
SSID | A human-readable network label. | The operator can rename it, copy it or use the same name across many access points. It was never a durable identity. |
AP BSSID | A WiFi basic service set, normally an access-point radio identity. | Hardware replacement, virtual BSSID design, configuration changes and mobile hotspot behaviour can change it. |
Client WiFi MAC | The address a phone, laptop or other client uses while scanning for or joining WiFi. | Modern operating systems increasingly randomise it to resist passive tracking. |
BLE advertiser address | The address used by a BLE device in its advertisements. | It may be public, static random, non-resolvable private or resolvable private; private forms can rotate. |
The AP BSSID and the client WiFi MAC are not the same thing.
When an investigator looks up a BSSID in WiGLE, they are normally using an access-point-side identifier. Client MAC randomisation does not automatically make that access-point pivot useless. A fixed office, hotel or home access point may retain a usable BSSID for a long time.
Client randomisation does, however, make it much harder and less appropriate to treat observed client devices as durable identifiers. Apple and Android use randomised addresses in a range of client-side WiFi scenarios specifically to reduce passive tracking. That is one reason this article does not include client enumeration or probe-request tracking as an OSINT method. Apple privacy documentation and Android MAC-randomisation documentation
The mobile-hotspot use case needs even more caution. Android supports MAC randomisation for Soft AP BSSIDs, and Android documents MAC randomisation in client mode, Soft AP and Wi-Fi Direct. Apple documents randomised MAC addresses for Personal Hotspot and Internet Sharing, with new addresses generated when those interfaces start. A phone or laptop hotspot can therefore keep the same SSID while presenting a different BSSID on a later day or after an interface restart. Android Soft AP documentation and Apple Platform Security
The consequence is straightforward:
A repeated exact BSSID remains a useful lead. A changed BSSID does not rule out the same mobile hotspot, travel router or operational asset.
This is not a reason to give up on wireless OSINT. It is a reason to lower the confidence of a single identifier, preserve the dates and collection conditions, and seek independent corroboration.
Build a collection plan that can survive scrutiny
Before a field visit, create a one-page collection plan. It does not need to be formal or complicated. It does need to exist before the data starts accumulating.
Item | Example |
Case / intelligence question | “Assess whether public wireless observations support the claimed operational use of Location A.” |
Authority and boundaries | Written client authorisation; public pavement only; 07:00–09:00 and 17:00–19:00; no entry to private grounds. |
Radio scope | Minimum necessary WiFi discovery data and BLE advertisements only; no connection, authentication capture, traffic capture or active functions. |
Collection route | One defined perimeter route, walked in the same direction on each visit. |
Supporting notes | Entrances, company signs, loading areas, event build-out, visible vendor vehicles and nearby sources of RF noise. |
Data handling | Raw export stays in the case folder; identifiers are masked in the report; no upload without a deliberate decision and authorisation. |
Retention | Define who holds the raw data, where and until when. |
Add the device model, app version, firmware version, phone used, time source and GPS status. It may feel excessive for a short walk. It becomes extremely useful when someone asks why the data from Tuesday does not match the data from Thursday.
OSINT is not just finding something. It is being able to show how you found it and how much confidence it deserves.
A basic case-folder structure
Keep the raw collection away from screenshots, working notes and the final report. A simple structure is enough:
case-name/
01-collection-plan/
02-raw-exports/
03-route-and-field-notes/
04-screenshots-and-photos/
05-analysis/
06-report/Name files so that future-you can understand them: 2026-09-09_location-a_perimeter-pass-01.csv is far better than wardrive-final-final2.csv.
If the work may become evidence, preserve the original export, record the date and time you received it, and work from a copy. The exact preservation process depends on the assignment and jurisdiction, but the principle does not: do not quietly edit the only copy of your source data.
A practical, repeatable field workflow
This is a deliberately conservative workflow. It is useful for a beginner and still disciplined enough for professional work.
1. Do the desk work first
Map the location. Look at satellite and street-level imagery, company websites, public records, event information, social media, past imagery and business directories. Identify the likely entrances, neighbouring businesses, public routes and obvious sources of confusion such as a café, hotel, shopping centre or shared office building.
The goal is not to decide the answer before you arrive. The goal is to know what you need to observe.
For a location-claim question, write a short hypothesis in advance:
If the organisation actively uses this building, I may observe its naming convention or known vendor infrastructure near the relevant perimeter. Any such observation will require corroboration because neighbours, former tenants and generic SSIDs may produce the same result.
Writing that down protects you from seeing what you hoped to see.
2. Test the equipment where you have permission
Charge the Biscuit Pro. Update the firmware only if you have time to test it afterwards. Check the Biscuit Manager connection, phone location permission, date and time, battery level, map behaviour, export destination and the exact collection mode.
Run a short test around your own network or another authorised environment. Confirm that the export contains what you expect and no more than your plan allows. Learn where sessions are stored and how to stop them cleanly.
Do this at home or in a lab. The pavement outside a target location is a poor place to discover that your phone has no GPS fix or that an app update changed the export format.
3. Capture the context before starting the radio collection
Record the weather if it is likely to matter, the date, the start time, the route and the reason for the pass. Note physical features as you go: signs, unit numbers, entrances, loading docks, visible cameras, temporary barriers, event signage, trucks, construction work and neighbouring businesses.
You are not collecting a WiFi list. You are collecting a location assessment.
At a hotel, the lobby and the street outside may be separated by concrete, glass and many radios. At a mixed-use building, the strongest SSID near one door may belong to the café next door. Context prevents bad attribution.
4. Collect consistently and stay inside the scope
Use the planned route. Walk at a steady pace. Keep the phone position reasonably consistent if RSSI comparison matters. Mark the start and end of each pass. If a junction, entrance or loading dock is relevant, make a contemporaneous field note rather than trying to reconstruct it from memory later.
Do not linger outside a location simply because the screen is interesting. Do not change the route halfway through without recording why. Do not turn a passive observation into a test of someone else's network.
For a single location, one pass is a snapshot. Two or three comparable passes, at different times, begin to show a pattern. Repeating the same route before, during and after an event can be more useful than one long walk with thousands of observations.
5. Stop, preserve and make a collection log
End the session when the route ends. Export the data into the case folder and retain the original. Write a few lines while the visit is still fresh:
Start and end time.
Exact route and any deviation.
GPS quality or loss of location.
Device and app status.
Environmental notes that may affect coverage.
Anomalies worth reviewing later.
Whether data left the device, and if so where it went.
This is where a field collection becomes repeatable rather than anecdotal.
6. Triage the data before you search the internet
First, review your own data against the collection question. Avoid turning every generic SSID into an investigative lead.
Start with four simple filters:
Specificity - Does a name relate to the organisation, a known vendor, a project, an event or a location? Guest is weak. ExampleCorp-AV-Production is more interesting, though still not proof.
Place - Was it observed around the whole route, only at one entrance or only beside a neighbouring business?
Time - Was it present on every pass, only during office hours or only during an event build-out?
Repetition - Does the same BSSID or BLE advertisement recur under comparable conditions?
Then compare the result with your field notes. A network labelled with a company name near a visible company sign is a stronger lead than the same label two streets away. A temporary-sounding network outside a loading bay while production trucks are present is context, not proof of ownership.
7. Use WiGLE as a historical and geospatial pivot
WiGLE is a large, volunteer-contributed collection of geolocated wireless observations. Its own Android client describes the project as a tool for detection, logging, search and export of WiFi, Bluetooth and cellular observations - and explicitly says it is not a tool for accessing networks without authorisation. Its public project documentation is worth reading.
For OSINT, WiGLE is a pivot point, not a verdict.
Search a distinctive SSID or a BSSID from your own collection. Ask questions such as:
Has this BSSID been observed near this area before?
Is the SSID concentrated around one plausible location or spread across many unrelated places?
Is there a clear change in observation history, or simply little historic coverage?
Does the time and place align with the physical context and other public sources?
Keep the limitations in the foreground:
WiGLE's displayed network position is a data-derived estimate from contributor observations. It can change as more observations are added and is not a ground-truth asset register.
A location can have no WiGLE history because nobody collected there or uploaded data.
An old observation may reflect moved equipment, changed tenants, replaced radios, GPS error or historical reality.
SSIDs are reused. BSSIDs can be virtualised or change with hardware and configuration.
A radio can be heard well beyond the building that hosts it.
The right sentence is:
“The WiGLE record supports this as a possible location and needs corroboration.”
The wrong sentence is:
“WiGLE proves the location.”
8. Corroborate with independent material
Wireless data becomes useful when it sits beside independent evidence.
For a geolocation lead, look at building layout, window position, signage, road markings, street furniture, nearby shops, language, power outlets, emergency signage, interior design, shadows, photos and video. For a company-location question, look at registration data, job advertisements, public procurement, event pages, supplier material, site photography and street-level imagery.
Try to disprove the hypothesis as actively as you try to support it. Is the SSID from a former tenant? A neighbour? A mobile hotspot? A default name? A vendor servicing more than one business in the building?
One wireless clue is a lead. A set of independent clues may become an assessment.
9. Report the meaning, not just the identifiers
Technical data without analysis makes a report look busy. It does not make it useful.
Do not write this:
SSID ABC-CORP-GUEST observed with BSSID xx:xx:xx:xx:xx:xx.
Write this instead:
During a scoped wireless observation from public space near the northern entrance, several WiFi networks using the organisation's apparent naming convention were observed. One was most consistently visible near the loading area. This may indicate operational or vendor infrastructure associated with the site; it does not establish ownership or occupancy. Internal asset records and further visual corroboration are required before drawing a conclusion.
That separates the observation from the assessment. It makes the limitation visible. It also gives the reader a next step.
Mask raw identifiers in a public report unless there is a clear reason to include them. Keep the unredacted data under the agreed case controls. The same applies even more strongly to BLE observations, where a raw identifier can carry a higher privacy risk than the intelligence value justifies.
What useful findings actually look like
The value is rarely “I saw 900 networks.” Counts are not intelligence. Comparison is.
Here are examples of findings that can be useful when handled carefully.
Worked example: from a photo to WiGLE to a field check
This is a good example of how WiGLE and a field collection can work together without pretending that either is magic.
Imagine that a photo or short video has already been geolocated through normal OSINT work. The visual evidence points to a specific street address: perhaps the investigator matched a distinctive façade, house number, road layout, business sign or window view.
At that point, WiGLE can add a historical layer.
The investigator reviews the wireless observations around the candidate location. They may find a distinctive SSID recorded alongside a BSSID, or a BSSID that has been repeatedly observed around that part of the street. The SSID might be a business name, a venue name or a personal-looking label. The BSSID is the more specific pivot; the SSID is the human-readable label associated with that observation.
That distinction is worth keeping straight. A BSSID does not itself disclose a family name. It is an identifier. A historical record associated with that BSSID may contain an SSID that is more telling.
Now the investigator has a hypothesis, not a conclusion:
A wireless observation associated with this distinctive name and BSSID has historically been seen near the location already suggested by the visual evidence.
If there is a legitimate case purpose, authority and a reason to visit, a carefully scoped field pass can test whether the same BSSID is still observable from a lawful position. A Biscuit Pro can make that collection practical: follow the predefined public route, collect only the agreed discovery data, preserve the original session export and compare it with the historical record afterwards.
There are three possible outcomes:
Result | Responsible reading |
The same BSSID is observed in the expected area. | This is additional support for the location hypothesis. It still does not prove that the photo was taken there or identify a resident. The radio may be heard from a neighbouring property. |
The SSID matches but the BSSID does not. | This is weaker. SSIDs are reused, hardware is replaced and multiple access points can share the same name. Record it as context, not confirmation. |
Neither is observed. | This does not disprove the location. The access point may be off, replaced, out of range, on a different band or missed by the collection conditions. The WiGLE observation may also be old. |
New BSSIDs observed during the field pass can be useful too. They may reveal a changed wireless environment, a new business tenant, a new vendor or simply the normal churn of consumer equipment. They should not become a shopping list for trying to identify people who live on a street.
The assessment must stay proportionate. If an SSID appears to contain a surname or another personal detail, treat it as sensitive data: do not put it in a public post, do not use it to profile residents and do not retain it longer than the case requires. The strength of this example is the chain of corroboration - visual clues, a historical wireless record and a current scoped observation - not the collection of personal information.
This is what the reporting language could look like:
Independent visual analysis identified Location A as the most likely origin of the media. A historical WiGLE observation showed a distinctive SSID and associated BSSID near that location. During a later, authorised perimeter collection from public space, the same BSSID was observed within the expected area. This supports, but does not prove, the location hypothesis. The finding is limited by the age and precision of historical observations, radio propagation and the possibility of nearby sources.
That is a useful finding. “The WiFi name proves who lives here” is not.
Worked example: does a hotspot appear to travel?
WiGLE can also be useful when a location search produces a distinctive BSSID that appears to belong to a hotspot or another mobile piece of equipment.
Imagine that an investigator starts with an authorised location question: a venue, a company facility, a vehicle operation or an event. A WiGLE search around that location returns a distinctive SSID and BSSID. The same BSSID appears in observations from two other cities at clearly separated dates. The SSID could be a company-branded hotspot name, a field-unit label or a less revealing but unusual string.
That can support a new hypothesis:
The same WiFi radio, or equipment using the same radio identity, may have been present in several locations over time.
It does not mean that an investigator has proven that a particular person travelled between those places. It may be a mobile hotspot. It may be a vehicle-mounted unit, a piece of deployed equipment or a corporate device that was moved. It may also be a bad data point, a changed configuration, a copied SSID, a mislocated observation or a misunderstanding of what the device actually is.
There is an important asymmetry here. An exact BSSID match across well-separated, plausible observations is useful support for a travel hypothesis. A different BSSID does not necessarily disprove it. Mobile hotspots can restart, be replaced or use MAC-randomisation behaviour that changes their advertised BSSID while retaining the same SSID. Treat the BSSID as a strong time-bound pivot, not a permanent device serial number.
Before reporting a movement hypothesis, slow down and test it:
Check | Why it matters |
Is the BSSID exactly the same, not merely the SSID? | An unusual SSID can still be reused by different devices. An exact BSSID match is a better pivot, though not an infallible identity. |
Are the observations separated in time and location in a plausible way? | A map point follows the collector. Nearby points, overlapping dates or impossible timing may reveal coverage, GPS or interpretation problems rather than travel. |
Does the signal behave like a mobile source? | A short appearance at multiple operational locations may fit a hotspot hypothesis better than years of observations around one building. It is still circumstantial. |
Is there independent context? | Public event schedules, company deployments, equipment photographs, known fleet activity or other authorised case material may corroborate a movement pattern. |
Could hardware or configuration explain it? | Radios can be replaced; hotspot settings can change; mobile hotspots may rotate their BSSID; and an SSID can be copied. Do not treat a BSSID as a device serial number. |
A scoped field collection can add a current point to the timeline. If a pass at an authorised site sees the same BSSID, record the time, place, collection conditions and confidence limits. If it is absent, record that too without treating absence as proof that the device left.
The right analytical language is careful:
Historical WiGLE observations associate BSSID XX:XX:XX:XX:XX:XX with several locations over a defined period. The distribution is consistent with a mobile hotspot or other transported radio asset. Available data does not establish the device owner, operator, purpose of travel or continuous movement between the observations. Independent corroboration is required.
This use case is about understanding the movement of an in-scope organisational asset or operational capability. It is not a method for monitoring private people. Do not turn scattered public observations into a private person's travel diary, and do not publish a sensitive movement map when a redacted analytical summary will answer the case question.
Worked example: a shared building needs a wireless fingerprint, not one name
Shared buildings create some of the easiest attribution mistakes. An office block may contain ten tenants, a café, building-management equipment and a guest network that reaches the pavement. A hotel may use one guest SSID across dozens of access points. A university campus may broadcast the same service-set name from many buildings.
That is normal network design. Multiple access points can broadcast the same SSID so that users experience one logical network across a site. A single SSID therefore has little value by itself.
The better question is whether there is a set of observations that forms a wireless fingerprint consistent with the candidate site.
Imagine an investigation into whether a company uses a particular floor in a shared office building. Instead of stopping at one company-looking SSID, the investigator records several related BSSIDs seen at defined points around the building. Historical WiGLE results show that the same small group has been associated with that building area over time. The group includes both 2.4 GHz and 5 GHz observations, and the organisation's public photographs show branded offices on the same side of the building where the collection was strongest.
That is still not automatic proof. A managed WiFi provider may operate the group for several tenants. The signals may come from another floor. But it is much better evidence than one SSID named Company-Guest.
The investigator should test alternatives:
Does the same BSSID group appear near more than one building in the district?
Do the company-looking SSIDs map to a known managed-service provider rather than the company itself?
Is there a café, coworking operator or hotel that explains the naming convention?
Do field notes, public photographs and building directories align with the observed side of the building?
Report it as a fingerprint, not a conclusion:
A group of related BSSIDs using the apparent organisational naming convention was repeatedly observed around the eastern façade. Historical WiGLE observations place the same group in the building area. Together with public images and the tenant directory, this is consistent with an operational presence at the site. The data cannot determine the relevant floor or exclude shared managed infrastructure.
Worked example: a rebrand, relocation or former tenant leaves a radio history
Wireless history can sometimes help build a cautious timeline for a business location.
Imagine a company that rebranded, moved offices or says it never occupied a particular address. Current maps and public records are inconclusive. WiGLE history around the site contains an older SSID that matches the company's former public name, then later observations show a different company-style naming pattern. A current, authorised field pass can show whether either pattern is still audible.
The OSINT question is not “when was this access point installed?” WiGLE cannot answer that reliably. The useful question is narrower:
Is there a historical wireless pattern that is consistent with the organisation's public footprint changing at this location?
Combine the radio timeline with archived websites, historical business registrations, cached job adverts, old employee posts, street imagery, lease announcements, company photographs and local news. If several independent sources indicate that the company used the address during the same broad period as the older wireless observations, you have a defensible historical association.
Be especially cautious with the language around time:
The earliest available WiGLE observation of the former-brand SSID near the site is from Month/Year, and the latest is from Month/Year. These dates describe database observations, not confirmed start and end dates of occupancy. When considered with archived company material from the same period, the pattern supports the hypothesis that the organisation used the location.
That sentence gives the reader evidence, confidence and limitation in one place.
Worked example: checking a claimed business address
An organisation says it works from a particular address. Public records and maps show a shared building with several tenants. A field collection from permitted public space finds three SSIDs using the organisation's apparent naming convention, plus a vendor-related SSID that is visible only near the service entrance.
The investigator checks WiGLE and finds that one BSSID associated with the naming convention has appeared near the same building over several years. On its own, that is still not proof of occupancy. The organisation could be a former tenant, the access point could be operated by a managed-service provider or the signal could be coming from next door.
The useful next moves are non-wireless: compare with business registration information, job advertisements, delivery access, supplier references, signs, unit numbers, company photographs and historical imagery. If those sources point to the same unit, the wireless data becomes a solid supporting layer.
The report should say “consistent with operational presence at the building” rather than “proves the organisation occupies the address.” That difference matters.
Worked example: an event that changes a place overnight
For an authorised event-security or situational-awareness assignment, take the same walk before build-out, during the event and after teardown. Keep the route, collection scope and notes consistent.
WiGLE may show what has historically been visible around the venue. The field data shows what is visible now. The comparison can highlight temporary broadcast names associated with production, ticketing, media, catering, AV or other contractors. Physical notes about trucks, badges, signage and temporary infrastructure are what make the radio observations meaningful.
The finding is not “we discovered the event WiFi.” It is the change: temporary operational infrastructure appeared in a defined period and disappeared afterwards. That can help a client understand exposure, operational tempo and naming leakage from its own event.
Location and occupancy leads
An organisation publicly denies operating from a particular site. A field pass reveals several SSIDs that follow its public naming convention and one vendor name associated with its services. That does not prove occupancy. It does justify checking corporate records, supplier material, employee posts, job adverts, delivery patterns and imagery.
The finding is the inconsistency worth investigating, not a claim that the radio evidence settled the issue.
Geolocation support
A WiFi network name appears in the background of a video. A WiGLE search shows historical observations around a candidate hotel, while the video independently matches the hotel's lobby design, nearby street furniture and a local event schedule.
The wireless clue supports the geolocation. It should never carry it alone.
Event build-up and operational change
Take the same permitted route before, during and after an event. A cluster of production-, media- or vendor-related SSIDs appears shortly before opening and disappears afterwards. Combined with physical event infrastructure and public event information, that can help understand operational build-up.
Again: names are leads. A temporary SSID could belong to a contractor, a vehicle or a neighbour. The value is the change pattern and the corroboration.
Defensive exposure review
An organisation asks what it leaks from the outside of its own premises. SSIDs may disclose department names, project names, office floors, a vendor product or legacy equipment. None of those names may be a vulnerability by itself. Together they make external reconnaissance easier.
That is a practical OPSEC finding. It can lead to a review of naming conventions, inventory hygiene and how retired equipment is decommissioned.
Anomaly triage in an authorised space
In a meeting room or vehicle that is within scope, a repeated BLE advertisement looks inconsistent with known equipment. The correct next step is not a dramatic conclusion. It is a documented, authorised physical inspection or a hand-off to someone who can properly identify the device.
BLE: useful, noisy and easy to get wrong
BLE needs more restraint than WiFi.
A Bluetooth name may be no name at all. A category may be inferred rather than verified. Addresses can rotate. A device seen in a room might be inside a bag, passing outside a window, on a floor above or attached to legitimate building equipment.
For an authorised anomaly sweep, I use a simple triage model:
Question | Why it matters |
Where was it observed? | Location context is more useful than a device name alone. |
When was it seen? | A single hit and a recurring signal deserve different confidence. |
Does it recur on a controlled re-check? | Repetition can justify further review; it still does not establish identity. |
Is there a normal explanation? | Sensors, wearables, building systems, visitor equipment and neighbouring devices are common. |
Is a physical inspection authorised? | If not, stop at the observation and document it. |
Never turn BLE collection into secret people tracking. Even if a device is technically observable, that does not make the collection proportionate, necessary or defensible.
Change detection is where this gets powerful
A single collection tells you what was visible at one moment, from one route, with one device.
Repeated collection gives you something much more useful: a baseline.
Use the same route, same collection scope and, where practical, similar time windows. Compare before/during/after an event. Compare a location month to month for your own organisation. Compare your current collection with historical WiGLE records while remembering the limitations of both.
Then you can say things that have analytical value:
This BSSID was visible on all three passes, near the same entrance.
This group of event-related SSIDs first appeared during build-out and was gone two days later.
This legacy-looking name remained visible after a site migration.
This BLE advertisement was repeatedly observed in a room where it should not have been, and a physical inspection is recommended.
This expected identifier was not observed under these specific collection conditions.
Notice the wording in the last example. Absence from a scan is not proof of absence. The access point could be off, out of range, on another band, shielded, hidden by the collection method or simply missed. Good reporting puts conditions around an absence finding.
Where this article stops
I want to be very clear about something: there are people in the WiFi, Bluetooth, radio-frequency and embedded-device worlds who are far more capable than I am.
They understand antenna design, RF propagation, spectrum analysis, 802.11 management frames, BLE protocol behaviour, firmware, packet analysis, direction finding, rogue-access-point detection, protocol reverse engineering and properly authorised adversary emulation at a level most OSINT practitioners will never need.
That work is real. It is valuable. It can be essential in a red-team engagement, incident response, wireless assessment, threat-hunting operation or lab research project. It is also usually outside the realm of OSINT and often outside the legal scope of a normal investigation.
This article does not try to turn someone into a wireless penetration tester. It should not.
An OSINT investigator's strength is knowing what a radio observation can contribute, where it is weak, when to hand it to a specialist and when to stop. The fact that a tool has an advanced feature does not mean the feature belongs in your case plan.
If your question becomes any of the following, bring in the right people and get the right written authority:
Is this access point securely configured?
Who is connected to it?
Is it possible to gain access?
Is this radio deliberately spoofed?
Can we identify or locate the transmitter precisely?
Can we inspect packet contents or emulate an attacker?
Those are not “just a bit more OSINT.” They are different kinds of work.
A compact field checklist
Before the visit:
Define the intelligence question and what would count as useful evidence.
Confirm authority, location boundaries, collection modes, data handling and retention.
Research the physical environment and plan the route.
Test the device, app, GPS, timestamps, collection mode and export in an authorised environment.
Decide whether an upload to WiGLE or another platform is authorised. Default to local storage until you make that decision deliberately.
During the visit:
Stay within the authorised area and timeframe.
Keep the route and pace consistent.
Record physical context alongside the radio observations.
Collect the minimum necessary data.
Do not connect, attack, interfere with or track.
After the visit:
Preserve the original export and write the collection log.
Analyse against the intelligence question, not against your curiosity.
Treat SSIDs, BSSIDs, BLE labels and WiGLE records as leads.
Corroborate with independent sources and actively test alternatives.
Report observations, assessment, limitations and next steps separately.
Redact identifiers and retain raw data according to the agreed plan.
Closing thought
Wardriving is often misunderstood because people only see the hacking angle.
For OSINT, the interesting part is not access. It is awareness.
WiFi and BLE observations can help us understand physical places. They can support geolocation, show operational change, expose careless naming, identify anomalies in authorised spaces and create better questions for the rest of an investigation.
WiGLE can provide a public historical layer. A field device such as Biscuit Pro can provide a current collection layer. The phone app can make that collection practical.
None of those tools do the analysis for you.
The device sees a signal. WiGLE gives you another observation. The investigator has to decide what it means, what it does not mean and whether the collection was worth doing in the first place.
Comments