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