WirelessSecurity

Wireless is the one part of a network's perimeter that physical walls don't stop. A firewall can block every port from the internet, but it can't stop someone in the parking lot from associating to a weak access point and landing directly on the internal VLAN — no phishing email, no exposed service, just radio waves crossing a wall. That's why wireless assessments are a standing line item in most penetration testing methodologies (PTES, OSSTMM) and why "guest Wi-Fi bridged to the corporate LAN" remains one of the most common findings in real engagements.

1. Survey your own environment

   Using your phone's Wi-Fi settings, list every network your devices have ever auto-connected to. That list is your personal Evil Twin attack surface.

2. Check WPS status

   Log into your home router's admin page and check whether WPS is enabled. Note it — you'll test it directly in Module 2.

3. Read one real-world case

   Search for a public writeup of a wireless-based breach or pentest finding (e.g. a conference talk or blog post) and note which specific weakness was exploited.

A wireless pentest can violate the second layer even when it's fully authorized under the first — an authorized client can give you permission to access their network, but no client can give you legal permission to violate spectrum regulations. This is why passive, receive-only actions (monitoring, capturing) are lower-risk than anything that transmits (deauth frames, rogue APs, jamming).

1. Get the SSIDs and BSSIDs in writing

   A wireless scope should list exact network names and, ideally, MAC address ranges of authorized APs — not just "our office Wi-Fi."

2. Confirm physical boundaries

   Radio doesn't stop at a lease line. Agree on which floors/buildings are in scope and what to do if your signal reaches a neighboring tenant.

3. Get explicit sign-off on deauth and jamming

   These affect every device in range, including personal phones of employees and neighbors — treat them as a distinct, higher-risk line item requiring separate approval.

4. Agree on a kill switch and testing window

   Wireless disruption is immediately visible to end users; agree on a time window and a way to reach you if something needs to stop mid-test.

1. Pass the adapter through to the VM

   Plug it into the host machine, then VM → Removable Devices → [adapter name] → Connect (Disconnect from Host) in VMware.

2. Confirm Kali sees it

   Run iwconfig or ip a — you should see an interface like wlan1 alongside your VM's normal eth0.

3. Kill interfering processes

   NetworkManager and wpa_supplicant fight with monitor mode. Run airmon-ng check kill before every lab session.

4. Enable monitor mode

   This creates a monitor-mode interface (often renamed wlan1mon) that can see raw 802.11 frames instead of only fully-connected traffic.

5. Set up your own dedicated practice AP

   Use a spare router (or your main one, temporarily, in a room where the signal doesn't reach neighbors) with a throwaway SSID like WIRELESS-LAB and a passphrase you choose deliberately weak for cracking practice.

6. Verify injection works

   Aircrack-ng's injection test confirms your adapter/driver combo can actually transmit crafted frames, not just receive.

# stop services that interfere with monitor mode
sudo airmon-ng check kill

# enable monitor mode on your physical adapter
sudo airmon-ng start wlan1

# confirm the interface is up in monitor mode
iwconfig

# test packet injection against your own AP's channel
sudo aireplay-ng --test wlan1mon

1. Check your adapter's supported channels

   Run iwlist wlan1 channel to see which bands and channels your hardware supports.

2. Identify your practice AP's band

   Check your WIRELESS-LAB router's admin page and note whether it's broadcasting on 2.4GHz, 5GHz, or both.

1. Start monitor mode

   If it isn't already running from Lab 0.3: sudo airmon-ng start wlan1.

2. Capture to a file

   Use airodump-ng with the -w flag to write a .cap file while it scans, targeting your practice AP's channel with -c.

3. Open the capture in Wireshark

   Load the resulting .cap file and apply the filter wlan.fc.type_subtype == 0x08 to isolate beacon frames.

4. Inspect a beacon frame

   Expand the IEEE 802.11 wireless LAN tree — find the SSID, supported rates, and RSN (security) information element showing WPA2/WPA3 capability.

5. Filter for probe requests

   Apply wlan.fc.type_subtype == 0x04 and look for the SSIDs nearby phones are asking for by name — this is how devices leak their saved network history.

# capture on your practice AP's channel only
sudo airodump-ng --channel 6 --write lab1_capture --output-format pcap wlan1mon

1. Run a full-spectrum scan

   sudo airodump-ng wlan1mon with no channel lock hops across all channels, listing every AP it hears.

2. Read the AP table

   Note BSSID, power (signal strength), channel, encryption (WEP/WPA/WPA2/WPA3), and cipher for each network — focus only on your own WIRELESS-LAB entry.

3. Read the client table below it

   Shows which client MAC addresses are associated to which BSSID — this is how you'll target a specific device in later labs.

4. Lock onto your AP's channel

   Re-run with --bssid and --channel set to your practice AP for a focused, lower-noise capture.

5. Cross-check with Kismet

   Launch Kismet for a GUI view with signal graphing and automatic device fingerprinting — useful for longer recon sessions.

# broad scan across all channels
sudo airodump-ng wlan1mon

# focused scan + capture on your practice AP only
sudo airodump-ng --bssid AA:BB:CC:DD:EE:FF --channel 6 \
  --write lab1_focused wlan1mon

A "hidden" network simply stops including its SSID in beacon frames — it still broadcasts constantly, and the SSID reappears in plaintext the moment a legitimate client probes for it or associates. Any passive listener who waits for a client to connect (or forces a reconnect with a deauth frame, covered in Module 2) sees the SSID immediately. It is a cosmetic setting, not a security control.

1. Enable SSID hiding

   On your WIRELESS-LAB router's admin page, turn off SSID broadcast and confirm it disappears from a normal scan.

2. Capture while a client connects

   Run airodump-ng locked to the AP's channel and reconnect a test device — watch the SSID appear as soon as the probe/association exchange happens.

3. Identify device vendors from MAC addresses

   The first three octets of a MAC address (the OUI) identify the manufacturer — use macchanger -l or an online OUI lookup against captured client MACs.

# look up a vendor by OUI prefix
macchanger -l | grep -i "AA:BB:CC"

WEP encrypts each packet with RC4 keyed by a static passphrase plus a 24-bit Initialization Vector (IV) that's sent in the clear. With only 16 million possible IVs, a busy network reuses them constantly, and statistical analysis of enough reused-IV packets recovers the key directly — no password guessing required, just enough captured traffic.

1. Switch your practice AP to WEP

   Most routers still offer WEP under legacy options — set a short passphrase for this lab only, then revert to WPA2 immediately after.

2. Capture traffic

   airodump-ng locked to the AP's BSSID and channel, writing to a file.

3. Generate traffic to speed up IV collection

   Use aireplay-ng's ARP replay attack to force the AP to rapidly generate new IVs.

4. Crack once you have ~20-40k IVs

   Run aircrack-ng against the capture file — it recovers the key directly from statistical analysis.

# capture toward a file
sudo airodump-ng --bssid AA:BB:CC:DD:EE:FF -c 6 -w wep_lab wlan1mon

# replay captured ARP packets to generate new IVs quickly
sudo aireplay-ng --arpreplay -b AA:BB:CC:DD:EE:FF wlan1mon

# crack once enough IVs are captured
aircrack-ng wep_lab-01.cap

WPA2-PSK derives a session key from the passphrase and a series of nonces exchanged during association — the "4-way handshake." That exchange is visible on the air even though the passphrase itself never crosses the network. Capturing it gives you exactly enough material to test password guesses offline, without ever touching the live AP again.

1. Revert your practice AP to WPA2-PSK

   Set a deliberately guessable passphrase for this exercise (something in the top 100k rockyou.txt list).

2. Start a focused capture

   airodump-ng locked to the AP's BSSID and channel, writing to a file.

3. Force a reconnect with a deauth frame

   Send a handful of deauthentication frames to a connected client — its device will automatically reassociate, generating a fresh handshake.

4. Confirm the handshake was captured

   airodump-ng shows WPA handshake: AA:BB:CC:DD:EE:FF in its top-right corner once captured.

# start capture locked to your AP
sudo airodump-ng --bssid AA:BB:CC:DD:EE:FF -c 6 -w handshake_lab wlan1mon

# deauth a specific client to force a reconnect (run in a second terminal)
sudo aireplay-ng --deauth 5 -a AA:BB:CC:DD:EE:FF -c 11:22:33:44:55:66 wlan1mon

1. Get a wordlist

   Kali ships rockyou.txt at /usr/share/wordlists/rockyou.txt.gz — unzip it once.

2. Run the dictionary attack

   aircrack-ng tries each candidate passphrase against the captured handshake until one produces a matching MIC.

# one-time unzip
gunzip /usr/share/wordlists/rockyou.txt.gz

# dictionary attack against the captured handshake
aircrack-ng -w /usr/share/wordlists/rockyou.txt \
  -b AA:BB:CC:DD:EE:FF handshake_lab-01.cap

1. Convert the capture

   Use hcxpcapngtool to convert the .cap into hashcat's .hc22000 format.

2. Run mode 22000

   Hashcat's WPA-PBKDF2-PMKID+EAPOL mode, pointed at the same wordlist, is dramatically faster than aircrack-ng's CPU-only implementation on any decent GPU.

# convert capture to hashcat format
hcxpcapngtool -o handshake.hc22000 handshake_lab-01.cap

# crack with hashcat mode 22000
hashcat -m 22000 handshake.hc22000 /usr/share/wordlists/rockyou.txt

1. Run a targeted deauth

   Reuse the command from Lab 2.2 against one client and time how quickly it reconnects.

2. Run a broadcast deauth (own AP, brief window only)

   Omit the -c flag to send to the broadcast address, disconnecting every client — run this for a few seconds only, on your own AP, with no other devices in range.

3. Observe WPA3's partial mitigation

   If your AP supports WPA3 or 802.11w (Management Frame Protection), repeat the test — deauth frames should be rejected as unauthenticated once PMF is enforced.

# broadcast deauth — every client on this BSSID (OWN AP ONLY, brief test)
sudo aireplay-ng --deauth 10 -a AA:BB:CC:DD:EE:FF wlan1mon

Many access points include a Robust Security Network (RSN) field called the PMKID in their very first EAPOL message to speed up roaming between APs on the same network. That field is derived from the same pairwise master key a full handshake would reveal — meaning it can be requested directly from the AP itself, with no client and no deauth involved at all.

1. Capture the PMKID

   hcxdumptool actively requests it from your practice AP directly.

2. Convert to hashcat format

   Same hcxpcapngtool conversion as Lab 2.3.

3. Crack with hashcat mode 22000

   Identical cracking command to the full-handshake attack — hashcat's mode 22000 handles both PMKID and EAPOL material.

# capture PMKID directly from the AP, no client needed
sudo hcxdumptool -i wlan1mon -o pmkid_lab.pcapng --enable_status=1

# convert and crack exactly as in Lab 2.3
hcxpcapngtool -o pmkid_lab.hc22000 pmkid_lab.pcapng
hashcat -m 22000 pmkid_lab.hc22000 /usr/share/wordlists/rockyou.txt

WPS's PIN is checked in two independent halves (4 digits, then 3 digits plus a checksum), and the AP tells you separately whether each half was correct. That reduces an 8-digit search space that should take centuries down to at most 11,000 guesses — completely bypassing passphrase strength, since a successful PIN guess reveals the actual WPA2 passphrase directly.

1. Enable WPS on your practice AP

   Confirm it's on in the router admin page — many ship with it enabled by default.

2. Scan for WPS-enabled APs

   wash (from the Reaver suite) lists nearby APs with WPS active.

3. Run Reaver against your AP

   It systematically brute-forces the PIN halves and, on success, returns the WPA2 passphrase.

4. Try Bully as an alternative

   A more actively maintained reimplementation of the same attack, often faster against modern firmware rate-limiting.

# scan for WPS-enabled networks
sudo wash -i wlan1mon

# brute-force the WPS PIN with Reaver
sudo reaver -i wlan1mon -b AA:BB:CC:DD:EE:FF -vv

# alternative: Bully
sudo bully wlan1mon -b AA:BB:CC:DD:EE:FF -v 3

802.11 has no built-in way for a client to verify an AP's identity beyond its SSID and, in some cases, its MAC address — both of which are trivial to clone. Most devices are configured to auto-join any AP broadcasting a remembered SSID, with the strongest signal usually winning if two APs share a name. An Evil Twin exploits exactly that: broadcast the same name, sit closer or louder than the real AP, and devices reconnect to you without any prompt.

1. Configure hostapd

   Set the SSID to match your WIRELESS-LAB network exactly, using a second wireless interface or adapter.

2. Configure dnsmasq for DHCP

   Your fake AP needs to hand out IP addresses just like the real one, or connected clients won't get network access and will quickly disconnect.

3. Start both services

   Bring up the fake AP and confirm it appears in a scan alongside (or briefly deauth the real AP to eclipse) your legitimate network.

4. Connect a test device

   Use a spare phone or laptop you own to confirm it associates to the fake AP without any warning.

# minimal hostapd.conf
interface=wlan1
driver=nl80211
ssid=WIRELESS-LAB
hw_mode=g
channel=6

# launch the fake AP
sudo hostapd hostapd.conf

# hand out DHCP leases on the fake AP's subnet
sudo dnsmasq -C dnsmasq.conf -d

1. Serve a fake captive portal

   Point dnsmasq's DNS at your own IP for every domain, then serve a simple HTML login page that mimics a router or ISP login screen.

2. Redirect all HTTP traffic to it

   Any unencrypted request from a connected client gets redirected to your portal page before reaching its real destination.

3. Log submitted credentials to a file

   A minimal backend script writes whatever's typed into the form — confirm this works with your own test credentials only.

4. Observe HTTPS's protection

   Sites using HTTPS with HSTS will show certificate warnings instead of silently working — note which of your test devices' apps still leak data anyway (some apps ignore cert warnings for background traffic).

From Lab 1.2, you saw devices broadcast probe requests for every network they've previously joined. A Karma-style tool listens for those requests and responds to each one as if it were that exact network — a phone that's ever joined "Starbucks WiFi," "Airport_Free_WiFi," or a hotel network anywhere will connect to your fake AP the moment it hears its own probe answered.

1. Put a test device in a known state

   Have a spare phone previously join a network with a distinctive name you'll recognize in probe requests.

2. Run bettercap's Wi-Fi module

   Enable its probe-response / Karma-style functionality to answer any observed probe request from your test device.

3. Watch the test device auto-connect

   It should associate without any user interaction, believing it rejoined a network it already trusted.

# bettercap interactive shell
sudo bettercap -iface wlan1mon

# inside bettercap: enable Wi-Fi recon and probe monitoring
wifi.recon on
wifi.show

1. Spoof your adapter's MAC to match the real AP's

   Some MAC-filtering setups only check the MAC address, not any cryptographic identity — cloning it defeats that check entirely.

2. Route connected clients' traffic through your machine

   With your Evil Twin from Lab 3.1 acting as the gateway, all traffic from connected test devices naturally flows through your box.

3. Inspect traffic with bettercap or Wireshark

   Confirm plaintext HTTP is fully readable, while HTTPS traffic is opaque without a successful certificate-trust attack.

4. Document what MITM does and doesn't grant

   Note exactly which apps/sites leaked data and which didn't — this becomes your Module 7 report's evidence.

# spoof MAC address on the attacking interface
sudo macchanger -m AA:BB:CC:DD:EE:FF wlan1

# in bettercap: sniff traffic flowing through the fake AP
net.sniff on

1. Install and configure hostapd-wpe

   It ships a modified hostapd plus a self-signed certificate, purpose-built to impersonate an 802.1X authenticator and log credentials.

2. Broadcast the enterprise SSID

   Clone your own test enterprise network's SSID (set one up on your practice AP if it supports WPA2-Enterprise, or a software AP for this lab).

3. Connect a misconfigured test client

   On a spare test device, deliberately disable "validate server certificate" in its Wi-Fi settings to simulate a common real-world misconfiguration.

4. Capture the MSCHAPv2 handshake

   hostapd-wpe logs the challenge/response, which can then be cracked offline with tools like asleap if the password is weak.

# run hostapd-wpe with its bundled config
sudo hostapd-wpe /etc/hostapd-wpe/hostapd-wpe.conf

# captured challenge/response gets logged automatically to
# hostapd-wpe.log — crack offline with asleap against a wordlist
asleap -C <challenge> -R <response> -W /usr/share/wordlists/rockyou.txt

The "Dragonblood" research disclosed side-channel and downgrade weaknesses in early SAE implementations — timing/cache side channels that could leak partial information, and downgrade attacks against WPA3/WPA2 "transition mode" networks that let an attacker force a WPA2-style connection instead. This is a case study in why cryptographic protocol upgrades still need scrutiny of their actual implementation, not just their design.

1. Check transition mode on your practice AP

   If it supports WPA3, check whether "WPA2/WPA3 transition mode" is enabled — note that this mode exists specifically for backward compatibility and reintroduces WPA2's attack surface.

2. Read the original Dragonblood disclosure

   Search for the researchers' own summary and note the two or three specific CVEs assigned — this is good practice for reading vulnerability research generally.

1. Scan for Classic devices

   hcitool scan lists nearby discoverable Bluetooth Classic devices with their MAC addresses.

2. Scan for BLE devices

   bluetoothctl's scan on mode picks up BLE advertisements from wearables and IoT sensors nearby (use your own devices — a fitness tracker or smart bulb works well).

3. Enumerate services on your own device

   gatttool or bluetoothctl's info command lists the GATT services/characteristics your own BLE device exposes.

# classic Bluetooth device discovery
sudo hcitool scan

# BLE scanning via bluetoothctl
bluetoothctl
scan on

1. Capture your own device's pairing exchange

   Use Wireshark with a BLE-capable adapter (or a dedicated tool like Ubertooth/btlejack if available) while re-pairing a "Just Works" IoT device you own.

2. Identify the pairing mode used

   Inspect the captured pairing request/response frames to confirm which of the three modes above was negotiated.

3. Note what's exposed on a Just Works device

   Document which characteristics (readable values, commands) are accessible without any authentication at all.

1. Identify what you already own

   Check your home for Zigbee/Z-Wave hubs (many smart speakers and hubs include a radio) and note the protocol on the box or spec sheet.

2. Check your access badge type

   If you have a building access card, look up its printed model number to identify whether it's a legacy unencrypted proximity card or a modern encrypted one.

1. Apply every control to your practice AP

   Go through the checklist above one row at a time on your router's admin page.

2. Re-run Lab 2.6's WPS scan

   Confirm wash no longer lists your AP as WPS-enabled.

3. Re-run Lab 2.4's deauth test

   With 802.11w enabled, confirm the deauth frames are now rejected instead of disconnecting the client.

1. Run Kismet as a passive monitor

   Leave it running while you (or a lab partner) re-run Lab 2.4's deauth attack in a second session.

2. Watch the alert feed

   Confirm the deauth flood triggers a visible alert in Kismet's UI in near real time.

3. Repeat with your Evil Twin from Lab 3.1

   Bring up the cloned SSID and confirm Kismet flags the duplicate/spoofed AP.

1. Draft a segmentation diagram

   Sketch how guest, corporate, and IoT wireless traffic should be separated on a VLAN diagram for a small office.

1. Confirm it's not authorized testing

   Check whether a scheduled pentest or internal red-team exercise explains the alert before treating it as a real incident.

2. Locate the rogue device physically

   Use signal strength (PWR from Lab 1.3) across multiple locations to triangulate roughly where the transmitting device is.

3. Isolate affected wireless segments

   If containment is available on your WIPS, use it; otherwise consider temporarily disabling the affected SSID.

4. Force a credential reset if a rogue AP was live

   Any device that may have connected to an Evil Twin should have its credentials rotated, since you can't confirm what was captured.

5. Document the timeline

   First alert time, containment time, affected devices — this feeds directly into Module 7's reporting skills.

1. Write up your Module 2.3 finding

   Full structure above, using your actual lab commands and screenshots.

2. Write up your Module 3 capstone finding

   Same structure, covering the Evil Twin and captive-portal chain end to end.

1. Write your own rules of engagement

   Even against your own gear — practice the discipline from Module 0.2.

2. Run full passive recon

   Module 1's techniques, documenting every AP and client you observe.

3. Attempt every applicable Module 2 attack

   WPS, handshake capture and crack, PMKID — document which succeeded and why.

4. Run the Module 3 Evil Twin chain

   End to end, including the captive portal.

5. Apply Module 6's hardening

   Then re-run every attack that previously succeeded, confirming it now fails.

6. Write the final report

   Every finding, Lab 7.2's structure, plus a short executive summary in plain language for a non-technical reader.

1. Decide your actual goal first

   Offensive specialist, defensive/network engineer, or a broad pentest generalist role.

2. Match the certification to three real job listings

   Check what's actually asked for before committing time and money to one.

1. Write up your Module 7 capstone as a portfolio piece

   Sanitized of any real network details, this becomes a writing sample showing methodology, not just tool usage.

2. Build a home lab you keep long-term

   Keep your practice AP and adapter set up — new attack research (post-quantum SAE variants, new WPA3 CVEs) is easiest to test hands-on if the lab already exists.

3. Follow wireless-specific research

   Conference talks from DEF CON's Wireless Village and Wi-Fi/Bluetooth CVE disclosures are the fastest way to stay current after finishing a static workbook like this one.

4. Set a quarterly practice cadence

   Re-run one lab from this workbook against updated firmware or a new adapter every few months — tooling and defenses both evolve.

Everything in Modules 1–5 targeted protocols your Wi-Fi/Bluetooth chipset already knows how to demodulate. Garage door remotes, tire-pressure sensors, wireless doorbells, key fobs, and most proprietary 900MHz/433MHz IoT devices use none of those protocols — a fixed-purpose Wi-Fi adapter simply can't see them. An SDR replaces purpose-built radio hardware with a general-purpose receiver plus software, letting you tune to any frequency and decode whatever's there yourself.

1. Pass the RTL-SDR dongle through to the VM

   Same VMware process as Lab 0.3's Wi-Fi adapter.

2. Open gqrx and tune to an FM radio station

   A known, legal signal (any local FM broadcast, ~88–108MHz) is the easiest way to confirm the SDR and software chain works end to end.

3. Read the waterfall display

   The vertical axis is time, horizontal is frequency, and color is signal strength — learn to spot a burst transmission (like a key fob press) as a short vertical streak.

4. Scan the 433MHz ISM band

   Tune to 433.92MHz and press any 433MHz remote you own (garage remote, wireless doorbell, weather station sensor) — watch the burst appear on the waterfall.

# launch gqrx (GUI) against the RTL-SDR
gqrx

# or a quick CLI spectrum scan
rtl_power -f 433.5M:434.5M:1k -g 40 -i 10 scan.csv

1. Identify a fixed-code device you own

   Cheap older garage remotes and generic wireless doorbells are commonly fixed-code — check the manual/model number if unsure.

2. Capture the transmission

   Use rtl_433 to decode and log the signal while pressing the remote.

3. Replay it with a transmit-capable SDR

   If you have a HackRF, replay the captured IQ file and confirm the receiving device (your own garage door/doorbell) triggers identically.

# decode common 433MHz fixed-code protocols automatically
rtl_433 -f 433.92M

1. Read the WiFi Pineapple's documentation

   Map its built-in modules back to the specific labs in Module 3 they automate.

2. Read the Flipper Zero's feature list

   Map its Sub-GHz and RFID features back to Modules 5 and 9's concepts.

Jamming floods a frequency band with noise or a strong competing signal so legitimate devices can't distinguish real transmissions from interference — effectively a physical-layer denial-of-service. Unlike a deauth frame (Lab 2.4), which exploits a protocol weakness, jamming needs no protocol knowledge at all; raw power on the right frequency is enough.

1. Recognize the signature in a spectrum scan

   Using Lab 9.1's gqrx or Kismet's spectrum view, a jammed band shows sustained high noise floor across the whole channel, not the intermittent bursts of normal traffic.

2. Correlate with a sudden client drop-off

   Unlike a targeted deauth, jamming disconnects every client on the band simultaneously with no deauth frames logged at all — that absence is itself the signature.

1. Attach a GPS dongle (or use a phone's GPS via Kismet's remote capture)

   Kismet natively logs GPS coordinates alongside every AP and client it observes.

2. Walk (or drive, in an authorized area) your own property's perimeter

   Log continuously while covering the full area you want to map.

3. Export and visualize on a map

   Kismet can export to formats viewable in mapping tools, showing exactly where your signal is strong, weak, or leaking beyond your intended boundary.

4. Use signal strength to physically locate a rogue AP

   Revisit Lab 6.4's incident-response scenario — take PWR readings from three different points and triangulate roughly where a rogue transmitter sits.

An IMSI catcher (sometimes called a "Stingray," after one commercial product) impersonates a legitimate cell tower, exploiting the fact that older cellular protocols (2G in particular) don't require the network to authenticate itself to the phone — the same fundamental "no mutual authentication" weakness behind this workbook's Evil Twin attacks in Module 3, just at the cellular layer instead of Wi-Fi.

1. Read, don't build

   Study public research and conference talks on IMSI catcher detection apps (which look for the same "no mutual auth" red flags you learned to spot in Module 3).

2. Know when to hand off

   If a real engagement's scope ever includes cellular, that's a specialist sub-engagement requiring specific legal authorization beyond a standard wireless pentest — recognize the boundary rather than trying to cover it yourself.