Project Zero: Watch out for Web Proxy Auto-Discovery

Topic

New Reply

What is WPAD? Easy question, long answer. Google’s Project Zero just posted a scary evaluation: (With WPAD) every Windows machine will ask the local n
[See the full post at: Project Zero: Watch out for Web Proxy Auto-Discovery]

7 users thanked author for this post.

Lori, MrBrian, SueW, walker, Tiernan, davefox, AJNorth

Reply | Quote

Replies

The idea of keeping one computer off the Web (and the local network) except when necessary to update software is looking better every day.  Connection to the network isn’t needed to share one printer between two computers.

3 users thanked author for this post.

RamRod, Elly

Reply | Quote

They didn’t make it easy to disable system wide.

1 user thanked author for this post.

woody

Reply | Quote

https://www.howtogeek.com/298460/disable-wpad-in-windows-to-stay-safe-on-public-wi-fi-networks/

4 users thanked author for this post.

Lori, SueW, samak, davefox

Reply | Quote

From the original article:
The first one is the advice given by the howtogeek.com article.  That article deals with the possibility that a person can set up an open wifi network to have a malicious payload in what is supposed to be a proxy configuration file.  It’s possible that changing the setting as HTG.com suggests will stop this particular attack vector from working, but it’s not exactly the same thing that is being described in the Project Zero blog.

According to the Project Zero blog post, Windows does an “interesting” thing when hunting for the .js proxy config file.  If the local address is localmachine.us.division.company.com, it will attempt to retrieve the file from wpad.us.division.company.com, then wpad.division.company.com, then wpad.company.com… and then, incredibly, wpad.com.  Each of the first three queries were aimed at different places within the company.com second-level domain, but it iterates one time too many, sending the last request to a completely different second-level domain that is not within the local network at all.

Apparently, the issue was partly fixed some time ago, but only for computers whose localhost is on one of the most common US TLDs.  For those on country-specific TLDs, or any of the new weird ones we keep hearing about, like .ninja, it is possible that someone could have registered the URL in order to set up a malicious server to receive spurious proxy configuration requests from across the WAN and serve up a bit of .js malware.

Now, mitigation.  From the article:

Perhaps it would also work to set the Windows firewall or other packet filtering firewall (at the router level,  perhaps) of your choice to drop all such requests.  Modifying the hosts file is one of the first things that springs to mind, but apparently, that won’t be enough to completely block it.

Edit to remove HTML
Quotes in this post were not readable. Please convert to plain text before cut/pasts.

Reply | Quote

Something was messed up with the site when I wrote that (yes, another one posted anon by me, but this time I have a reason!).  It kept telling me “Unable to connect to database” or something similar when I tried to post a message or when I tried to sign in, and since it ended up posted anon (sign-in failed, I conclude), I could not see/ review the message and make sure it was as I wanted.  The only formatting was that which I used from the toolbar in this site’s text editor itself, which doesn’t persist in a copy/paste as I try it now.  Not the first time spurious HTML has appeared in one of my posts, but previously I had successfully signed in and was able to see the post and fix it.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

Reply | Quote

@ Ascaris

WPAD is enabled by default in Windows and IE/Edge. WPAD is disabled by default in nearly all other OS and browsers.

AFAIK, most Windows home-users do not need to setup a local network and proxy server to monitor and filter the Web-traffic of other users in the home = they should fully disable WPAD.

Companies and schools need to set up a local network and proxy server to monitor and filter the Web-traffic of their clients/students/users. This should be set up manually and not automatically via WPAD. …

The researchers recommended computer users disable the protocol. “No seriously, turn off WPAD!” one of their presentation slides said. “If you still need to use PAC files, turn off WPAD and configure an explicit URL for your PAC script; and serve it over HTTPS or from a local file.”

.
https://www.computerworld.com/article/3106070/security/disable-wpad-now-or-have-your-accounts-and-private-data-compromised.html

Reply | Quote

Hello there!

It seems that per the googleprojectzero discovery: “disabling WPAD” does Not work through some of the advices commonly found online to prevent the attack in their experiments.

They list 3 of them (copied here for your convenience):

> Turning off “Automatically detect settings” in Control Panel

> Setting “WpadOverride” registry key

> Putting “255.255.255.255 wpad” in the hosts file (this is going to stop the DNS variant but likely not the DHCP variant)

And that it seems to be, the only way to prevent this type of attack using new, currently unknown vulnerabilities (they explain they haven’t investigated every possibility): completely disabling the WinHttpAutoProxySvc service, and changing the corresponding registry entry’s “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc” value of “Start” from 3 (manual) to 4 (disabled) if this can’t be done in the Services UI.

Check the bottom of the article.

It may be useful to disable WPAD with these other ‘common’ advices, in other ways. I did the “Automatically detect settings” -off anyway.

– some chap

3 users thanked author for this post.

walker, SueW, Pepsiboy

Reply | Quote

anonymous #153122 said:
> Setting “WpadOverride” registry key

Different anon here. The said “WpadOverride” registry key recommended by GoogleProjectZero apparently refers to adding “WpadOverride = 1”  (DWORD) for the registry keys where “Wpad” exists (it may not, depending on one’s system), such as:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad
• HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad
• HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad

However, GoogleProjectZero’s advice will make things worse. It appears that the effect of adding “WpadOverride = 1” is the complete opposite of disabling WPAD.

Default Situation:
“WpadOverride’ registry value does not exist. Windows will stop trying to detect proxy settings via WPAD after one or a few failed attempts.

WpadOverride = 1:
Adding this registry value overrides the default situation as outlined above. In other words, this registry value tells Windows to ignore failed attempts & continue trying to detect proxy settings via WPAD — which is what we DO NOT want due to numerous security vulnerabilities (including harmful Javascript in malicious PAC files).

 

References:

[1] http://kb.k12usa.com/Knowledgebase/Proxy-Auto-Detect-WPAD-Issues-With-IE-Windows-7
Read the 1st para (titled “Summary”) carefully. “WpadOverride = 1” disables the “stop trying” function, so that WPAD works. But remember, we don’t want WPAD to work.

[2] http://blog.frankleonhardt.com/2011/wpad-and-windows-7-and-internet-explorer-8
This recommends that VPN users add “WpadOverride = 1” to the registry, so as to override the Windows feature that “stop checking for a WPAD server after a few failed attempts” (2nd para).

[3] https://stackoverflow.com/questions/15029615/how-to-turn-off-disable-web-proxy-auto-discovery-wpad-in-windows-server-2008/25366609#comment69297809_25366609
User flakshack said it best …

The WpadOverride key actually causes Windows to do WPAD requests more frequently. It’s pretty easy to pull up wireshark and filter on dns.qry.name contains “wpad” to verify that your suggested change does not disable it. The really sad part is that your answer has been quoted all over the Internet as the way of disabling WPAD (which can be a security vulnerability).

 

Reply | Quote

@anonymous:  It appears to me that those of us who are “totally computer illiterate” are “doomed”.     I don’t know one end from the other, and just want the computer to be “secure”, and with everything that has occurred during the (at least) 2 years it has only gotten worse.

Wish there were a “cure all” for something such as this which the average “Joe/Jane” users would never have need for, nor want.    No such luck, and that’s for certain.  Thank you for the information you have posted.   Hoping and praying that a “miracle” occurs one of these days with all of the miserable problems which keep occurring, and even becoming worse (if that’s possible!).   Thank you once again for the information.

Reply | Quote

It’s not immediately obvious, but the Project Zero Report does say that all of the bugs they found have been patched by Microsoft as of the December patches/updates. They cover themselves by saying that they can’t guarantee there are no other bugs, but at least for now – or once you install the December patches – you should be safe.

I suspect you have no desire to go into the registry, and neither do I, but I would suggest you also disable Wpad using the instructions in the ibtimes.co.uk link elsewhere in this thread. It’s very straightforward and you can do it through the Control Panel.

Also, as noted elsewhere on this thread, computers on your home network are probably quite safe unless one of them gets some malware that would enable a neer-do-well to gain access to one of your computers.

So, the way I see it, keep your antimalware up to date and also the patches/updates – subject to Woody’s MS-DefCon system – and you’re probably as safe as you can reasonably get without going into the registry or setting up blacklists on your firewall

1 user thanked author for this post.

walker

Reply | Quote

Reading the “Project Zero posting, with is salad of acronyms, prompts this question in plain words that is made in hopes of a like answer:

As probably many others following Woody’s, I have a  PC (Windows 7 Pro, Sp1, x64) connected to the Internet with modem/ISP fiber optic cable/the rest of the world, and my local network consists in one little WiFi/Ethernet modem, sitting in my living room. Sometimes I connect also my Mac via WiFi/modem/etc. The PC, only through Ethernet cable/modem/etc.

Am I very vulnerable to an attack via my “local network”, and is there something simple to be done to avoid that from happening?

Thank you.

Ex-Windows user (Win. 98, XP, 7); since mid-2017 using also macOS. Presently on Monterey 12.15 & sometimes running also Linux (Mint).

MacBook Pro circa mid-2015, 15" display, with 16GB 1600 GHz DDR3 RAM, 1 TB SSD, a Haswell architecture Intel CPU with 4 Cores and 8 Threads model i7-4870HQ @ 2.50GHz.
Intel Iris Pro GPU with Built-in Bus, VRAM 1.5 GB, Display 2880 x 1800 Retina, 24-Bit color.
macOS Monterey; browsers: Waterfox "Current", Vivaldi and (now and then) Chrome; security apps. Intego AV

Reply | Quote

As long as no infected computer/device is ever on your network you are good. If one of the other computer gets infected with a virus which is capable of lateral movement then you are not good.

1 user thanked author for this post.

OscarCP

Reply | Quote

Pardon my ignorance but why does my computer “need” to look across a network for javascripts at all?

4 users thanked author for this post.

Bill C., Charlie, Cybertooth, wdburt1

Reply | Quote

anonymous wrote:

https://www.howtogeek.com/298460/disable-wpad-in-windows-to-stay-safe-on-public-wi-fi-networks/

The solution in the above article for Windows 7,  unchecking “Automatically detect settings,” apparently does not work.  At least the authors of the Project Zero article, who only mention Windows 10, say that this did not prevent their attack (it’s right at the end of the article).

 

Reply | Quote

http://www.ibtimes.co.uk/how-disable-wpad-windows-so-hackers-cant-hijack-your-computer-1576111

2 users thanked author for this post.

samak, SueW

Reply | Quote

On review, I already disable this system wide as standard policy:

Disable:
iphlpsvc
WinHttpAutoProxySvc (windows 10 may protect this service for some unknown reason — no side effects so far)

set (in the hosts file):
255.255.255.255 wpad

Clear/block:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad
HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad
HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad

Reply | Quote

Is this a problem only if on uses Internet Explorer?

Would choosing, let’s say Firefox, instead as the default browser make any difference?

And if it does, how about the several bits and pieces of OS software that run IE in background without first asking the user for permission? Will they be just as happy running Firefox instead?

Ex-Windows user (Win. 98, XP, 7); since mid-2017 using also macOS. Presently on Monterey 12.15 & sometimes running also Linux (Mint).

MacBook Pro circa mid-2015, 15" display, with 16GB 1600 GHz DDR3 RAM, 1 TB SSD, a Haswell architecture Intel CPU with 4 Cores and 8 Threads model i7-4870HQ @ 2.50GHz.
Intel Iris Pro GPU with Built-in Bus, VRAM 1.5 GB, Display 2880 x 1800 Retina, 24-Bit color.
macOS Monterey; browsers: Waterfox "Current", Vivaldi and (now and then) Chrome; security apps. Intego AV

Reply | Quote

I have done some more reading about this, and it casts doubt on my previous post.  I haven’t gotten a complete picture of what this is about yet, but I wanted to post this update quickly, lest I inadvertently mislead anyone.

Since edit was no longer available as an option, I trashed my old message, but I will paste the entire text of it in here and make the edits inline.  The strikethrough portions are statements I made before that I question now, either in their accuracy or their relevance, with bolded comments added just now.

Oscar, that was one of my first questions too, but from what I gather from the article, using Firefox (or even having IE “uninstalled,” as you can sort-of do) won’t help. 

I am not sure about this now.  From the text of the original article, it says that the “operating system” requests the proxy information, but now I noticed that it says somewhere else that the “browser” requests the information.  The article also doesn’t list the obvious advice “don’t use IE or Edge” as a mitigation, and this is notable given that it’s Google making the statements… I’d think they’d be quick to point out that their own browser is better than someone else’s.

The culprit is the old jscript parser, which is a system component that (in addition to parsing the WPAD scripts) performed the script parsing for older versions of IE (and newer versions in compatibility mode).  Newer versions of IE can be made to call jscript.dll by means of IE’s compatibility mode, but there are other things that are not directly related to IE that can also call jscript.dll.  The WPAD function is one of those.

There’s no way to simply substitute Firefox’s Javascript parser for jscript.dll.  It seems to be another example of why the idea of merging the browser and the OS was a bad idea, but that ship sailed nearly 20 years ago when Windows 98 arrived, at least as far as Windows is concerned.

Still true, according to the original post, but I am not sure about the relevance to the question about FF being safer anymore.  The relevance of jscript.dll when using FF is an open question in my mind now.

If you need the auto-proxy configuration, that should stop the exploit if the WPAD server on your domain is working.  The client (your PC) will keep trying to find a WPAD server until it either finds one or when it runs out of hostnames to query, from what I gather, so if your WPAD function works, it will find that and stop looking before it ever gets to the point of searching for wpad.$tld (where $tld represents the top level domain, like com, net, or ninja).

It’s quite unlikely that a home user would ever need this function, though.  If you don’t need auto-proxy config, just turn the service off via the directions in this thread to mitigate the threat.

There seem to be three levels of issues that make this a problem in Windows.  First, that this feature is enabled by default, which is not the case with other operating systems (and such a potentially risky feature ought not to be on by default).  Second, it should not take disabling a service to turn this feature off; there should be a check box somewhere that does that (which the blog post says is not the case currently).  Third, Windows should never attempt to get a script from a site obviously unrelated to the domain to which the PC in question belongs. If you’re on us.ibm.com, it makes sense to look for wpad.us.ibm.com and wpad.ibm.com, but to try wpad.com is just absurd.

If this is something that can be mitigated by using another browser, I don’t see how it would be necessary to disable a Windows service.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

Reply | Quote

I had no trouble turning off the appropriate service in Windows 7 SP1 (64-bit).

I had no idea this service used J(ava)Script, let along unsandboxed JavaScript. I admit, I don’t see the point.

Reply | Quote

anonymous wrote:

I had no trouble turning off the appropriate service in Windows 7 SP1 (64-bit). I had no idea this service used J(ava)Script, let along unsandboxed JavaScript. I admit, I don’t see the point.

I did the registry change suggested in an earlier post. So far, no trouble with anything. My system is like yours, Win 7 SP1 x64. Waiting to see what happens over the next few days.

Dave

1 user thanked author for this post.

SueW

Reply | Quote

Well, any software running on the computer can do nasty things. Ever thought of that all routers have open ports returning details about setup (including user data) and connections to requests? Right, it’s an industry-wide practice and any software running on the computer may access those data. Of course, any other connected hardware may participate in those undocumented (at least, Microsoft won’t tell) activities as well.

So, think first before installing software or connecting anything to your computer. Most importantly, lock-down your firewall first! By default, ALL inbound traffic and ALL outbound ports other than 80/443 (HTTP/HTTPS) should be blocked. If you use e-mail, FTP, and the like, you’ll have to open related outbound ports as well.

Reply | Quote

I just reviewed my setup. On all Windows systems:

WinHTTP Web Proxy Auto Discovery Service – on Manual start since some time before 2010 and not running. I’ve just promoted it to Disabled status to be sure it doesn’t get started.

My DNS proxy server setup: It has been blacklisting wpad DNS resolutions for some time. Way back I noticed attempts to resolve things like wpad.carboni.lan going all the way out to Internet DNS servers and disallowed it.

Deny-by-default Sphinx Windows Firewall Control setup prevents any communications not previously specifically allowed by me. The nice part about this firewall setup is that it’s not just about ports but allows complete control over what specific programs can do what types of comms with what specific named Internet servers.

Most everything I can find not set to “auto” anything.

-Noel

Reply | Quote

Hi Noel

you mentioned Sphinx Windows Firewall Control many times here
with a trouble 2017 and seeing the great firewall protection you have
now I am actually keen to try it out
I recall you offer to share your config in one of the previous post
If you are willing, can you share it here again?
I am very keen to try it out in coming 2018
Thanks in advance and all your great advice here for the year

Back to fishing for better dreams
Nd60

Reply | Quote

Noel Carboni wrote:

WinHTTP Web Proxy Auto Discovery Service – on Manual start since some time before 2010 and not running. I’ve just promoted it to Disabled status to be sure it doesn’t get started.

Same with my Win 8.1 setup.  It was on Manual and not running; disabled now.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

Reply | Quote

A little confused here.

The Web articles from IBT and CW date from August 2016, and yet the Google guys publish their analysis in December 2017. So was this vulnerability known already, or not known? What of relevance to this issue has changed between 8/16 and 12/17?

Keep Running Windows 7 Safely for Years to Come  
Make Windows 10 look and work like Windows 7

Reply | Quote

I think the earlier articles sound the alarm about the possibility that malicious code could be delivered to computers (laptops, mainly) that connect to public wifi networks.  If the laptop in question is configured to seek out a WPAD config file, it could do so after the user connects to a public access point, thus subjecting him to arbitrary code that could be placed there by the operator of the access point, or by a miscreant lurking at a public access point looking to perform a MITM attack (though if this is successful, WPAD is far from the only source of danger to the hapless victim).

The new article from Google refers to the possibility that a person could get into trouble when his Windows PC tries to find a WPAD config file when connecting to a legitimate network (even his own, potentially), but because of an incorrect implementation of the function in Windows (and because the function is enabled by default in Windows, unlike other OSes), it can end up sending requests out across the internet to servers potentially set up to deliver malware to people under exactly that circumstance.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

1 user thanked author for this post.

Cybertooth

Reply | Quote

A simple question… However, it may not have a simple answer, but here goes. Does one who only allows one computer to connect to his router (i.e., just uses one computer on WiFi with no file/printer sharing, etc.) and does not use a proxy server need to be concerned about the Web Proxy Auto Discovery threat?

Also, in this scenario (described above), would disabling the Web Proxy Auto Discovery Service in Windows prevent one from using a third party proxy or VPN on an ad hoc basis?

I’m hoping someone can provide an authoritative response. Thank you.

Reply | Quote

Remember the Web Proxy Auto-Discovery vulnerability from last year?

I have some interesting info…

Back in December I had managed to quash all attempts by my systems to access wpad – Web Proxy Auto-Discovery – by deconfiguring the settings in Internet Options and disabling the “WinHTTP Web Proxy Auto-Discovery Service”.

All seemed well; thereafter I didn’t see even one attempt to resolve the name wpad in weeks.

Fast forward to yesterday… I discovered, coincidentally while watching DNS resolutions and reviewing logs, that about 10 days ago some component on my Windows 8.1 workstation has started again trying to resolve wpad. Repeatedly. Note the times in this log excerpt…

[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 ---
...
[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 ---

Fortunately last year I had also reconfigured my DNS proxy server (something that not many folks have) to block the resolution of wpad.anything, so the requests here never got outside my LAN (hence the “blacklisted” messages above).

But the fact that these entries are again being logged implies something Microsoft has done has usurped my attempts to stop wpad usage! What has caused my system to start attempting wpad access again?

I looked in my Application event log and I see that I had installed an update to Microsoft Visual Studio Community 2017 at 20:25 on January 9, coincidentally at just the time we see the wpad name resolution attempts start up again in the log. Visual Studio is known to be a cloud-integrated application, but what’s surprising is that even with the various system components deconfigured/disabled, it’s apparently either trying to find a web proxy server itself or has convinced Windows to do it in spite of my settings. I checked – the “WinHTTP Web Proxy Auto-Discovery Service” is still stopped and disabled.

I have been unable to find any additional settings, tweaks, or policies that will shut these new wpad access attempts down. However, there is a published technique – even suggested by Microsoft – that can block a system from attempting to contact a wpad server… You can put one or several entries in your hosts file that will block attempts to resolve the name of wpad (or wpad with your domain extension). This is what I put in my hosts file, and sure enough, the wpad.carboni.lan name resolution attempts have stopped.

# Disable Web Proxy Auto Discovery (inspired by MS16-073)

0.0.0.0  wpad
0.0.0.0  wpad.carboni.lan

The second entry is there because I know (from my DNS logs) that my systems tack my workgroup suffix on the end of names and make the attempt to resolve them. We sure as heck don’t want such name resolution requests going out to the wild internet. The ONLY thing that could possibly come of that is no good!

Because I had taken multiple steps to ensure no external attempt at wpad name resolution is possible (in this case, through my DNS blacklist configuration), my system remained secure. I have no idea what Visual Studio would do if it were able to resolve wpad to an address and get some data from a server, but I CAN say it works okay without doing so.

However, in the general case, if applications can start overriding the system and attempting their own wpad resolutions, my experience implies others’ systems could be making these attempts again even though they don’t want wpad accessed.

I don’t really know quite how to advise in general what other users who are SURE they don’t want wpad should put in their hosts file… The name is going to depend on the kind of networking they’ve set up and the suffix they’ve chosen for their workgroup. It’s possible that just the first entry I’ve listed above will do the job, or maybe one with a single dot following (e.g., “0.0.0.0 wpad.”)

If you want to add two entries as I have done, and you use Windows Workgroup networking, your “System” properties dialog is where you can see your workgroup name. You can see from my screen grab where my system has gotten the “.carboni.lan” suffix; notably it converted my workgroup name to lower case in constructing the wpad server name.

Note that the hosts file is notoriously difficult to edit – Microsoft throws a number of roadblocks in your way, presumably in the name of security (and somehow they just KNOW we can’t do it right). I think they even have Windows Defender consider changes to hosts potentially malicious. But it can be altered to add this extra level of protection if you’re careful and persistent.

-Noel

2 users thanked author for this post.

Cascadian, MrBrian

Reply | Quote