Spooky Wifi

    When casually doing what I like to do and scanning the open air for fun and profit, I found something rather peculiar. 

    In today's world an unencrypted wireless network is pretty rare as it allows risks of spoofing, mitm, and various exploitation techniques which may be hard to defend against in courts. Many businesses offering wifi to it's customers stopped doing so because they couldn't maintain appropriate logging to prove when someone did something they shouldn't or which user it was. Captive portals weren't very affective and that was before iam services like keycloak were popular. So to see one in 2026 seemed a little bit wild.

    When anything is "open" the data is shared unencrypted over the air. This can be sniffed and accessed by anyone passing by, and in the right, or I guess wrong, scenarios it can actually be mitm or spoofed without actually associating to the wifi network. This was the premise that created wep, then wpa, and now we're on wpa 3 standard. So you could imagine this as opening everyone on their network to 1995 wireless internet in 2026. Wild. But wait, it's gets better. Capturing this one network just so happens to show a LOT of traffic from one particular client (check the frames and lost frames section). For anyone who cares this is on wifi channel 52 which is basically just a fancy way of saying 5260 MHz.

    Now mind you, where I am, this is a much less populated frequency than in many other areas. Channel 52 is also part of a group of wifi ranges considered unii2a, which makes this particularly interesting. 

    Not knowing what it was, I started researching what ubiquiti devices use channel 52 and apparently a lot of them do including by not limited to some point to point wifi devices. Not accomplishing much in this search, I went ahead and looked at the packets captured. Using tshark filtering on fields eth.src, ip.src, udp.srcport, etc... I was able to build a list of interesting communications over port 10002.

    Trying to decode some of this I made a quick scapy parser using copilot:

#!/usr/bin/env python3

from scapy.all import *

from collections import defaultdict

import argparse

import datetime

import re

UBNT_PORT = 10002

def extract_ascii(raw):

    return ''.join(chr(b) if 32 <= b < 127 else ' ' for b in raw)

def split_fields(ascii_data):

    parts = re.split(r'[\x00\s]+', ascii_data)

    return [p for p in parts if len(p) > 1]

def analyze_pcap(pcap_file):

    pkts = rdpcap(pcap_file)

    devices = defaultdict(lambda: {

        "fields": set(),

        "timestamps": []

    })

    for pkt in pkts:

        if not pkt.haslayer(IP) or not pkt.haslayer(UDP):

            continue

        ip = pkt[IP]

        udp = pkt[UDP]

        if udp.sport != UBNT_PORT and udp.dport != UBNT_PORT:

            continue

        try:

            payload = bytes(udp.payload)

            ts = datetime.datetime.fromtimestamp(float(pkt.time))

        except Exception:

            continue

        ascii_data = extract_ascii(payload)

        fields = split_fields(ascii_data)

        if not fields:

            continue

        devices[ip.src]["fields"].update(fields)

        devices[ip.src]["timestamps"].append(ts)

    return devices

def print_results(devices):

    print("\n=== DEVICE INVENTORY ===\n")

    for ip, info in devices.items():

        print(f"Device: {ip}")

        for f in sorted(info["fields"]):

            print(f"   {f}")

        print(f"  Broadcasts: {len(info['timestamps'])}")

        print()

    print("\n=== BROADCAST TIMELINES ===\n")

    for ip, info in devices.items():

        print(f"{ip}:")

        for ts in info["timestamps"][:10]:

            print(f"   {ts}")

        if len(info["timestamps"]) > 10:

            print(f"   ... ({len(info['timestamps'])} total)")

        print()

if __name__ == "__main__":

    parser = argparse.ArgumentParser(description="Analyze Ubiquiti UDP/10002 discovery packets (Ethernet or 802.11)")

    parser.add_argument("pcap", help="Path to pcap file")

    args = parser.parse_args()

    devices = analyze_pcap(args.pcap)

    print_results(devices)

    This allowed me to see that in fact this includes businesses, personal names, etc.. in these broadcasts over an unencrypted publicly hear-able network.

    If you'll note, this also shows the PBE-5ac-gen2 and other sorts of powerbeam device names. These devices are available on the ubiquiti store as you might exepect, as point to point devices (https://store.ui.com/us/en/products/powerbeam-5ac). Meaning these are devices in the network meant to form directional antenna for network sharing. Turning this into an almost certainly ISP level routers that were connecting. There was of course other data, like people connecting to roku, and router specific protocols like ospf being broadcast as well. Which further pointed towards how these devices were relevant. (as a higher-than-consumer level network infrastructure. Meaning this was almost definitely an ISP of some kind). 

    In my initial scan, I only got private, autoconfigure, or carrier grade nat IP addresses so I tried to reach out to the fire department and the local facebook groups for help identifying this.

    Buuuuuuut after asking someone brought up that a local ISP had some of these ubiquiti devices up recently that may be the cause of this. Around the same time I'd just found where I accidently filtered on the most important part... arp requests.

Reaching out to the provider

    As many of the technical folks who read this will immediately see this and think wait what, for anyone else that's some public ip addresses (starting in 52. and 107.) being broadcast on this network. I used this as evidence to both email and call the provider. They said they'd create a trouble ticket internally and get it resolved. The customer support tech was very friendly and was willing to make things happen which is nearly unheard of in the ISP world. So props to them for that. 

As of the next day, it was fixed and back up and running as wpa2.

    While I've asked for information about what happened, as of this writing I  have not received word back about what happened or a technical description of the problems.

Educated guesses?

    If  I was to make an assumption, it would make me think someone setup these networks to replace broken equipment. Sometimes, when pushing down configurations to devices parts or all of the configuration gets lost in transit. A big reason why I like to push configs then validate configs before moving on. I've just seen it too many times to count and it often stays unrecognized for a long time before someone comes around and fixes it.

Thanks for reading

If you need any IT or CyberSecurity work remotely or within the DFW area, please contact us over at FeemcoTechnologies.