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.
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:
GET /wpad.dat HTTP/1.1Connection: Keep-AliveAccept: */*Host: 217.70.184.38HTTP/1.1 404 Not FoundServer: BaseHTTP/0.3
Python/2.6.6Content-type: text/htmlVary: HostContent-Length: 384Accept-Ranges: bytesDate: Wed, 27 Jun 2012 11:21:03
GMTAge: 0Via: 1.1 varnishConnection: close
404 Not Found
Not Found
Nothing matches the given URI
Strange. And all this behavior out of nowhere. I also ran a GMER scan which also came up 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.