Tutorial

Disable WPAD via GPO (Verified)

It turns out that most online documentation (including Microsoft's) about how to disable WPAD are actually incorrect. After discovering this and contacting MSRC, Microsoft updated their documentation to add a pretty important note.

Eddie Zhang

• 7 min read
Disable WPAD via GPO (Verified)

Just here for the story about the reporting this to MSRC? Skip to here.

To disable WPAD (Web Proxy Auto-Discovery), two (2) registry keys need to be set.

  • Target key 1: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
    • Create a REG_DWORD set to 1: DisableWpad
  • Target key 2: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
    • Create a REG_DWORD set to 0: AutoDetect
    • This key toggles the setting for "Automatically detect settings" under Windows Automatic proxy setup in Windows Settings.
    • NOTE: This is a volatile registry key which will disappear once applied - it operates on the following REG_BINARY: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections - DefaultConnectionSettings
    • You can instead opt to update the DefaultConnectionSettings registry key directly if you'd prefer that.

To set these keys via a GPO, we will need to create two (2) GPOs.

  • DisableWPADComputer
  • DisableWPADUser

As key one targets HKEY_LOCAL_MACHINE and the other targets HKEY_CURRENT_USER it's advisable to separate these into GPOs that apply to computer OUs and user OUs.

Note: It is technically possible to merge these two GPOs by applying both configurations to computer objects and using loopback processing. This has performance implications so it isn't recommended.

GPO 1 - DisableWPADComputer

To create GPOs which set registry keys you need to navigate to Computer/User Configuration -> Preferences -> Windows Settings -> Registry and create new registry items.

For our computer GPO we'll set the key which affects the HKLM hive.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

  • Create a REG_DWORD set to 1: DisableWpad

This GPO needs be applied to OUs where your computer objects live.

đź’ˇ
Prioritise rolling this GPO out to workstations first as they are more likely to be targeted by attacks that leverage WPAD.

GPO 2 - DisableWpadUser

Next we need to create a GPO which works on the HKCU hive.

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings

  • Create a REG_DWORD set to 0: AutoDetect

As this is a GPO which applies user configurations. It needs to be applied to an OU which contains your user objects.

The final GPO linking might look something like this:

Implementation Notes

  • Probably shouldn't need saying but disabling WPAD will mean you will need to manually configure any proxy servers you use.
  • Two (2) reboots are required for the GPO to be effective.
    • Computer policies are applied on boot, and the GPO only writes the registry key which doesn't get evaluated till a subsequent reboot.
  • Test as you would with rolling out any other GPO - use pilot groups/users.

Testing Methodology

Want a way to test that no more WPAD requests are being made?

Here's a simplified way to test it:

  1. Install Wireshark and start a packet capture for your network interface.
  2. Apply the packet filter dns.qry.name contains "wpad" .
  3. Disconnect (don't disable as it this will stop your packet capture) your network interface.
    1. For wireless network adapters, disconnect and reconnect to your SSID.
    2. For ethernet, unplug and plug the cable back in physically.
    3. For virtual machines, there's normally the capability to disconnect the adapter virtually.
  1. Upon reconnecting your network interface to the network, you should immediately see WPAD DNS requests being made if you haven't applied the registry keys.
đź’ˇ
The keen eyed among you might notice that we're only checking for the WPAD DNS request. During testing, I found that if you setup a malicious WPAD server and try to exploit it, the actual WPAD HTTP request would follow soon after.

This simplified testing method just means that those that don't want to setup the full attack chain can still validate the issue/remediation.

Here's what this looks like on a default install of Windows 11.

0:00
/0:14

WPAD key & Proxy setting unconfigured - Default

Finally, here's what things should look like if you've applied the registry keys correctly.

0:00
/0:23

WPAD key & Proxy setting configured - After GPO

The Report to MSRC

This all started with trying to write a helpful blog about how to disable WPAD.

Like many others, I initially turned to the internet to see how others were approaching this, and eventually relied on Microsoft’s own documentation. After all, who better to trust than the vendor, right?

According to their documentation prior to my reaching out to them, disabling WPAD was as simple as setting a specific registry key.

Web archive link.

Microsoft Documentation Pre-Update

I followed Microsoft’s instructions and set the registry key, thinking that would disable WPAD. Next, I ran a quick test to see if it worked.

0:00
/0:22

Only WPAD key configured

It doesn't work? I'm still seeing WPAD requests.

| Shoutout to Sam for helping me validate that I wasn't going insane.

To make things even more confusing. Using the same testing method on a Windows 10 1903 machine, the registry key actually worked. After setting it, WPAD requests stopped appearing.

Was this a regression? Not sure, let's just ask Microsoft.

Report Timeline

  • August 30: Report raised with MSRC to look into whether this WPAD key was a regression.
  • September 12: MSRC closed issue citing no immediate threat to customers - possible misunderstanding.
  • September 12: Updated public disclosure to 20 September.
  • September 17: MSRC reopened issue to reinvestigate case.
  • September 19: MSRC closed issue citing low risk but noted that they would update documentation.
  • September 19: Asked MSRC if they were able to reproduce the issue.
  • September 20-23: Documentation updated in git.
  • October 5: MSRC replied linking updated documentation.

It turns out at some point, something changed and their documentation was no longer correct.

Documentation Post Update

I wonder how many organisations think they've disabled WPAD but actually haven't as a result of the incorrect documentation.

Alternate Solutions

As I was fumbling around trying to disable WPAD, I also considered some of the other solutions but ultimately decided against recommending them.

Disable the WPAD Service

It's possible to disable the WinHttpAutoProxySvc altogether however there's lots of threads out there about the impacts of doing so including:

Applications straight up not launching and depending on this service.

Windows: cannot start if `WinHttpAutoProxySvc` is disabled · Issue #10215 · tailscale/tailscale
What is the issue? A user reports that 1.52 cannot start on machines at their location. Their site disables WinHttpAutoProxySvc as a security risk. They ask if we can check whether a service is dis…
GitHubtailscale

and thread exhaustion issues.

Microsoft Knowledge Base Archive
An unofficial Microsoft Knowledge Base archive which is intended to provide a reliable access to deleted content from Microsoft KB.
Microsoft Knowledge Base ArchiveVadims Podans

If you want to try this anyway the registry key to set is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc

    • Create a REG_DWORD set to 4: Start

Create a hosts File Entry for WPAD

This seems like a viable option but is difficult to recommend as a safe option for all environments.

By adding a line for WPAD into the hosts file on your computers you can ensure that malicious WPAD servers can never be resolved.

C:\Windows\System32\Drivers\etc\hosts

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#       127.0.0.1       localhost
#       ::1             localhost

255.255.255.255 wpad.

Microsoft has even previously suggested it as a workaround:

MS16-077: Security update for WPAD: June 14, 2016 - Microsoft Support
Resolves vulnerabilities in Windows that could allow elevation of privilege if the Web Proxy Auto Discovery (WPAD) protocol falls back to a vulnerable proxy discovery process on a target system.
Microsoft Support

Practically, if you have hosts in your environment that make use of their hosts file you can't simply create a GPO to replace the hosts file.

You'll need to use a script to evaluate what's currently configured and add the WPAD entry if it's not already there. Not impossible, but also not a very clean solution.

Why Disable WPAD (Short Version)

If you've gotten this far but aren't sure why you should disable WPAD then here's a extremely short write-up about that - this post is too long already.

There are two main attack scenarios we're worried about. If WPAD isn't disabled AND an attacker can convince your victim workstation that they are the WPAD server:

  1. An attacker can capture user credentials (hashes) from victim workstations with 0 interaction from the user.
  2. An attacker can act as a malicious web proxy and inspect unencrypted web traffic or otherwise perform MITM attacks.

In most cases, an attacker needs to be on the same network segment as your victim in order to leverage other techniques to convince your victim workstation that they are the WPAD server (e.g. https://github.com/dirkjanm/mitm6).