Ricognizione ed Enumerazione degli Obiettivi
Rilevamento Passivo vs. Attivo
La prima decisione nella ricognizione wireless è se ascoltare silenziosamente o sondare l'ambiente. Il rilevamento passivo pone l'adattatore in modalità monitor e registra ogni frame 802.11 su un canale sintonizzato. Questo non lascia alcuna impronta radio—nessuna richiesta di associazione, nessuna richiesta di probe con il tuo indirizzo MAC, nessun pattern di burst rivelatore che un WIDS potrebbe segnalare. Il compromesso è il tempo: catturi solo ciò che l'infrastruttura e i client trasmettono organicamente. Su canali silenziosi, potresti aspettare minuti per un burst di beacon o un probe client.
Il rilevamento attivo invia richieste di probe dirette o broadcast, attivando risposte AP e accelerando la risoluzione SSID. Dipinge anche un bersaglio sulla tua radio. Le firme WIDS enterprise segnalano routinariamente flood di probe con cambio rapido di canale, e alcune contromisure (gestione risorse radio basata su AP, selezione dinamica canale) altereranno l'ambiente target in risposta. Per valutazione difensiva autorizzata, il rilevamento attivo appartiene a finestre di laboratorio controllate; per enumerazione baseline di produzione, la raccolta passiva su finestre estese produce dati più puliti.
Cosa fa: Cattura tutto il traffico 802.11 su un canale specificato senza unirsi a nessun BSS. Quando usarlo: Mappatura topologia baseline, valutazione stealth, o quando hai bisogno di sequenze di frame per il troubleshooting dei fallimenti di associazione. Rischi: Il cambio di canale senza disciplina frammenta la cattura; i client potrebbero essere su un canale che manchi per minuti. Output atteso: Frame 802.11 raw con header radiotap inclusi metadati di potenza segnale, canale e data rate.
# Lab: Imposta interfaccia in modalità monitor, fissa canale per evitare gap di hopping
sudo ip link set wlan0 down
sudo iw wlan0 set monitor none
sudo ip link set wlan0 up
sudo iw wlan0 set channel 36 HT20
# Verifica modalità e canale
iw dev wlan0 info
Variante produzione: Usa finestre di cattura più brevi (5–10 minuti per canale) con rotazione di canale scriptata piuttosto che hopping manuale continuo. Registra i tempi di permanenza sul canale per correlare con traffico mancato successivamente.
Tipi di Frame 802.11: Riferimento sul Campo
I bit Type e Subtype del campo Frame Control determinano tutto sulla rilevanza di sicurezza di un frame. I filtri di visualizzazione di Wireshark si basano direttamente su queste classificazioni.
| Tipo di Frame | Esempi Subtype | Rilevanza Sicurezza | Filtro di Visualizzazione Chiave |
|---|---|---|---|
| Management (0) | Beacon, Probe Request/Response, Authentication, Association Request/Response, Deauthentication, Disassociation | Topologia BSS, capacità, enumerazione client, superficie di attacco per spoofing | wlan.fc.type == 0 |
| Control (1) | RTS, CTS, ACK, Block ACK | Prenotazione mezzo, mitigazione nodo nascosto; raramente contiene dati di sicurezza direttamente | wlan.fc.type == 1 |
| Data (2) | Data, Null, QoS Data, Data+CF-Ack | Traffico upper-layer incapsulato; lo stato di protezione rivela WPA2/WPA3 vs. aperto | wlan.fc.type == 2 |
| Extension (3) | Riservato/non comune | Non tipicamente incontrato in ricognizione standard | wlan.fc.type == 3 |
Subtype critici per ricognizione:
| Subtype | Valore Decimale | Filtro | Cosa Rivelano |
|---|---|---|---|
| Beacon | 8 | wlan.fc.subtype == 8 |
Capacità AP, SSID (o vuoto per hidden), RSN IE, supporto 802.11w, canale, rate |
| Probe Request | 4 | wlan.fc.subtype == 4 |
SSID desiderati dal client (diretti) o wildcard (broadcast); rivela target di roaming |
| Probe Response | 5 | wlan.fc.subtype == 5 |
Risposta AP a probe; dati comparabili al beacon ma attivati |
| Authentication | 11 | wlan.fc.subtype == 11 |
Numeri di sequenza autenticazione; tipo algoritmo (Open System vs. SAE) |
| Association Request | 0 | wlan.fc.subtype == 0 |
Capacità client, rate supportati, RSN IE dalla prospettiva client |
Intuizione conquistata con fatica: Un AP con "SSID nascosto" non omette il suo beacon—invia frame beacon con un elemento SSID vuoto (
length 0). L'SSID trapelo in probe response a client legittimi e in frame di association request da quei client. Una cattura passiva nel tempo recupera quasi sempre il nome senza probing attivo.
Scoperta SSID Nascosto e Enumerazione Client
Catturare la fuga di SSID:
# Cattura beacon e traffico diretto sul canale target
sudo tcpdump -i wlan0 -w hidden_ssid.pcap -e -s 0 \
'type mgt and (subtype beacon or subtype assoc-req or subtype reassoc-req or subtype probe-resp)'
Filtri di visualizzazione Wireshark per analisi post-cattura:
# Isola AP con SSID vuoto nei beacon ma SSID altrove
wlan.fc.subtype == 8 && !(wlan.ssid) && wlan.bssid == 00:11:22:33:44:55
# Poi cerca lo stesso BSSID con SSID non vuoto in altri frame
wlan.bssid == 00:11:22:33:44:55 && wlan.ssid
Enumerazione client da probe request—i client rivelano reti preferite e a volte se stessi:
# Tutti i probe request (broadcast e diretti)
wlan.fc.type == 0 && wlan.fc.subtype == 4
# Raggruppa per SSID sondato—rivela cronologia di roaming del client
tshark -r capture.pcap -Y 'wlan.fc.subtype == 4' -T fields \
-e wlan.sa -e wlan.ssid | sort | uniq -c | sort -rn
Interpretazione output campione:
42 6a:3c:4f:12:89:ab CorpWiFi
17 6a:3c:4f:12:89:ab GuestNet
9 6a:3c:4f:12:89:ab [EMPTY: broadcast probe]
Il client 6a:3c:4f:12:89:ab si è associato precedentemente a CorpWiFi; il probe broadcast suggerisce che non è riuscito a trovare una rete preferita ed è ricaduto sulla discovery wildcard. Il prefisso MAC potrebbe essere randomizzato (vedi sotto).
Elementi Informativi RSN: Lettura dello Stato di Protezione
L'RSN IE in beacon e probe response codifica la differenza tra WPA2-PSK, WPA2-Enterprise, WPA3-SAE, e se la protezione frame di gestione (802.11w) è richiesta o opzionale.
Filtri Wireshark per parsing delle capacità:
# Reti con qualsiasi RSN IE presente (non WEP, non aperte)
wlan.rsn
# 802.11w obbligatorio (MFP richiesto)
wlan.rsn.capabilities.mfpr == 1
# 802.11w opzionale (MFP capace ma non imposto)
wlan.rsn.capabilities.mfpc == 1 && wlan.rsn.capabilities.mfpr == 0
# WPA3-SAE (Authentication Key Management suite selector 00-0F-AC:8)
wlan.rsn.akms.suites == 00-0f-ac:08
| Posizione Campo RSN IE | Significato per Valutazione |
|---|---|
| Group Cipher Suite | Crittografia broadcast/multicast: tipicamente CCMP (00-0F-AC:4) o GCMP-256 per WPA3-Enterprise |
| Pairwise Cipher Suite Count | Solitamente 1; voci multiple suggeriscono modalità transizione o misconfigurazione |
| AKM Suite List | PSK (00-0F-AC:2), 802.1X (00-0F-AC:1), SAE (00-0F-AC:8), FT-SAE (00-0F-AC:9) |
| Bit 6-7 RSN Capabilities | MFPC (bit 6: capace), MFPR (bit 7: richiesto)—insieme definiscono la postura 802.11w |
Cosa fa: Il filtro
wlan.rsnisola reti protette moderne; combinato con selector AKM suite identifica WPA3 vs. modalità transizione legacy. Quando usarlo: Prioritizzare target di valutazione per livello di hardening, o rilevare reti capaci di downgrade. Rischi: Leggere "capace" come "imposto" lascia falsa fiducia; verificare sempre MFPR.
Randomizzazione Indirizzo MAC: Impatto sul Tracciamento
I client moderni randomizzano gli indirizzi MAC nelle richieste di probe per prevenire il tracciamento. Questo rompe l'enumerazione naive del client per MAC sorgente ma non tutti i metodi di correlazione.
Rilevamento pattern di randomizzazione:
| Indicatore | Tecnica | Limitazione |
|---|---|---|
| Bit localmente amministrato (U/L = 1 nel primo ottetto) | wlan.sa[0] & 0x02 == 0x02 |
Non tutti i MAC random lo impostano; alcune implementazioni usano range globalmente unici |
| Mismatch OUI | wlan.sa[0:3] != wlan.tag.oui in vendor-specific IE |
Raramente presente nei probe request |
| Gap numeri di sequenza | wlan.seq salta senza pattern di rollover |
Tracciamento stateful attraverso burst di probe; fallisce se il client tace |
| Timing/fingerprinting | Intervallo inter-probe, rate supportati, ordinamento IE | Euristico; richiede dati di training |
Quando la randomizzazione è attiva, pivotare l'enumerazione alla correlazione comportamentale: liste SSID probe, capacità 802.11 (HT/VHE capabilities, bitmap extended capabilities), e vendor-specific IE. Un client che sonda gli stessi cinque SSID attraverso multipli MAC random è ancora un unico client per scopi di threat modeling.
Analisi Spettrale e Interferenza Non-WiFi
Non tutte le radio parlano 802.11. Bluetooth, Zigbee, FHSS proprietari, telefoni cordless e forni a microonde occupano la banda 2.4 GHz; LTE-U e sistemi radar sconfinano sui canali DFS 5 GHz. Strumenti radio definiti da software (hackrf, rtl-sdr) o analizzatori di spettro dedicati (Wi-Spy, Oscium WiPry) rivelano energia che lo stack 802.11 scarta come rumore non parsificabile.
Correlazione pratica:
| Sintomo in Cattura 802.11 | Interferente Probabile | Conferma |
|---|---|---|
| Alto tasso di retry, basso RSSI, spettro pulito su altri canali | Interferenza co-canale da deployment AP denso | Utilizzo canale in elementi quiet dei beacon |
| Picchi periodici nel noise floor, ciclo ~15–20 secondi | Forno a microonde in 2.4 GHz | Waterfall spettrale mostra burst largo 20 MHz |
| Sordità completa su specifico canale 5 GHz con pattern radar | Rilevamento radar DFS (meteorologico, militare) | Frame di annuncio cambio canale nella cattura; verificare dominio regolatorio |
| Burst di energia stretti, frequency-hopping | Bluetooth Classic o BLE | Waterfall SDR mostra hop 1 MHz; cattura 802.11 mostra solo noise floor elevato |
Intuizione conquistata con fatica: Un adattatore WiFi in modalità monitor non può riportare ciò che non può decodificare. Prima di incolpare "copertura WiFi scarsa," escludere sempre interferenti non-WiFi con visualizzazione spettrale—specialmente in ambienti industriali dove telemetria 2.4 GHz proprietaria coesiste con WLAN enterprise.
Inferenza Topologia Enterprise
I deployment enterprise trapelano struttura attraverso pattern di beacon e probe:
- Set di BSSID multipli con SSID identico e MAC sequenziali: Indica architettura basata su controller con virtual AP su radio o interfacce dedicate. Il gap tra MAC suggerisce la dimensione del blocco di allocazione vendor.
- Intervalli beacon identici ma periodi DTIM varianti: Diverse politiche di risparmio energia o consegna multicast per ruolo AP (indoor vs. outdoor, voice-optimized vs. best-effort).
- Varianza timing risposte probe: AP con SSID identico ma latenza di risposta disparata possono essere su diversi gruppi controller o AP remoti connessi via WAN.
- Report vicini 802.11k/v/r nei beacon: Rivelano topologia di roaming pianificata—canali adiacenti e target BSSID che l'infrastruttura vuole che i client preferiscano.
Filtro Wireshark per elementi neighbor report:
wlan.tag.number == 52 # Neighbor Report element
wlan.tag.number == 69 # Fine Timing Measurement Parameters (802.11mc)
Correlazione Database Wardriving
BSSID, SSID e dati di geolocalizzazione raccolti possono essere correlati con database pubblici. WiGLE.net fornisce la più grande aggregazione aperta; la sua API permette lookup bulk per rilevamento cambiamenti infrastrutturali.
Confine etico: I dati WiGLE sono crowdsourced. Correlare il proprio ambiente autorizzato contro record storici è difensivo; query bulk per mappare target di terzi non lo è.
Lab: Correlazione API WiGLE per infrastruttura di proprietà
# Query WiGLE per un singolo BSSID noto come appartenente alla tua organizzazione
curl -s -u "WiGLE_USER:WiGLE_API_KEY" \
"https://api.wigle.net/api/v2/network/detail?netid=00:11:22:33:44:55" \
| jq '.results[] | {ssid, trilat, trilong, lastupdt}'
Variante produzione: Esportare lista BSSID da NMS/WLC, query batch notturna via API con rate limiting (WiGLE permette 100 query/minuto per utenti registrati), flaggare AP nuovamente esposti o rilocati.
Cosa fa: Identifica se AP autorizzati sono stati geolocalizzati e loggati da wardriver di terze parti—utile per rilevamento rogue AP e valutazione sicurezza fisica. Quando usarlo: Audit infrastruttura periodico, post-integrazione fusione, o dopo cambiamenti fisici di sito. Rischi: Limiti rate API; dati obsoleti (date ultima vista possono essere di mesi); falsi positivi da riutilizzo MAC in hardware riciclato.
Errori Comuni in Cattura Ricognizione
| Errore | Perché ti colpisce |
|---|---|
| Cattura in modalità managed invece di monitor mode | Vedi solo il tuo traffico e broadcast/multicast sul BSS unito; manchi beacon da altri ESS, frame diretti client-to-client, e flood di deauth |
| Dimenticare di bloccare canale o saltare troppo velocemente | Frammenta sequenze handshake attraverso file; Wireshark non può riassemblare o seguire stream divisi da cambio canale |
| Ignorare campi header 802.11 radiotap | Errori FCS, bad PLCP, o frame non-dati con payload spazzatura appaiono come "malformed" a meno che non filtri wlan_radio.fcs_bad == 0 |
| Confidare nella stringa SSID come identificatore unico | Multipli ESS possono condividere un SSID; BSSID è la chiave affidabile. Gli attacchi SSID collision sfruttano deliberatamente questa confusione |
| Trascurare catture 6 GHz / Wi-Fi 6E | Richiede hardware 6 GHz-capable e spesso diversa attivazione regolatoria; silenzioso su strumenti solo 2.4/5 GHz |
Checklist: Flusso di Lavoro Ricognizione Baseline
- [ ] Verificare supporto modalità monitor adattatore e stabilità driver sotto carico
- [ ] Documentare piano canali per dominio regolatorio; notare canali DFS che richiedono rilevamento radar
- [ ] Catturare minimo 5 minuti per canale, o un intervallo beacon completo × fattore di permanenza
- [ ] Loggare metadati cattura: tipo adattatore, versione driver, configurazione antenna, posizione fisica
- [ ] Post-processing: estrarre BSSID unici, SSID, AKM suite, stato 802.11w, indicatori randomizzazione MAC client
- [ ] Cross-riferire contro inventario infrastruttura autorizzata; flaggare BSSID sconosciuti per triage rogue AP
- [ ] Archiviare PCAP raw con retention conforme a policy di incident response; derivare CSV riassuntivo per trend analysis