Thanks for sharing IPNetInfo and Fastresolver. I find these two apps very useful!
Sorry, clumsy me! The thing is I was quite scared about this problem and wanted to say so much in few words… And I thought I mentioned about svchost in the first place… I must of wrote but then delete it.
The thing with svchost is that when the system starts (after I log in on my account), after a few minutes I usually see [in the firewall active connections] a new row for svchost having as destination IP the one with 81.x.x.186 or in some rare cases 81.x.x.144 but in most part is the first one… This connection doesn’t last long. It transfers 66 B IN and about ~1.5 KB OUT and then… it goes away.
And yes, I do use Microsoft Office Click-to-go… I think it was preinstalled. All I did was to… launch it and was all to go. The weird thing was a new drive in my computer. It has the letter Q and it can’t be accessed but sometimes the firewall alerts me about this office pack. I think it’s because the program is a free edition and uses some ADS.
Now… I made a screenshot for wireshark when I allowed the connection between explorer and that IP so I can see what’s happening. I attached the image bellow and next to it is the log saved from wireshark (don’t know if this helps…).
First I thought I got it right. I tried to understand what those infos mean but all I managed to translate is: somehow that IP has to do with akamai.net which according to some articles found on google, akamai has something to do with internet content caching… whatever that is. It seems that it helps users improving page rendering or something like this. Probably this was correct, my mistake was to filter a different IP by a typo…
So… for the right and strange IP… I think it has something to do with this crl.microsoft.com/pki/crl/products/MicCodSigPCA_08-31-2010.crl
Ok, I’ve done some more research. First… to make some light for the first case which I messed up. That akamai thing can be seen if you ping crl.microsoft.com and the IP address for the akamai full dns is 81.x.x.184 and 81.x.x.144 (first I got the 184 ip then on the next ping I got the 144 one… don’t know why). Also, the akamai dns I’m talking about is a1363.g.akamai.net
Now… about that crl.microsoft.com
I’ve seen this on most of the entries from those IPs in wireshark at Transmission Control Protocol > Hypertext Transfer Protocol. All of them are using the GET method to pull up something like…
GET /pki/crl/products/CSPCA.crl HTTP/1.1\r\n GET /pki/crl/products/MicrosoftRootAuthority.crl HTTP/1.1\r\n GET /pki/crl/products/MicWinHarComPCA_2010-11-01.crl HTTP/1.1\r\n GET /pki/crl/products/microsoftrootcert.crl HTTP/1.1\r\n GET /pki/crl/products/CSPCA.crl HTTP/1.1\r\n GET /pki/crl/products/CodeSigPCA.crl HTTP/1.1\r\n GET /pki/crl/products/WinPCA.crl HTTP/1.1\r\n
All these are happening at the system start when svchost.exe is making the connection.
Google gave me some answers but don’t know for sure… Those crl files are some king of certificates and what svchost does is to check if the system is genuine and something about the office-to-go pack. I attached a screenshot (wiresharkpart2.png) with all the connections made by svchost at startup and the ping request for crl.microsoft.com in a text file. And finally the last screenshot (wiresharkpart3.png) has all the connections made with those IPs in about 30 minutes.
What do you think?
[attachment deleted by admin]