Spoofing DHCP: DHCP Spoofing (T1557.003)

L'esecuzione controllata di uno scenario DHCP Spoofing richiede un segmento L2 di laboratorio isolato o un ambiente autorizzato con scope contrattuale esplicito su ARP/DHCP poisoning. Il presupposto è la presenza dell'attaccante nello stesso dominio di broadcast della vittima, tipicamente ottenuta dopo compromissione di un endpoint interno o accesso fisico a una porta trunk non protetta.

Lo strumento di riferimento è Responder (open source), che integra un rogue DHCP server attivabile con l'opzione dedicata. Il comando tipico è sudo responder -I eth0 -d, dove il flag -d abilita la modalità DHCP e distribuisce ai client un WPAD malevolo insieme a gateway e DNS alterati. La combinazione con -w (WPAD server integrato) e -b (basic auth downgrade) massimizza la cattura di hash NTLMv1/v2. Per DHCPv6, mitm6 (open source) è lo standard de facto: eseguito con sudo mitm6 -d dominio.local -i eth0, risponde ai messaggi INFORMATION-REQUEST di Windows configurandosi come DNS IPv6 primario e reindirizzando le query verso il nodo attaccante, spesso in catena con ntlmrelayx della suite impacket (open source) per relay verso LDAP/LDAPS.

Per scenari di DHCP starvation si utilizza Yersinia (open source) con sudo yersinia -I e selezione del modulo DHCP, oppure lo script dhcpstarv (open source). L'obiettivo è esaurire il pool per costringere i nuovi client a leasing dal rogue server. In ambienti di test si può costruire un DHCP rogue anche con dnsmasq (open source) configurato con opzioni personalizzate su dhcp-option=3,IP_attaccante (gateway) e dhcp-option=6,IP_attaccante (DNS).

La catena d'attacco tipica in un red team engagement segue tre fasi: (1) posizionamento L2 tramite compromissione endpoint o VLAN hopping con Scapy (open source); (2) rogue DHCP + DNS spoofing per redirigere traffico HTTPS verso proxy trasparente mitmproxy (open source) con certificati generati al volo, oppure downgrade su HTTP; (3) cattura credenziali NTLM, cookie di sessione, token OAuth e relay con ntlmrelayx.

Su ESXi e infrastrutture ipervisor la tecnica ha rilevanza quando le port group virtuali consentono Forged Transmits e MAC Address Changes impostati su Accept: un attaccante con controllo di una VM può innescare lo stesso scenario contro altre VM sullo stesso vSwitch. La verifica avviene con esxcli network vswitch standard policy security get.

La detection di DHCP Spoofing è essenzialmente un problema di baseline di rete: bisogna sapere quali server DHCP sono autorizzati e allertare su qualunque OFFER o ACK proveniente da sorgenti diverse. La regola AN1290 di MITRE per Windows si basa proprio su questo principio, correlando WinEventLog:System con flussi NSM:Flow per identificare server non nell'elenco AuthorizedDHCPServers.

Sul piano dei log source, gli eventi chiave in ambiente Windows Server con ruolo DHCP sono nel canale Microsoft-Windows-DHCP-Server/Operational e nel log System con EventCode 1341 (scope disattivato), 1342 e 1020 (rogue server detection nativa). Sui client, i cambi di lease sono tracciati in Microsoft-Windows-Dhcp-Client/Operational con EventCode 50037 e correlati. In ambienti Linux, linux:syslog raccoglie i messaggi dhclient con nuovi DNS o gateway assegnati; su macOS l'unifiedlog espone gli eventi del subsystem com.apple.bootp.

A livello network, i sensori IDS come Suricata (open source) o Zeek (open source) forniscono visibilità completa: Zeek genera automaticamente il log dhcp.log con server_addr, requested_addr, lease_time e assigned_addr, permettendo query del tipo "quali MAC hanno risposto con OFFER negli ultimi 30 giorni" per costruire l'allowlist. Regole Suricata sulla porta UDP 67/68 possono flaggare pattern anomali, mentre per DHCPv6 va monitorata la porta UDP 547 e le risposte multicast a ff02::1:2.

Gli indicatori comportamentali prioritari sono: molteplici OFFER per lo stesso DISCOVER provenienti da MAC diversi, variazione improvvisa del DNS assegnato su una fascia di client, incremento anomalo di DISCOVER compatibile con starvation attack (soglia utile: >100 lease request/minuto da MAC non ancora visti), comparsa di server IPv6 RA o risposte DHCPv6 in reti storicamente solo IPv4. La combinazione "nuovo DHCP server + successiva query DNS verso dominio a bassa reputazione" è un pattern ad alta confidenza.

Sul piano preventivo e di hardening, DHCP snooping sugli switch L2 con configurazione delle porte uplink come trusted neutralizza la classe di attacco alla radice; va abbinato a Dynamic ARP Inspection e IP Source Guard. Per DHCPv6 servono RA Guard e blocco esplicito del traffico UDP 546/547 sulle porte access. Questi controlli mappano sulle mitigazioni M1031 e M1037.

I falsi positivi tipici arrivano da server DHCP legittimi non censiti (stampanti multifunzione con DHCP integrato attivo per errore, appliance di test, hypervisor con DHCP interno per NAT). Una fase iniziale di discovery di 2-4 settimane per popolare l'allowlist riduce drasticamente il rumore.

L'analisi forense di un incidente DHCP Spoofing ricostruisce la finestra temporale in cui i client hanno accettato lease malevoli e traccia la propagazione del traffico deviato. Il punto di partenza è la correlazione tra lease log, configurazioni di rete degli endpoint e capture di traffico se disponibili.

Su Windows client, l'artefatto primario è la registry key HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces{GUID}, dove i valori DhcpServer, DhcpNameServer, DhcpDefaultGateway e LeaseObtainedTime documentano l'ultimo lease accettato. Il log Microsoft-Windows-Dhcp-Client/Operational conserva la sequenza cronologica dei rinnovi con EventCode 50036, 50037, 50038. Il comando ipconfig /all fornisce lo stato istantaneo, mentre Get-NetIPConfiguration in PowerShell (built-in) restituisce dati strutturati. Il file C:\Windows\System32\dhcp\DhcpSrvLog-.log* sui server Windows contiene lo storico dei lease erogati, utile per confermare che il client non ha ricevuto configurazione dal server legittimo in una specifica finestra.

Su Linux, i file di riferimento sono /var/lib/dhcp/dhclient.leases o /var/lib/NetworkManager/.lease* con timestamp di acquisizione, server_identifier e opzioni ricevute. Il journal di systemd (journalctl -u NetworkManager o journalctl -u dhcpcd) espone la sequenza di negoziazione. Su macOS, i lease sono in /var/db/dhcpclient/leases/ con formato plist, ispezionabili con plutil -p; l'unified log si interroga con log show --predicate 'subsystem == "com.apple.bootp"' --last 7d.

La timeline di ricostruzione si costruisce in tre livelli. Primo, identificare il server_identifier anomalo confrontandolo con l'inventario dei DHCP autorizzati. Secondo, per ogni endpoint compromesso, determinare LeaseObtainedTime e LeaseExpires per delimitare la finestra di esposizione. Terzo, correlare con i log DNS del periodo: se il DNS spoofato ha risolto domini legittimi verso IP attaccante, i log del resolver locale, i browser history e i log applicativi mostreranno connessioni sospette in quella finestra.

Sul piano network, se sono disponibili PCAP o metadati Zeek, il file dhcp.log fornisce l'evidenza definitiva: mittente MAC/IP dell'OFFER malevolo, opzioni distribuite, client vittime. In assenza di capture, i NetFlow/IPFIX aiutano a identificare i client il cui traffico è stato improvvisamente incanalato verso un gateway anomalo. Su switch Cisco, i log di DHCP snooping binding table (show ip dhcp snooping binding) e i violation counter (show ip dhcp snooping statistics) sono fondamentali quando la funzione era attiva.

Gli IoC persistenti da estrarre includono: MAC del rogue server, IP e hostname assunti, DNS distribuiti, WPAD URL erogati, timestamp di prima e ultima osservazione, elenco endpoint impattati. Questi elementi alimentano sia il report d'incidente sia le regole di detection aggiornate.

I dati MITRE ATT&CK forniti per T1557.003 non elencano gruppi APT, software o campagne specificamente attribuiti a questa sottotecnica. Questa assenza è di per sé un elemento di intelligence rilevante e va interpretata con attenzione operativa piuttosto che come indicazione di scarsa rilevanza.

Il DHCP Spoofing è una tecnica intrinsecamente post-compromise e L2-bound: richiede presenza sul segmento di broadcast, quindi è più caratteristica di operazioni di red team interni, penetration test e insider threat che di intrusioni APT tracciate pubblicamente con attribuzione a un gruppo specifico. Le APT che raggiungono un foothold interno tendono a documentare l'uso di tecniche AiTM sotto ombrelli più ampi come T1557 genitore o T1557.001 (LLMNR/NBT-NS Poisoning) e T1557.002 (ARP Cache Poisoning), storicamente meglio strumentate e più stealth della variante DHCP.

Sul piano dell'evoluzione, la tecnica è particolarmente rilevante in tre contesti che meritano monitoraggio nei feed di threat intelligence. Il primo è quello degli attacchi a reti enterprise dual-stack dove IPv6 è abilitato di default ma non gestito: strumenti come mitm6 hanno dimostrato che una singola workstation compromessa può innescare relay NTLM verso Domain Controller sfruttando l'assenza di monitoring DHCPv6. Il secondo riguarda ambienti OT/ICS e reti industriali, dove segmenti L2 estesi, assenza di DHCP snooping e client legacy rendono lo spoofing efficace anche contro sistemi di supervisione. Il terzo è il cloud ibrido, dove reti overlay virtuali e VPN client-to-site talvolta espongono broadcast domain condivisi in modo non evidente all'amministratore.

Sul fronte del tool overlap, le utility utilizzate da red team e attaccanti convergono su un set ristretto e maturo: Responder, mitm6, impacket/ntlmrelayx, bettercap (open source), Yersinia. La presenza di questi binari o dei loro artefatti di rete in ambiente enterprise, senza contesto autorizzativo, è un forte segnale di attività ostile o non conforme. Le firme network per identificare Responder (pattern nei NetBIOS/LLMNR reply) e mitm6 (specifiche opzioni DHCPv6) sono ben documentate nelle regole Suricata Emerging Threats (freemium/open).

Dal punto di vista del trend prospettico, l'adozione crescente di Zero Trust Network Access e la segmentazione microperimetrale riducono la superficie utile del DHCP Spoofing tradizionale, ma non nei segmenti utente flat che rimangono maggioritari nelle PMI. L'introduzione di 802.1X con NAC e di DHCP snooping obbligatorio nelle policy di baseline enterprise è la contromisura strutturale più efficace. Gli intelligence officer dovrebbero monitorare specificamente i report di ingaggi red team pubblici e i writeup di CTF/HTB che aggiornano vettori DHCPv6, poiché è lì che emergono per prime le variazioni tecniche prima di essere adottate operativamente.

MITRE ATT&CK T1557.003 (DHCP Spoofing), tattiche TA0006 e TA0009, mitigazioni M1031 e M1037, regole di detection DET0468 (AN1290 Windows, AN1291 Linux, AN1292 macOS). Documentazione ufficiale di Responder, mitm6, impacket, Zeek, Suricata, Yersinia e dnsmasq per riferimenti tecnici sui tool. Documentazione Cisco su DHCP snooping, Dynamic ARP Inspection e RA Guard. Le sezioni operative integrano conoscenza professionale di cybersecurity su comandi, artefatti forensi e hardening di rete.