Disabling Web Proxy Auto Detect (WPAD) Correctly

The Web Proxy Auto Detect (WPAD) feature in Windows makes it easier to automatically discover proxy settings on the local network. However, since it is commonly abused in a variety of attacks, security hardening guides often instruct to disable WPAD entirely. If you're like most people, your first thought will be to open services.msc, look for something that looks like it ("WinHTTP Web Proxy Auto-Discovery Service"), and... fall right into a trap.

DO NOT DISABLE THE WPAD SERVICE! SOME WINDOWS COMPONENTS USING WINHTTP WILL BREAK!

It is very counter-intuitive, but in order to disable WPAD correctly, one needs to use a registry key, and leave the service running:

New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp' -Name DisableWpad -Value 1 -Force

Instead of using PowerShell, you can also download and import DisableWpad.reg to set the registry key. The end result should look like this:

You can also check the status of the service with PowerShell:

Get-Service WinHttpAutoProxySvc | Format-List -Property Status,Name,DisplayName

Status      : Running
Name        : WinHttpAutoProxySvc
DisplayName : WinHTTP Web Proxy Auto-Discovery Service

Disabling the WPAD service breaks some Windows components using WinHTTP. For instance, the KDC proxying client often used with RDP, the RD Gateway, or DirectAccess to make Kerberos work outside of the corporate network will just... silently fail, causing a fallback to NTLM. I found out the hard way that IT fell into that trap when hardening our systems, and wasted quite a lot of time researching why Kerberos wouldn't kick in. The WPAD service is also required for Windows Defender Application Guard (WDAG).

In both cases, the components don't care about WPAD - the problem is caused by WinHTTP APIs checking if the WPAD service is simply running.

this blog post is based on this twitter thread