Jump to content

hxxp://wpad.domain.name/wpad.dat


Recommended Posts

  • Administrators

I'm sorry but we do not provide support to those with misused / leaked licenses. The license you use was overused and canceled.

Link to comment
Share on other sites

We are facing almost same problem from yesterday.

running any application using internet cause blocking connection. what is realy strange to me that it points to same IP like original post.

 

Link to comment
Share on other sites

13 hours ago, JanBar said:

We are facing almost same problem from yesterday.

running any application using internet cause blocking connection. what is realy strange to me that it points to same IP like original post.

 

Appears Eset is detecting an infected BGP server performing WPAD "man-in-the-middle" interception activities.

It so happens that the IP address shown references a server in Prague. This might explain why your Internet traffic is being blocked since I assume being located in the Czech Republic, regional Internet network traffic is being routed through this server.

You can try to set your browser network settings to use "no proxy" which is a recommended mitigation for this type of WPAD attack. You also need to inform your ISP of this activity so that they can investigate on their end what is the status of this server.

Link to comment
Share on other sites

14 hours ago, JanBar said:

no proxy is set and winhttpautoproxysvc is completely disabled

but the problem persist 😞

In Win 10, make sure below highlighted setting is set to "off":

Eset_Proxy.thumb.png.1e9e6098ed0d547a2ed7158221045534.png

Link to comment
Share on other sites

sure i did, this setting is set to off. But in WIN 10, this settings doesnt stop the service itself

you can check it by type "sc query winhttpautoproxysvc"

so i disable also the service

Link to comment
Share on other sites

Refer to this posting:  https://www.reddit.com/r/networking/comments/732r5n/anybody_else_having_issues_with_wpaddomainname/ . Although its 4 years old, it still appears applicable since the same three OVH French servers are still currently being used in the wpad.domain.name configuration file.

Again, its your ISP's responsibility to ensure you're not being routed to this domain. You need to contact them about this. If they ignore you, find a different ISP provider. If you're using ISP provided DNS servers, switch to using Google, Clouldfare, etc. and see if that eliminates the issue.

Also, note that Microsoft does not recommend that the winhttpautoproxysvc be disabled.

Edited by itman
Link to comment
Share on other sites

Hacking of the router is possible. As a solution, you need to go to the router settings and change the domain name from domain.name to my.router (as an example, or another non-existent domain name).

 

Quote

SQx: It turns out that this domain name is real, and it contains intangible settings that Windows 7/10 automatically picks up, hxxp://185.38.111.1/wpad.dat or hxxp://wpad.domain.name/wpad.dat

Rostelecom_1.png.804a2c870beb4f955e67403

Link to comment
Share on other sites

5 hours ago, safety said:

Hacking of the router is possible. As a solution, you need to go to the router settings and change the domain name from domain.name to my.router (as an example, or another non-existent domain name).

On ISP provided routers that setting wouldn't exist. If would take the form of DNS suffix that would be stored internally in the router and is not user modifiable. As such, I can't see how it could be hacked. I would reset the router and see if that resolves the issue.

However, DCHP domain is stored in Win registry Tcpip settings per below screen shot. It is possible this setting was hacked. However, I believe this setting is refreshed each time system restarts.  But not in the case of Win 10 fast startup mode I believe.

Eset_WPAD.thumb.png.ad438b773717e77c9b51e6c37dcbf627.png

Edited by itman
Link to comment
Share on other sites

Another thing that can be tried is to perform a full Win 10 network reset. See below screen shot. Note carefully what this does and that VPN software, etc.. might have to be reinstalled. Also, you will have no network connectivity for 5 mins. while Windows is setting up the network for a reset.

If this doesn't solve the wpad issue, it is happening external to Windows; either by the router or your ISP network. Also if this solves the issue but it reappears later, this would imply that it is installed malware related.

Eset_Reset.png.d5a3408a1670dc145c67b8cf47c18e43.png

Link to comment
Share on other sites

I did come across the Google ProjectZero article that recommended that winhttpautoproxysvc  service be disabled: https://googleprojectzero.blogspot.com/2017/12/apacolypse-now-exploiting-windows-10-in_18.html . BTW - this was patched by Microsoft.

At the same time I found this later dated router vulnerability advisory that also might be worth exploring:

Quote

The Web Proxy Automatic Discovery (WPAD) protocol is used to automatically provide proxy configuration information to devices on a network. Clients issue a special DHCP request to obtain the information for the proxy configuration, but will fall back on a DNS request to one of several standardized URLs making use of the subdomain name of “wpad” if a DHCP response is unavailable.

An attacker with local area network (LAN) access may be able to add a device with the name “wpad” to the network, which may produce a collision with a standardized WPAD DNS name. Many customer premise home/office routers (including, but not limited to, Google Wifi and Ubiquiti UniFi) automatically register device names as DNS A records on the LAN, which may allow an attacker to utilize a specially named and configured device to act as a WPAD proxy configuration server. The attacker-served proxy configuration can result in the loss of confidentiality and integrity of any network activity by any device that utilizes WPAD.

https://www.kb.cert.org/vuls/id/598349

Of note is the recommended mitigation for this is:

Quote

Home/office LAN/WLAN routers should not auto-register to their local DNS magic names related to auto-configuration and auto-discovery features should not accept mDNS based names as authoritative sources.

Apply the vendor patch.

Edited by itman
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...