Skip to content
Naked Security Naked Security

When domain names attack: the WPAD name collision vulnerability

Poorly configured networks and new rules on internet domain names are giving cybercriminals a powerful new attack tool.

A combination of poorly configured networks and new rules on internet domain names are giving cybercriminals a new and easy way to attack entire organisations, according to research out of the University of Michigan.

The vulnerability, described by US-CERT (the United States Computer Emergency Readiness Team) in alert TA16-144A issued 23 May 2016, affects computers that are using WPAD.

WPAD is short for Web Proxy Autodiscovery Protocol, a system that makes it easy for organisations to configure the many web browsers inside their network.

WPAD is supposed to find its browser configuration files on the internal network, but wily attackers may be able to trick WPAD into downloading booby-trapped versions of those configuration files from the public internet instead.

Worse still, if you use a work computer at home, and WPAD is enabled, you may very well end up searching for your browser configuration on the open internet every time, simply because your work network isn’t visible.

And WPAD very often is enabled, as US-CERT points out:

WPAD is enabled by default on all Microsoft Windows operating systems and Internet Explorer browsers. WPAD is supported but not enabled by default on Mac and Linux-based operating systems, as well as, Safari, Chrome, and Firefox browsers.

WPAD explained

Organisations typically allow access to the web through intermediary servers called proxies to improve performance, monitoring and security.

But that creates a “chicken-and-egg” problem: how to tell the browsers inside the network which proxy server to user in order to get web access in the first place?

The easiest way to answer that question is with a configuration file called a PAC (proxy auto-config) file that sets the browser up automatically.

So, before it can find the proxy server, a web browser needs to know: where’s the PAC file?

And that’s where WPAD comes in – a WPAD-enabled browser will automatically look for a PAC file called wpad.dat on the local network.

The browser works out where to look by using the network name of the computer it’s on. A browser on a computer with the network name would look in the following locations, in order:

The .company.example domain is private to the organisation’s network and DNS lookups for *.company.example domains are supposed to be answered by the organisation’s own DNS servers.

Unfortunately it doesn’t always work out that way.

If a web browser finds itself on another network, one where the DNS servers don’t know how to respond to queries for .company.example, those queries may be escalated to public DNS servers.

According to US-CERT:

The WPAD vulnerability is significant to corporate assets such as laptops. In some cases these assets are vulnerable even while at work but observations indicate that most assets become vulnerable when used outside an internal network (e.g. home networks, public Wi-Fi networks).

It’s a data leak that happens a lot, according to the University of Michigan:

in two of 13 DNS root servers, roughly 20 million such queries are observed to be leaking to the public DNS namespace every day. This has been a known problem for years but … were not exploitable previously.

This is dangerous because if attackers were able to purchase the domain name .company.example they could put up a website at and publish their own PAC file that tells browsers to use the attacker’s proxy server.

The attacker would then have a grandstand seat from which to spy on all the web traffic passing to and from that browser, extracting personal data or confidential company information and injecting malware or ads.

WPAD data leakage has been going on for years but some companies have avoided trouble in spite of their poor network configuration because in private they use their own, official top-level domain name, like, or a made-up top-level domain like .company.test that won’t work on the public internet and isn’t for sale.

The problem is that a recent change in the way that global top-level domains (gTLDs) work is changing that.

How the gTLD project made it worse

Global top-level domains include names that don’t denote any geographical region, such as .com, .org and .net.

In the beginning, the internet had just 7 gTLDs and the number grew very sedately until 2011, by which time there were 22.

But in 2012 ICANN (the Internet Corporation for Assigned Names and Numbers) threw the doors open and started taking applications for the creation of brand new gTLDs and today there are more than 700 of them.

The expanded crop of gTLDs includes everything from .ninja to .city and a number of things that companies might plausibly use internally such as .office, .network, .global and .group.

Domain names that once kept companies immune from WPAD data leakage, because they only worked inside the company, are starting to work outside the company too – and they’re up for sale.

Organisations can no longer assume that the domain names they made up for their private DNS won’t work on the internet, so the problem of WPAD data leakage has become a genuine vulnerability.

The researchers at the University of Michigan have shown that WPAD attacks are possible and practical but not widely exploited:

We find that even though some attack surface domains have already been registered, the overall registration and exploitation status are still in the early stage, indicating that proactive protection strategies are still feasible.

US-CERT recommends that administrators take the following steps to mitigate this vulnerability:

  • Consider disabling automatic proxy discovery/configuration in browsers and operating systems when you set up and device that will not be used on internal networks.
  • Consider using a fully qualified domain name (FQDN) from global DNS as the root for enterprise and other internal namespace.
  • Configure internal DNS servers to respond authoritatively to internal TLD queries.
  • Configure firewalls and proxies to log and block outbound requests for wpad.dat files.
  • Identify expected WPAD network traffic and monitor the public namespace or consider registering domains defensively to avoid future name collisions.
  • File a report with ICANN if your system is suffering demonstrably severe harm as a consequence of name collision by visiting.

One more suggestion from us: don’t make up domain names, not even (perhaps especially) for testing or documentation.

If you need sample domain names that don’t need registration, and that no one else will ever be allowed to register for treacherous purposes, please take a look at the internet standards documents RFC 6761 (Special-Use Domain Names) and RFC 2606 (Reserved Top Level DNS Names).


It seems clear to me that the real problem is inventing your own domain names! I know that was very much the done thing in the past, but it was always a dumb idea, and remains so today. It’s really easy to avoid these kinds of problems – use a sub-domain of a public domain you own as the root for your AD etc..

An added bonus to using a subdomain of a real domain you actually own is that you can easily get certs without having to set up your own internal CA.


Mark Stockley wrote “WPAD is enabled by default on all Microsoft Windows operating systems and Internet Explorer browsers.”

It would have been a much more useful article if you stated how to disable WPAD on Windows and IE.


The following steps work for Windows 10:

Click the Windows logo on the bottom left corner and select Settings.
Select Network & Internet.
Select Proxy from the list on the left.
Make sure “Automatically Detect Settings” is disabled.
The following steps work for Windows XP, Windows Vista and Windows 7:

Click Start or the Windows logo and then find Control Panel.
In the control panel select Internet Options.
Go to the Connections tab and select LAN Settings.
Make sure “Automatically detect settings” is disabled.


@Laurence. You need to disable Proxy Automatic detection in IE connection settings. WPAD query will be block listed by Windows DNS Servers by default, you can check this by running this command “dnscmd /info /globalqueryblocklist”


On Windwos 10 (at least) Firefox and Chrome use system settings.

Control Panel – Internet Options – Connections or IE/Edge settings or press windows-key and type Proxy



The default DHCP domain setting of my D-Link DIR-615 wireless router is: “domain.example” and I didn’t change it. The Proxy Automatic detection is enabled in my Windows 10/IE settings.

I was not aware of the WPAD vulnerability until recently I found my proxy setting is somehow automatically set to “xxx.yy.z.qqq:8080″… Then I checked further and found someone registered wpad.domain.example and utilized it to auto set my proxy to a malicious proxy server (xxx.yy.z.qqq) in Spain…

Allowing someone to register something like wpad.domain.example looks a bad idea. These “wpad” domain names should be reserved.


I faced the same problem since couple of days. My router has set in the settings. I did ping wpad (fqdn is which is responding with malicious IP [REDACTED]. Fortunately, my antivirus is blocking this ip and url By the way, I never set auto proxy (automatically detect) in the LAN settings but still it was taking the above malicious ip to my surprise. Finally, I added an entry of wpad (and it’s fqdn) to localhost ( in hosts file and the problem is resolved.


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!