Strange outgoing connection for WPAD?

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. I'm using Comodo and my defense+ and firewall have both been on permanently. Windows 7 64bit SP1.

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, Gmer) 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.

So I fired up Wireshark. Following the TCP traffic I originally got nothing, but then I gave up and decided to let the connection through. Managed to follow those packets and I got:

And this is supposed to be hosted at 217.70.184.38/wpad.dat. Going to this page results in a 404 error just as seen in the HTML from wireshark.

Attached are screenshots from Process Monitor and my Comodo firewall log. Any ideas?

 

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.

 

Nice investigative work. Cheers on figuring it out and the warning.

The domain seems to be down now, possibly as a way to deal with this exact issue.

What router was it?