Responder 3.0.7.0 comes with a new DHCP poisoner module. This module allows you to remotely inject a WPAD server with no user interaction (0 click) and capture/relay NTLM credentials on all Windows versions ranging from Windows 98 to the current version (Windows 11, Server 2022).
WPAD and DHCP
Windows uses several custom DHCP options such as NetBIOS, WINS, WPAD settings. When a workstation sends a DHCP request to get its networking settings, these additional settings can be included in the DHCP answer to facilitate straightforward connectivity and name resolution.
WPAD configuration is currently provided in DHCP option 252.
The DHCP protocol is quite old (1993), and doesn't provide any relevant security. Requests are broadcast, can be relayed across subnets with DHCP relay and obviously anyone on a subnet who can answer more rapidly than the actual DHCP server can inject any network settings on the client who issued the DHCP request.
Spoofing DHCP challenges
Spoofing DHCP responses with no disruption can be challenging since you're interfering with a workstation network configuration. Usually, you need to have very good knowledge of the target subnet, where is the DNS server, where is the switch, routing table, domain, netmask, DHCP server, etc. Any mistake with these settings will result in disruption on the network.
However, spoofing DHCP answers has unique benefits. It's definitely stealthier than ARP poisoning; One unicast response is sufficient to permanently poison a victim's routing information, it's also common to see multiple DHCP servers operating on a network. Unicast DHCP answers are more complex to detect, a few switch provides security settings to prevent DHCP snooping, however those settings are not straightforward and are often misconfigured when enabled.
Responder approach
Previous Responder version included a DHCP.py script in the tool folder. This script was not the easiest to operate and the fear of causing disruption on client networks made it a "last option" tool.
Responder 3.0.7.0 changed that and DHCP poisoning is completely automated and cause no disruption on the network.
To understand how Responder do that, you need to understand how DHCP works,
A client performs a broadcast DHCP REQUEST when the workstation is restarted, when the network adapter is enabled or simply when the DHCP lease expires (usually a few hours), the DHCP server reply with a DHCP ACK answer containing all network settings and additional options.
A client performs a broadcast DHCP REQUEST when the workstation is restarted, when the network adapter is enabled or simply when the DHCP lease expires (usually a few hours), the DHCP server reply with a DHCP ACK answer containing all network settings and additional options.
Responder takes advantage of that and race against the legit DHCP server to answers with a DHCP ACK containing invalid network settings, a valid WPAD server (Responder IP) and a very short lease time (10 seconds).
The workstation gets the WPAD server injected and will issue a new DHCP request right after, Responder will let the legit DHCP server do its job and provide the right network settings.
Due to Windows DHCP client design, an injected WPAD server is permanent until next reboot regardless if another DHCP server provides a new configuration :)
A maximum of 4 spoofing attempts by MAC address has been configured in the DHCP module, which should be more than enough to get the WPAD server injected.
How to run it:
The new DHCP module is disabled by default, you can enable it with the -d command line option.
WPADScript = function FindProxyForURL(url, host){if ((host == "localhost") || shExpMatch(host, "localhost.*") ||(host == "127.0.0.1") || isPlainHostName(host)) return "DIRECT"; if (dnsDomainIs(host, "ProxySrv")||shExpMatch(host, "(*.ProxySrv|ProxySrv)")) return "DIRECT"; return 'PROXY ProxySrv:3128; PROXY ProxySrv:3141; DIRECT';}
Wpad script configuration is automated, the next step is to launch Responder with the following arguments:
./Responder.py -I eth0 -rPdv
Why -P and not -F? Nowadays, WPAD NTLM authentication is unlikely successful, therefore forcing NTLM authentication on wpad.dat retrieval is not recommended. The concept is to serve the wpad.dat file with no user authentication, and as soon the client starts using our proxy, we force authentication with the Proxy-Auth module :)
When a WPAD server is injected, the user on the workstation doesn't need to open or do anything, NTLM hashes starts to flow in Responder automatically.
Final words
This Responder version is currently available for our sponsors on Porchetta Industries.
This functionality will be released publicly for everyone else in a few months on github.
Porchetta Industries is a unique platform allowing tool makers to be sponsored for their work and tools they provides freely to the security community at large.
For more information, visit: https://porchetta.industries
No comments:
Post a Comment