Cleaning Up Risky Traffic, A Mini Series: WPAD

Web Proxy Auto-Discovery (WPAD) – A Security Risk and How to Mitigate It

This article provides a brief overview of Web Proxy Auto-Discovery (WPAD) attacks, explains how to remediate and defend them, and includes a guide for setting up an NTLM relay honeypot as a tripwire for attackers.

Web Proxy Auto-Discovery (WPAD) is a feature that allows browsers to automatically locate the configuration for their organization’s web proxy. While this is a convenient feature, it can pose a serious security risk if left unsecured. The WPAD protocol can be exploited by attackers to intercept a WPAD request and insert their own IP as the provider of the WPAD configuration instructions. This allows attackers to execute malicious attacks such as credential theft or malware delivery.

The WPAD protocol uses either DHCP, DNS, or LLMNR and NBNS to locate the web proxy configuration. When a browser is configured to auto-discover proxy settings, which is often the default configuration, it will query “wpad.<yourdomain>.<tld>”. If it gets a response, it will connect to that IP and download the wpad.dat file, which it then uses to proxy its browsing as instructed in the file.

Tactics and Vulnerabilities

The following CVE’s and tactics correlate to WPAD.

1. Tactic: Initial Access Technique: Exploit Public-Facing Application (T1190) WPAD can be exploited to gain initial access to a network by redirecting clients to a malicious proxy server.
2. Tactic: Execution Technique: Command and Scripting Interpreter (T1059) Attackers can use WPAD to execute malicious commands or scripts on client machines.
3. Tactic: Persistence Technique: Rogue Domain Controller (T1207) Attackers can set up a rogue domain controller that responds to WPAD requests and intercepts traffic, allowing them to maintain persistence on the network.
4. Tactic: Defense Evasion Technique: Proxy (T1071) Attackers can use WPAD to bypass security measures by redirecting traffic through a proxy server that they control.

• CVE-2017-16996: WPAD Name Collision Vulnerability – this vulnerability arises when a malicious actor registers a domain name that matches the WPAD host name used by an organization. If WPAD is enabled and the organization’s devices automatically use the malicious actor’s domain name to locate the WPAD configuration file, the attacker can potentially intercept and redirect network traffic.
• CVE-2016-10183: WPAD Proxy Autodiscovery Protocol vulnerability – this vulnerability allows an attacker to conduct a man-in-the-middle (MITM) attack by tricking a victim’s device into using a malicious proxy server. This can lead to sensitive data being intercepted or modified by the attacker.
• CVE-2015-6495: WPAD Proxy Autodiscovery Protocol vulnerability – similar to the above vulnerability, this CVE describes a flaw in the way that WPAD autodiscovery works that could allow an attacker to conduct a MITM attack.

Remediation for WPAD

To mitigate this security risk, there are several steps that can be taken. First, create the wpad A record on your DNS servers and point it to 127.0.0.1 if you don’t have a proxy server. If you have a proxy server, then point it to that IP instead. This ensures that the WPAD request is redirected back to the client machine, preventing any external attacker from intercepting or manipulating the request.

Second, create a hosts file entry on your endpoints for WPAD as well. This will protect them while off-net. By adding the hosts file entry, you tell your machine to always use the IP you provided for WPAD, preventing the machine from querying DNS or LLMNR and NBNS for WPAD. This makes it harder for attackers to intercept the request or manipulate it.

Third, disable auto-discovery for your browsers. This can be done by creating a new DWORD 32-Bit value in HKEY_Current_User\Software\Microsoft\Windows\Current Version\Internet Settings\WPAD, calling it WpadOverride, and setting the value to 1. Your mileage may vary depending on the browsers you support in your enterprise, but most modern browsers support this configuration. This step ensures that your machines don’t try to auto-discover the proxy configuration, further protecting them against potential attacks.

Finally, set the WPAD server via DHCP as well. It is Option 252 and just takes a string value of a URL to a wpad.dat file. By setting the WPAD server via DHCP, you ensure that all machines in your network are configured to use the same WPAD configuration. This makes it easier to manage and maintain the WPAD configuration across your network.

But what if we could use this attack against our attackers? By disabling WPAD on our clients and setting hosts file entries for WPAD on them pointing to localhost, we can create a canary in our enterprise coal mine and host a wpad.dat file on some host. Anything that queries DNS for WPAD or hits our wpad web host is suspicious, allowing us to detect and respond to potential attacks. This technique involves creating a fake WPAD configuration that points to a non-existent IP address. If an attacker tries to intercept the WPAD request, they will get an error message or a timeout, which can alert your security team to potential attacks.

Setting up a honeypot for WPAD (Web Proxy Auto-Discovery) for free with open-source tools involves the following steps:

1. Choose a honeypot platform: There are several open-source honeypot platforms available, such as Dionaea, Cowrie, and Honeyd, among others. Choose a platform that supports WPAD and is compatible with your operating system.
2. Set up a virtual machine: Create a virtual machine to host the honeypot. Ensure that the virtual machine is isolated from the rest of the network to prevent attackers from gaining access to other systems.
3. Install Honeyd on a Linux server: Install the chosen honeypot platform and configure it to intercept requests for WPAD files. The honeypot should serve a fake WPAD file that directs attackers to the fake proxy server.
4. Create a configuration file for Honeyd that includes the following lines: create wpad set wpad personality “Microsoft Internet Explorer 6.0” set wpad default tcp action reset bind wpad 0.0.0.0
5. Start Honeyd with the configuration file: honeyd -f honeyd.conf
6. Create a fake WPAD file and place it in the /var/www/html/ directory: echo “function FindProxyForURL(url, host) { return ‘PROXY 10.0.0.1:8080’; }” > /var/www/html/wpad.dat
7. Configure your network to point to the IP address of the Honeyd server as the WPAD server.
8. Monitor and analyze: Monitor the honeypot for any suspicious activity, such as attempts to exploit vulnerabilities or unauthorized access attempts. Analyze the logs to identify attack patterns and develop effective countermeasures.
9. Maintain and update: Regularly update the honeypot and its components to ensure that it is up-to-date with the latest security patches and threat intelligence.

By taking these steps, you can ensure the security of your organization’s web proxy and protect against potential attacks. It’s always better to be proactive than reactive when it comes to security.

Overall, Web Proxy Auto-Discovery (WPAD) is a convenient feature that can save time and effort in configuring web proxies for an organization’s devices. However, it can pose a serious security risk if left unsecured, as attackers can exploit the protocol to execute malicious attacks. To mitigate this risk, it is important to take steps such as disabling auto-discovery for browsers, creating a wpad A record on DNS servers, and setting up a honeypot for WPAD. By taking these steps, you can ensure the security of your organization’s web proxy and protect against potential attacks.

For assistance in securing your network against WPAD attacks or to see how our fully managed XDR solution can help detect and prevent misconfigurations and malicious actors, reach out to professionalservices@tridentstack.com or email sales@tridentstack.com.