WPAD spoofing
Theory
A proxy can be used to handle clients requests (for example to access the Internet). In a network in which the topology changes frequently, adaptive configurations are needed. A type of proxies called "Adaptive proxies" uses a configuration script.
The Web Proxy Automatic Discovery (WPAD) protocol helps clients in finding a proxy configuration script (wpad.dat
). This script gives a set of proxies that can be used, and can be located with an hostname or an URL. Various mechanisms can be used to find its location (by order of resolution):
- WinHTTP/WinINET
- DHCP
- DNS
- Internet Explorer's LAN settings, or configuration file
Practice
WPAD spoofing can be combined with
- LLMNR and NBT-NS spoofing
- DHCP poisoning combined (or not) with DNS spoofing
- ARP poisoning or DHCPv6 spoofing, followed by DNS spoofing
Proxy auth NTLM authentication can either be
- forced and captured with Responder with
--wredir
and--ProxyAuth
- forced and relayed with ntlmrelayx by using the
--http-port 3128
argument
through LLMNR, NBT-NS spoofing
On old Windows systems (i.e. lacking the MS16-077 security update), the WPAD location could be obtained through insecure name resolution protocols like LLMNR and NBT-NS when standard DNS queries were failing (i.e. no DNS record for WPAD). This allowed attackers to operate LLMNR and NBT-NS spoofing to answer those WPAD queries and redirect to a fake wpad.dat
file, hence poisoning the web proxy configuration of the requesting clients, hence obtaining more traffic.
Responder (Python) and Inveigh (Powershell) are great tools for name poisoning. In addition to name poisoning, they also have the ability to start servers (listeners) that will capture authentications and echo the NTLM hashes to the attacker.
The following command will start LLMNR, NBTS and mDNS spoofing. Name resolution queries for the wpad server will be answered just like any other query. Fake authentication servers (HTTP/S, SMB, SQL, FTP, IMAP, POP3, DNS, LDAP, ...) will capture NTLM hashes.
- The
-w/--wpad
option will make Responder start the WPAD rogue server so that fakewpad.dat
file can be served to requesting clients. - The
-P/--ProxyAuth
option to force the Windows client to authenticate after thewpad.dat
is accessed and when the client starts using the proxy
responder --interface "eth0" --wpad --ProxyAuth
responder -I "eth0" -wP
through ADIDNS spoofing
On up-to-date machines (i.e. with the MS16-077 security update applied), WPAD can still be abused through ADIDNS spoofing if the WPAD record does not exist. There is however a DNS block list mitigation called GQBL (Global Query Block List) preventing names like WPAD and ISATAP (default entries) to be resolved. This block list exists to reduce vulnerabilities associated with dynamic DNS updates but it can be edited when implementing WPAD.
Pre CVE-2018-8320
On machines that are not patched against CVE-2018-8320, there are two ways to bypass the GQBL: by registering a wildcard record or by registering a domain alias (DNAME) record, which can be conducted as follows with Powermad (Powershell).
New-ADIDNSNode -Node '*' -Data 'Pentest_IP_Address'
New-ADIDNSNode -Node wpad -Type DNAME -Data 'pentester01.TARGETDOMAIN.LOCAL'
Post CVE-2018-8320
On machines that are patched against that CVE, registering a name server (NS) record could still work.
New-ADIDNSNode -Node wpad -Type NS -Data 'pentester01.TARGETDOMAIN.LOCAL'
In order for the NS record technique to work, the tester has to have a DNS server running for DNS spoofing. This can easily be accomplished with dnschef (Python).
dnschef --fakeip 'Pentest_IP_Address' --interface 'Pentest_IP_Address' --port 53 --logfile dnschef.log
through DHCPv6 spoofing
On up-to-date machines (i.e. with the MS16-077 security update applied), WPAD can still be abused through ADIDNS spoofing, even if the WPAD record does exist. With DNS poisoning through DHCPv6 spoofing, an attacker can reply to DHCPv6 requests, and then reply to DNS queries.
This attack can be conducted with mitm6 (Python), see the DHCPv6 spoofing page for exploitation notes.
Resources
https://blog.netspi.com/adidns-revisited/
https://www.fox-it.com/en/news/blog/mitm6-compromising-ipv4-networks-via-ipv6/