disable wpad DNS querys completly
Question
Wednesday, July 20, 2011 5:59 PM | 1 vote
Hi forum,
My platform is W2k8 with IE8. I want completly disable wpad.domain.com DNS queries cause my enviroment is not using any proxy. I tried:
- disable "automatically detect network settings" with GPO within IE lansettings
- disable "use automatic configuraiton script" with GPO within IE lansettings
- removed and disabled proxy server settings
- stopped and disabled "WebDav Client Redirector Driver service", "WinHTTP Web Proxy Auto-Discovery Service", "webclient"
"Netsh winhttp show proxy" tells me "Direct access (no proxy server)." but when a user is logging on to the server i see wpad queryies and http connects to wpad server with wireshark.
Any hints?
Best Regards,
Andreas
All replies (18)
Friday, July 29, 2011 3:29 AM ✅Answered
Hi,
Please check if there is 252 option on DHCP server. Please also check if there is a WPAD record on your DNS server. If there are, please remove them.
Regards,
Scott Xie
Thursday, August 4, 2011 6:34 AM ✅Answered
Hi !
Check all GP policy for Internet Explorer and remove clear "Automatically detect settings" then goto on yours DHCP server and check client and server options on DHCP server and try to find WPAD or 252 Code, if exist WPAD or 252 Code then remove it.
Best Regards
Thursday, July 21, 2011 4:20 AM | 3 votes
Hi,
Please double check the following troubleshooting steps:
1. Uncheck “Automatically detect settings” of Local Area Network (LAN) Settings in Internet Options.
2. Disable the service “WinHTTP Web Proxy Auto-Discovery Service” in Services.
3. Disable devolution by setting UseDomainNameDevolution value under the following registry entry to 0 (FALSE):
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
Regards,
Forum Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com .
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Thursday, July 21, 2011 2:59 PM | 1 vote
doublechecked, but issue still exists.
Regards,
Andreas
Thursday, August 4, 2011 6:07 AM
Hi,
I would like to confirm what is the current situation? If there is anything that I can do for you, please do not hesitate to let me know, and I will be happy to help.
Regards,
Arthur Li
Forum Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Saturday, September 5, 2015 3:53 AM
Did you ever figure this out? I have done all the above, yet my clients still query for wpad on bootup and random times throughout the day.
Wednesday, December 2, 2015 1:58 PM | 4 votes
I would like to know two, we have the same issue, have gone as far as disabling NETBIOS entirely but this gave to many issues, it will just switch on newer machines to LLMNR and start broadcasting the same with that protocol, changed the node-types, tried to change IP-stack settings to combat it, there is no easy way to stop this. It will just go on, in the end i just enabled WPAD in our DNS and created a fake machine with the name WPAD, it did stop the msg, but it is incredible annoying there is no simple option and all the options above mentioned are actually useless.
We are working with many different platforms at once and this is just a very small part of the current broadcast traffic, but somehow it is the only one visually present everywhere during monitoring.
Please give us a easy register hack to close this rather dangerous security leak once and for all.
Wednesday, September 7, 2016 3:46 PM | 1 vote
Hi,
In light of this PoC https://room362.com/post/2016/snagging-creds-from-locked-machines/ I would like to completely disable any WPAD probe from any of our workstations, under any circumstances.
Your answer seems to imply that whatever you turn off in GPO is irrelevant when an arbitrary rogue DHCP server (as in the PoC) offers up option 252. Is that correct?
How do I prevent a random person with $55 of hardware getting the hashes out of a locked system in 15 seconds? Is it possible to completely kill WPAD domain-wide through GPO?
Monday, October 31, 2016 9:08 PM
Did anyone come up with an answer? I have set the numerous recommendations (disabled "WinHTTP Web Proxy Auto-Discovery Service", uncheck "automatically detect network settings", set the WpadOverride key to 1) and using the Network Monitor, I still see checks for wpad. I do not have Option 252 configured and there is no DNS entry wpad.
Any advice would be greatly appreciated!
Monday, October 31, 2016 10:31 PM | 1 vote
These articles contain some useful references and workarounds
https://technet.microsoft.com/en-us/library/security/MS16-077
(Stop WPAD using a host file entry)
https://support.microsoft.com/en-au/kb/3165191
Don [doesn't work for MSFT, and they're probably glad about that ;]
Monday, December 19, 2016 12:20 AM
Arthur Li: I will explain it to you, please read my entire post before replying with a boilerplate answer.
The situation is that anyone with $55 of hardware and physical access can dump the password hashes from a workstation running Windows (whether on or off).
This STILL works and will work even if the drives are protected with Bitlocker(!). If the workstation only uses a TPM to unlock the (boot) drive(s), the password hashes can be dumped regardless of whether it's off or on (because the attacker could just turn it on). If the workstation uses any other means of unlocking the drive(s) then this method can be employed only when the workstation is on.
Once the hashes are brute-forced offline the attacker can return and will have log-on access to the workstation (and whatever else...), including to all unlocked Bitlocker encrypted disks (and the ones that were locked with the same password as used to log-on). Additionally the attacker may gain remote access to the same data if the account allows network access.
If a Domain Admin had logged on to the workstation in the past, potentially the attacker has access to everything in the domain (including the EFS and Bitlocker recovery agents if in someone's or some server's store).
You can see the method at: https://room362.com/post/2016/snagging-creds-from-locked-machines/
This is an *unacceptable* risk to many, especially when auto configuration of proxies is neither implemented nor wanted. We wish to make this method of attack impossible on our workstations/networks.
What I (and others here) want to know exactly:
How do we completely disable *all* WPAD (and similar) functionality? How do I leverage Group Policy to configure all our workstations and servers to:
1/ to NEVER to query for any WPAD-related DNS record under any circumstances, ever again. The DNS server the client queries may be a *rogue* one provided in a DHCPOFFER from an also *rogue* DHCP server, and thus not under our control. No WPAD lookups initiated whatsoever. None!
2/ to IGNORE any option 252 (and preferably any other option that provides proxy auto configuration settings) it may receive from a legitimate or *rogue* DHCP server (the client won't know the difference!). Just IGNORE it completely.
3/ to not attempt ANY automatic configuration of proxy servers by retrieving external data to use as local configuration of proxies to use, whether through DNS query, HTTP download of a file, carrier pigeon or whatever. Just NOT make any attempt to!
This concerns the configuration of the workstations in the network only: The complete deactivation of automatic configuration of proxies, specifically WPAD. How the legitimate DNS or DHCP servers are configured in the network is completely *irrelevant* (since the attack makes use of its own DHCP server that we do NOT control, and that rogue DHCP server may provide an, also rogue, DNS server to the client.).
We want to nuke all proxy "auto configuration", and specifically WPAD functionality, from our workstations. Please tell us how we do this using Group Policy. Thank you in advance!
Monday, December 19, 2016 8:05 PM
@raphidae
This thread is quite old (started in 2011), and Arthur_Li's response is also quite old.
Arthur_Li seems to no longer be active on these forums (so a response from him is unlikely).
Did you consider the suggestion/reference I made earlier? (Workaround: create dummy local hosts entry)
https://technet.microsoft.com/en-us/library/security/ms16-077#Anchor_3
I think your request is valid and reasonable but I'm not aware of existing GP settings which can achieve your goal (since GP settings are merely a way to apply configurations to Windows, but, Windows must offer the ability, and in this case, I don't think that Windows offers this ability, or if it does offer the ability, I have been unable to find formal/public documentation of that)
Don [doesn't work for MSFT, and they're probably glad about that ;]
Tuesday, December 20, 2016 2:24 PM
It would be nice if Microsoft would come up with a reasonable method to turn off WPAD from even querying. It is pretty sad in today's day that they would recommend using a HOST file, instead of having a reg key and/or GPO to turn off this option. Yes, I could probably push out a HOST file via GPO, but the fundamental is that it is still querying. I have absolution no need for this feature and since it can be used to compromise a system, they should address it from that prospective and allow you to turn it off completely
Friday, May 26, 2017 12:02 PM
An new facts about the WPAD crap?
Tuesday, August 1, 2017 11:54 PM
This problem still exists. I cannot seem to turn it off. This is real security issue.
Monday, October 2, 2017 3:37 PM | 2 votes
I have found that added 255.255.255.255 wpad to the host file stops this from being broadcast. The article below has more information and also points to a MS article suggesting this is a workaround
Monday, January 22, 2018 3:49 PM
Dredging up this old thread...
In mid December 2017 I had managed to eliminate the attempts to resolve wpad (with my LAN domain's extension) by doing the various things suggested online (disabling the service, etc.), and I had not one attempt in a whole month. Then upon installing the Internet Explorer Windows Update (and ONLY that update) from January 2018 suddenly I see it trying wpad again - initially a few times then every 20 minutes thereafter.
Fortunately I had also coded an entry into our DNS server to block any attempt to resolve wpad, so they are not getting outside our secure LAN.
[18-Dec-17 08:22:11] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[18-Dec-17 08:43:26] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[09-Jan-18 20:24:38] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[10-Jan-18 12:52:41] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[10-Jan-18 18:45:06] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[12-Jan-18 07:44:16] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[12-Jan-18 07:45:31] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[12-Jan-18 08:05:31] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[12-Jan-18 08:25:31] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[12-Jan-18 08:45:31] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[12-Jan-18 09:05:31] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[12-Jan-18 09:25:31] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[12-Jan-18 09:45:31] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[12-Jan-18 10:05:31] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[12-Jan-18 10:25:31] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[12-Jan-18 10:45:31] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[12-Jan-18 11:05:31] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[12-Jan-18 11:25:31] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
...
[22-Jan-18 06:25:29] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[22-Jan-18 06:45:29] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[22-Jan-18 07:05:29] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[22-Jan-18 07:25:29] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[22-Jan-18 07:45:29] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[22-Jan-18 08:05:29] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[22-Jan-18 08:25:29] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[22-Jan-18 08:45:29] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[22-Jan-18 09:05:29] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
[22-Jan-18 09:25:29] Client 192.168.2.32, wpad.carboni.lan A not found blacklisted by DNS proxy
What strikes me here is that even in light of Microsoft's recent acknowledgement of the Windows Proxy Auto Discovery vulnerabilities they have added something back in to Internet Explorer that tries to access Windows Proxy Auto Discovery - again.
I've just added the hosts file workaround, which quells any attempts to resolve wpad getting to the DNS server, but...
**Where is the configuration option? Those who don't need this functionality shouldn't have to add a hosts file workaround to shut these attempts down! What's running that we don't need/want running?
**
-Noel
Detailed how-to in my eBooks: |
Configure The Windows 7 "To Work" Options |
Sunday, January 28, 2018 8:26 PM
@Noel,
is 'WinHttpAutoProxySvc' running ?
If so, stop that service and set it back to Disabled?
Maybe the January CU has removed any previous config you applied (to stop/disable that service)?
Don [doesn't work for MSFT, and they're probably glad about that ;]