svchost.exe tries to connect to this two addresses which belong to Telezug AG:
212.4.67.72
212.4.67.74
See attached image.
I cannot see any reason for which svchost.exe should try to connect to those addresses.
My system is Windows XP with all the latest service packs and updates.
Should I be worried about a rootkit ? Any help is appreciated.
[attachment deleted by admin]
A Whois query gives us the following information for the IP addresses:
IP Address 212.4.67.72 Host a212-4-67-72.deploy.akamaitechnologies.com Location CH, Switzerland City -, - - Organization Telezug AG CableTV Customer ISP TELEZUG AG AS Number AS8821 WWZ Telekom AG
inetnum: 212.4.66.0 - 212.4.68.255 netname: TELEZUG-HFC descr: Telezug AG CableTV Customer country: CH remarks: **************************************************** remarks: For Spam/Abuse, please contact ONLY abuse@telezug.ch remarks: E-mails to other addresses will be IGNORED remarks: **************************************************** admin-c: TZE1-RIPE tech-c: TZN1-RIPE remarks: rev-srv: dns01.datazug.ch remarks: rev-srv: dns02.datazug.ch status: ASSIGNED PA mnt-by: AS8821-MNT source: RIPE # Filtered remarks: rev-srv attribute deprecated by RIPE NCC on 02/09/2009role: Telezug Network Engineering
address: WWZ Telekom AG
address: Chollerstrasse 24
address: CH-6301 Zug
address: Switzerland
phone: +41 41 748 49 30
fax-no: +41 41 748 47 47
e-mail: registry@telezug.ch
remarks: ****************************************************
remarks: For Spam/Abuse, please contact ONLY abuse@telezug.ch
remarks: For Security related tasks, use security@telezug.ch
remarks: E-mails to other addresses will be IGNORED
remarks: ****************************************************
mnt-by: TELEZUG-MNT
admin-c: RBU1-RIPE
tech-c: RBU1-RIPE
tech-c: PSC1-RIPE
tech-c: BHEG1-RIPE
nic-hdl: TZE1-RIPE
source: RIPE # Filteredrole: Telezug Network Operations Center
address: WWZ Telekom AG
address: Chollerstrasse 24
address: CH-6301 Zug
address: Switzerland
phone: +41 41 748 49 30
fax-no: +41 41 748 47 47
e-mail: noc@telezug.ch
remarks: ****************************************************
remarks: For Spam/Abuse, please contact ONLY abuse@telezug.ch
remarks: For Security related tasks, use security@telezug.ch
remarks: E-mails to other addresses will be IGNORED
remarks: ****************************************************
mnt-by: AS8821-MNT
admin-c: TZE1-RIPE
tech-c: TZN1-RIPE
nic-hdl: TZN1-RIPE
source: RIPE # Filtered% Information related to ‘212.4.64.0/19AS8821’
route: 212.4.64.0/19
descr: Telezug AG
descr: Chollerstrasse 24
descr: CH-6301 Zug
descr: Switzerland
remarks: ****************************************************
remarks: For Spam/Abuse, please contact ONLY abuse@telezug.ch
remarks: E-mails to other addresses will be IGNORED
remarks: ****************************************************
member-of: RS-TELEZUG
origin: AS8821
mnt-by: AS8821-MNT
source: RIPE # Filtered
The Whois information is inconclusive. That sometimes happens when an IP range was sold from one party to the other and the Whois information was not updated yet.
This range is either owned by Akamai ( a huge hosting company that hosts about 25% of the web and distributes updates for big software companies f.e.) or Telezug AG CableTV Customer ( www.telezug.ch ); a Swiss cable company among other things.
As a mod I can see you are connecting from an address that belongs to datazug.ch ISP. Datazug also shows in the Whois information so I think it is likely an address belonging to your ISP. Do you have an application running from your ISP that monitors your cable modem? That may be calling home.
In case the addresses are belonging to Akamai you may be looking at an updater trying to connect to the update server hosted by Akamai.
To get more information you can use Svchost Analyser and Svchost Viewer to see what process is behind that specific svchost.exe activity. You can cross reference with the Process ID (PID) when using those tools. The PID can be found with View Active Connections. Keep in mind that the PID may change when you reboot your computer.
Hello Eric,
Thanks you for the info, I really appreciate it.
A few more details on this problem:
Do you have an application running from your ISP that monitors your cable modem? That may be calling home.
I definitely DON’T HAVE any application from the ISP that monitors the cable modem. The cable modem doesn’t need any software installation: it has an Ethernet port to which you can connect a computer (or a home router) directly.
It works automatically with Windows and Linux.
svchost.exe tried again today to connect to some addresses at port 80 (see attached image). This time they don’t belong to Telezug but to Level 3 Communications.
The plot thickens … ???
I tried both programs you mentioned (Svchost Analyser and Svchost Viewer) but I couldn’t find a way to identify which service inside svchost.exe tries to make those connections.
Is there a way for the Comodo Firewall to display this information ? Or maybe another external tool can help me do that ?
Any help is appreciated since I really want to get to the bottom of this.
[attachment deleted by admin]
To know which of the svchost.exe processes is the one making the connection you need to see what Process ID it has.
The PID can be seen when using the Active Connections window. However you need to catch the connection in the act.
Thank you Eric.
Catching the svchost.exe process “in the act” is going to be difficult.
Maybe there is a software that can record all the connections made by processes ? That would help in finding the culprit.
Also, is there a way to make each service run into a separate svchost process ? This would make finding the service easier.
There are a number of options to do this:
This will run the netstat command silently every 60 seconds (change the value if your wish) and add the results to netstat.txt
Enable the logging option found under the file menu and leave currports open. Check the log file for details. the log capture can be customised. see the currports web page for details.
This is a protocol analyser similar to wireshark, but it now supports individual process connections and lists PIDs It’s a little more complex than the previous options, but might be useful.
Also, is there a way to make each service run into a separate svchost process ? This would make finding the service easier.
There are ways to do this, here’s a couple of links that may help. There’s plenty of information available:
http://www.winplat.net/post/2009/09/19/How-to-Isolate-services-running-in-svchostexe-process-instance.aspx
https://blogs.msdn.com/b/danvdw/archive/2003/09/26/51956.aspx
The first step to get a handle on SVCHost is to recognize what is ‘normal’. SVCHost is nothing more than a service the runs other services. You can internet search to get more info, but that’s essential to what it does. It is a fundamental core component of Windows. So IF Windows is assumed to be clean, then one can assume that SVCHost is also clean. Given the two foregoing premise, then whatever SVCHost does should be normal behvior.
What I’ve done is open notepad and paste the following:
Tasklist /FI “IMAGENAME eq svchost.exe” /svc
pause
I saved that file as Process_Tool.cmd. Then I created a shortcut on my desktop linking to that file. When you click the shortcut it will open up a DOS window and dsiplay all the services that are running under SVCHost. You need to get familiiar with what is normal. IF there’s an unual entry that ever shows up, or a process w/no name, that’s a good sign that SVCHost has been hijacked. Other than that what do you care? As long as it doesn’t have anything odd in its service process list, its assumbed to be legit Microsoft business.
On my system the following zones are allowed connection by SVCHost:
Akamai - SVCHost
Akamai - ARM/SVCHost - 80/443
AkamaiTech - SVCHost - 80 / 443
Akamai - ARM / SVCHost - 443
AkamaiTech - SVCHost - 443
*Akamai FT - SVCHost
eurorings.net - SVCHost
*GBLX - SVCHost
*GBLX - SVChost / ARM - 443
*Hurricane - SVCHost
*Level 3 - SVCHost
llnw.net - SVCHost
msecn.net - CIS / SVCHost / HelpCtr / VS
msecn - 80 / 443
msecn.net - 443
*MS 1BLK - SVCHost 80/443
*MS 1BLK - SVCHost - 443
*MS-Global-Net - SVCHost - 80/443
*NTT America - AcroRd32 / SVCHost
*NTT America - SVCHost
PCCWGlobal.net - CIS / jaucheck / SVCHost
qwest.net - jaucheck / SVCHost
qwest.net - SVCHost
*Qwest / Akamai - CIS / SVCHost
The key to the zone names is:
Network zones are sorted alphabetically by domain name / application / port
Zones may end up beging shared between applications, so when an IP address is discovered to already exist in some zone, the zone is either renamed (to include the new app name) and the existing ren-named zone added to the new app, or the particular IP pulled out of the existing zone, and a new zone created and that IP put into the new zone. That usually becomes an issue when a zone that is default port 80 suddenly is discovered to share port 80 & 443. In that case I make a new zone and suffix it with 80/443, and create a new rule allowing access to both port 80 & 443 for that zone. The pre-existing rules remain unaltered and are by default all connecting to port 80.
The * prefix zones are all referencing the unassignable IP address owner netname CIDR mask. For example:
*GBLX = Global Crossing In any *GBLX zone will be only the specific IP addresses that any arbitrary application connects to. However, I have a zone called:
_ARIN (IP Owner): Global Crossing
64.208.0.0/255.255.0.0
64.209.0.0/255.255.128.0
64.211.0.0/255.255.128.0
64.211.128.0/255.255.192.0
64.211.192.0/255.255.224.0
64.212.0.0/255.252.0.0
206.57.0.0/255.255.128.0
206.132.0.0/255.255.128.0
208.48.224.0/255.255.0.0
208.49.0.0/255.255.224.0
208.50.0.0/255.255.0.0
208.50.192.0/255.255.192.0
208.51.0.0/255.255.0.0
For any IP address that fits into the network range of those subnet masks, I put it into the proper * zone (or create as needed). If I can’t find it in there, then I have to look it up. I either find a new IP Owner, or have to add to the existing network subnets.
Actually, correct CIDR notation is presented differently. Using your example the notation would be:
64.208.0.0/16
RFC 4632 - Classless Inter-domain Routing ( CIDR ): The Internet …
Right. The mask is the dot notation. You can’t enter CIDR mask in CIS.
You can't enter CIDR mask in CIS.
Correct.
Thank you all for the useful infos. I’ll take a closer look to the problem using this info.