Please help with this outbound connection problem...

I'm at wits end here. Since yesterday whenever I connect to my router (via Ethernet) svchost tries to connect to some obscure IP. 217.70.184.38. The previous night it never did this and I've not installed anything new, my defense+ and firewall have both been on permanently.

Some of it seems to be IPV6 traffic? Strange, some sort of IPV4 tunneling possibly? Also, ignore 213.199.181.90, I'm just blocking Microsoft.

Anyway, I did multiple malware scans (malwarebytes, spybot, super-antispyware, Dr. Web) and never found a thing. I also re-imaged my entire system HDD to 3 weeks ago, but the exact same behavior occurs (And it never did so previously). So time to dig deeper...

Using TCP View I found the Svchost process attempting the connection. I then moved on to Process Monitor to track the PID and found that the service NIS (Network Store Interface Service) is initiating the connection.

So that doesn't help much.

DNS lookups seems to direct me to webredir.vip.gandi.net.

So I fired up Wireshark. Following the TCP traffic to that address gives me the following string:

Going to that domain just results in a parked page, probably something normal (to do with WPAD?). But the link to see info on the parked domain reveals that it was registered on the 26 - just when I started receiving these problems??

Attached are screenshots from Process Monitor and my Comodo firewall log. Also, I'm on Windows 7 64bit SP1.

 

UPDATE: I just gave up and eventually allowed the connection. This gave me some interesting info from Wireshark. I followed the TCP packets to find that it seems Svchost is issuing a WPAD request to 217.70.184.38/wpad.dat. It tries to GET this DAT file but fails. The full output was:

Strange. And all this behavior out of nowhere. I also ran a GMER scan which also came up clean!

 

I don't think that this is good at all. A few months ago (Feb-March this year) a few of our clients also had a similar problem to yours, SVCHOST connections to gandi,net (a legit French provider, btw). However as we determined that these connections shouldn't be, it was apparent that some spoofing or obfuscation was being used.

Sure enough these computers were found to be part of a Botnet. Detecting a botnet can be easy or very hard depending (really helpful). Sadly most of the good stuff is UNIX only, but for Windows you can try Trend Micro's RUBotted.

http://downloadcenter.trendmicro.com/index.php?regs=NABU&clk=latest&clkval=1777&lang_loc=1

When that fails try Esmisoft:

http://www.emsisoft.com/en/software/eek/


Let us know how it goes.

 

Thanks for the reply. I ran RUBotted but it never detected anything. Esmisoft is a bit large for my connection so I'll download it a little later.

I loaded up my VirtualBox and found that Comodo is doing the same thing in there, which means that it probably isn't malware?

I also reset my router and flashed the firmware in case something is trying to feed me the WPAD through the DCHP or something, but the connections persist.

 

Some time ago Sparviero wrote to similar user problems, similar phenomena as in MITM attack (man-in-the-middle attack). Read and proceed as described here; https://www.wilderssecurity.com/showthread.php?t=273557&page=3

 

proCo- unless you have a dedicated program checking on escargot futures in Paris there is something not quite right occurring.Also rule Comodo out. They (to the best of my knowledge) do not use gandi.net's cloud.

 

I'm not sure as to how similar this is. It may be related but it's hard to tell. Something is causing the NSI service in my svchost to request a WPAD file from 217.70.184.38, which doesn't exist!

If it is malware then it sure as hell evaded detection for a long time!

 

I'm leaning towards there being something buried deep in my system, possibly in the MBR? A bootable scan might be my next attempt as all of the windows scanners come back clean.

 

I've fixed the problem! And as I suspected, it isn't malware (after 7 different scans I can confirm that)! Instead it's a case of unintentional spoofing. It looked very much like a man-in-the-middle attack but it wasn't quite there yet...

Here's what happened: My router, a Trendnet TEW-658BRM, places my local network on the default domain "domain.name". When Windows attempted to look for the WPAD file (in case it needs to make use of a proxy to connect to the internet) it contacted my router at that domain (the request would have been wpad.domain.name/wpad.dat). The router can't provide the WPAD file and usually this wouldn't be a problem as the WPAD request wouldn't translate into a real URL outside of the network, but in my case it did. If you visit http://wpad.domain.name you'll notice that it redirects you to a parked page provided by gandi.net. Whois reveals that this domain was registered on the 26 June - the same time the connections begun appearing in my firewall logs. Those connection were to gandi.net. From that date onward whenever my router received the request for a WPAD file it did a check and discovered the domain wpad.domain.name on the internet and so forwarded the request to that server. Obviously no WPAD file actually exists there and as such I picked up the Error 404 for the WPAD HTTP GET request in Wireshark.

The solution was to change my local domain to something that couldn't be resolved outside of the network (something like mylocaldomain.domainname). Changing it back to domain.name results in the connections once again occurring, proving that it was the problem.

On another note, this person who registered wpad.domain.name may be attempting to spoof connections that belong to the default domain of domain.name. At the moment the page is parked and no real wpad file is resolved, but if that changes then gandi.net should be notified.

 

I'm not sure

Let 'accept that miracles do happen and you have a request to this connection - wpad.domain.name = 217.70.184.38, the reason is as you described above?

How I do not believe in miracles, noticed that you have this connection attempt - webredir.vip.gandi.net = 217.70.184.38, that has nothing to do with your above written explanation.

- something or someone must write the request for this two connection.
- the first thing I would suggest, move "comodoko" or better format/c.

 

I've reimaged my system drive to 2 months ago, and I've also tested this in a clean virtual machine. I've scanned boot sectors. This is as good, if not better than, a format. Format will result in the same behavior.

webredir.vip.gandi.net is a result of the parked domain. The correlation between the IPs being served by Gandi is enough proof. The winHTTP service, which also handles WPAD configuration, made the request which was then routed outside my network because of the recently registered domain. Switching my network domain back to "domain.name" results in the behavior starting up immediately. It's not intermittent, it's solid.

 

- do as you think it's best for you, I wish you much luck.

 

Here is the traceroute to wpad.domain.name.

I hope that answers to your original concern. It isn't two connections, just one. And the domain wpad.domain.name is eventually redirected (as per traceroute above) to webredir.vip.gandi.net. This is the parked page hosted on gandi.net. The IP is owned by gandi, the domain, wpad.domain.name, has been registered by someone else on gandi who doesn't have hosting or his/her own server as yet. Thus the returned 404 for WPAD requests to this domain.

And if anyone thinks that my router was attacked as to cause my network to join domain.name, think again. I've reset and flashed the firmware, the default domain is domain.name. I haven't had any connections since changing this default network domain to something that can't be resolved on the WWW.

Edit: Also note this confirmation of Windows 7 attempting to obtain a WPAD file without any browsers open: http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/74bdc3e7-fc0b-4848-9211-47a77061e263/ (this would be the "something" requesting the WPAD file)

And this from wikipedia (http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol):

The domain in the above example is example.com. My domain was domain.name. If you look at the third attempted URL you will notice that in my case it would resolve to wpad.domain.name/wpad.dat. This is the exact request I traced in wireshark. The router just passes that request on to the WWW, as explained in my original past. But just to clear things up, here are two scenarios that have occurred:

When the domain wpad.domain.name never resolved to anything:
- Windows requested a wpad file at wpad.domain.name (which, in a large network using proxies, the server wpad exists on domain.name and returns proxy configuration settings in wpad.dat)
- DNS says wpad.domain.name doesn't resolve to any IP.
- Nothing happens.

After wpad.domain.name was registered (26 June):
- Windows requested a wpad file at wpad.domain.name
- DNS returns IP as this domain now suddenly exists. Router passes this request through to the IP.
- My firewall detects an outbound connection as the supposed-to-be internal network domain is routed through to the resolved IP
- If the connection is allowed, the HTTP GET request is sent for wpad.dat at the gandi parked page IP. HTML with an Error 404 message (note: Not a true WPAD java script file) is returned from the gandi servers as no site is hosted there (as yet).

If you read further on the Wikipedia article, you will come across the security section. You can read that for further insight into the problem.

Edit 2: Reading patch information on the Microsoft site reveals that Windows will stop at the third-level domain (i.e. wpad.example.com) as anything beyond that (i.e. wpad.com) will resolve to outside the internal network and cannot be trusted. This would be all fine if my routers default didn't actually contain a TLD (.name) that actually existed!

And to top all this up, if someone was trying to "hack" me using a proxy server for a man-in-the-middle attack then the address would contain a real proxy configuration file (wpad.dat), which it doesn't (just a 404 error)! Not that someone isn't planning on using this domain for future spoofing of innocent people unknowingly belonging to the domain.name network domain.

 

WPAD (Web Proxy Auto Discovery) is a method used by web clients to automatically locate a browser configuration file used to connect through proxy.

Successful attack on WPAD guarantees attackers full access on user data sent to Internet which could allow stealing critical data like passwords or credit card numbers. WPAD potential danger depends on two factors: default configuration and weak awareness among users.

A man-in-the-middle attack vulnerability exists in DNS servers where dynamic update is used and ISATAP and WPAD are not already registered in DNS. This vulnerability could allow a remote authenticated attacker to spoof a web proxy thereby redirect Internet traffic to an address of the attacker's choice.

Download wpadcheck from;

http://packetstormsecurity.org/files/download/77950/wpadcheck_en.zip

and checks for potentially dangerous entries in WINS server or DNS zone.

-in this short video can you seen as the "miracles" happen, man in the middle web attacks using WPAD.

-http://auditcasts.com/videos/mov/videos/17/Man-in-the-Middle-with-WPAD.mov-

 

Just an update: Gandi.net shutdown that domain name. It no longer resolves. This means that it probably was being set-up to perform man-in-the-middle attacks, but as I noted, was not yet associated with a real server (only a parked page). No WPAD attacks were yet performed with this specific domain.

Although I fixed this vulnerability on my own network (also confirmed with Wireshark packet tracer) I am happy that others with similar problems are protected from this specific attacker (as long as Gandi keeps the domain). Although it would be best for them to change the default network domain on their own routers, this is still an appropriate fix from a grander perspective.

 

To prevent any future wpad connection, enter in your HOSTS file one of these lines 127.0.0.1 wpad or 0.0.0.0 wpad