Today I was playing with my Check Point NGX Lab at home (yes, people can have that in real life) when some funny connections got my attention (in a freaky way).
Do you see that huge amount of HTTP connections? <- This is a rethorical question, by the way.
All of them originate from my machine and connect to an IP address in the range 74.125.0.0/16. A quick whois query for this address shows the following result (surprise…)
carlos@dell:~$ whois 74.125.98.38[Querying whois.arin.net][whois.arin.net]## Query terms are ambiguous. The query is assumed to be:# “n 74.125.98.38″## Use “?” to get help.### The following results may also be obtained via:# http://whois.arin.net/rest/nets;q=74.125.98.38?showDetails=true&showARIN=false#NetRange: 74.125.0.0 – 74.125.255.255CIDR: 74.125.0.0/16OriginAS:NetName: GOOGLENetHandle: NET-74-125-0-0-1Parent: NET-74-0-0-0-0NetType: Direct AllocationNameServer: NS2.GOOGLE.COMNameServer: NS3.GOOGLE.COMNameServer: NS4.GOOGLE.COMNameServer: NS1.GOOGLE.COMRegDate: 2007-03-13Updated: 2007-05-22Ref: http://whois.arin.net/rest/net/NET-74-125-0-0-1OrgName: Google Inc.OrgId: GOGLAddress: 1600 Amphitheatre ParkwayCity: Mountain ViewStateProv: CAPostalCode: 94043Country: US[...]
WTF was this? Connecting to a registered Google IP address, it couldn’t be ordinary Malware… Google Malware? 
So it was time for Microsoft beloved Sysinternals Suite (I freaking love that software, VIVA Mark Russinovich!)
First at all, which process was initiating the connections?
TCPView showed that svchost, PID 1032 was doing this. Double WTF?
svchost.exe named “services host” is an skeleton for Windows services. Since these are implemented as DLLs and not complete executables, they need a harness to run. That’s why Process Explorer lists so many processes inside them.
At the time this happened the process GoogleUpdater.exe was hanging as well from this process tree. This was already a hint, I was actually on the right track but this process had a completely different PID. Thus it looked like, somehow, GoogleUpdater.exe was making use of any of these services to acomplish its task.
Time to check what the hell these small HTTP packets were. I downloaded Wireshark.
Before even download Wireshark completely, I got another clue. While the 17MB of the (beloved) packet analyzer were on its way, the quick flow of small HTTP packet decreased drastically, almost stopped. If this was some kind of malware it was a really polite one, because it looked like it was leaving the bandwidth available to my download…
Using the “Follow TCP Stream” feature of Wireshark (isn’t that just cool?) I got a good view of what was going on behind the stages…
The system was downloading small pieces of the Google Chrome installer (check the “375.125″ inside the URL). You can see in the HTTP response that it is actually an application/x-msdos-program of length 14285 bytes.
But the really interesting part is the User-Agent the systems is using in these HTTP requests: “Microsoft BITS/6.7″.
Going back to Process Explorer, we confirm that BITS is indeed one of the services hosted in that svchost.exe instance.
And this is what MSDN has to say about the BITS service:
Background Intelligent Transfer Service (BITS) transfers files (downloads or uploads) between a client and server and provides progress information related to the transfers. You can also download files from a peer.
The next time I opened Chrome and checked the version, this is what I (unsurprisingly) found:
Also, neither malware nor evil Google eavesdropping but enough to scare a chickenshit like me