diff --git a/src/generic-methodologies-and-resources/pentesting-network/dhcpv6.md b/src/generic-methodologies-and-resources/pentesting-network/dhcpv6.md index c5b4964eb07..691bdf88dac 100644 --- a/src/generic-methodologies-and-resources/pentesting-network/dhcpv6.md +++ b/src/generic-methodologies-and-resources/pentesting-network/dhcpv6.md @@ -35,11 +35,68 @@ A comparative view of DHCPv6 and DHCPv4 message types is presented in the table 12. **Relay-Forw (12)**: Relay agents forward messages to servers. 13. **Relay-Repl (13)**: Servers reply to relay agents, who then deliver the message to the client. -## References +## DHCPv6 Essentials (Attacker View) + +- **UDP ports**: clients listen on `546`, servers/relays on `547`. +- **Multicast**: clients send Solicit/Information-Request to `ff02::1:2` (All DHCPv6 Relay Agents and Servers). +- **Client identity**: DHCPv6 uses a **DUID** (Client Identifier option) instead of MAC-only identity, so spoofing requires matching the DUID rather than just L2. +- **Stateful mode**: uses **IA_NA** (addresses) and optionally **IA_PD** (prefix delegation). +- **Stateless mode**: uses **Information-Request** to fetch only options (DNS, domain search list, etc.). +- **High-value option**: **DNS Recursive Name Server** (option 23) is the usual target for DNS takeover in mixed IPv4/IPv6 networks. +- **High-value option**: **Domain Search List** (option 24) can leak internal namespaces and steer short-name resolution. +- **High-value option**: **Client FQDN** (if sent) can leak internal naming and is often used to build targeted relay rules. + +## Passive Recon from DHCPv6 Traffic + +Sniffing DHCPv6 gives you organization-specific context without sending packets: + +- Internal DNS servers (option 23) and search domains (option 24). +- Hostnames/FQDNs when clients send the FQDN option. +- DUID formats (LLT/LL/UUID/EN) that help correlate hosts across address changes. + +If you need the full IPv6 MITM chain (RA + DHCPv6 DNS takeover + relay), see [Pentesting IPv6](pentesting-ipv6.md). + +## Rogue DHCPv6 / DNS Takeover (Practical Tools) + +Common offensive pattern: stand up a rogue DHCPv6 server, respond to Solicit/Information-Request, and deliver **attacker-controlled DNS** (and optionally addresses/prefixes). Practical tooling: + +- **mitm6** (Windows-focused DNS takeover): + +```bash +sudo mitm6 -i eth0 -d corp.local +``` + +- **pretender** (DHCPv6 DNS takeover + LNR spoofing): + +```bash +pretender -i eth0 --dry +pretender -i eth0 +``` + +- **THC IPv6 fake DHCPv6 server** (`fake_dhcps6`): + +```bash +fake_dhcps6 [dhcp-server-ip [mac]] +``` + +## Reconfigure Message Abuse (When Auth Is Missing) + +The **Reconfigure** message is designed for servers to trigger a Renew/Information-Request on clients. RFC 8415 requires clients to **discard unauthenticated** Reconfigure messages, but in networks where DHCPv6 authentication is unused or mis-implemented, spoofed Reconfigure frames can be leveraged to **force fresh DHCPv6 exchanges**, giving a rogue server another chance to inject DNS/search-list options. + +## Relay Agent Options & Policy Abuse + +Many enterprise/ISP deployments use DHCPv6 relays and apply policy based on relay options: + +- **Interface-ID** and **Remote-ID** are commonly inserted by relays to identify the client’s attachment point. +- If an attacker can spoof or tamper with **Relay-Forward** traffic, they can influence how the server classifies the client and which policies/options it applies (address pools, DNS servers, prefix delegation, etc.). + + +## References - [https://support.huawei.com/enterprise/en/doc/EDOC1100306163/d427e938/introduction-to-dhcpv6-messages](https://support.huawei.com/enterprise/en/doc/EDOC1100306163/d427e938/introduction-to-dhcpv6-messages) +- [https://www.rfc-editor.org/rfc/rfc8415.txt](https://www.rfc-editor.org/rfc/rfc8415.txt) +- [https://blog.redteam-pentesting.de/2022/introducing-pretender/](https://blog.redteam-pentesting.de/2022/introducing-pretender/) {{#include ../../banners/hacktricks-training.md}} -