I am on Dial-up and my bandwidth bearly reaches 56kbps. There is this Generic Host Process for Win32 Service that is using all my bandwidth when I am not using my internet connection. When I want to download something, the download speed is ~1 kbps with all the bandwidth this process is using. Can anybody tell me what I can do to stop it? When I block its activities with ZA none of my other internet services work (IE/FF/etc). I have sniffed the network traffic with Ethereal but the packets being sent and received are not in plain text neither are comprehensible (not at least by me). I'd appreciate it if somebody could tell me how to prevent this service from eating my connection's bandwidth before I pick a gun and shoot it in the head.
Posted on 2007-03-26 09:41:28 by XCHG
It could be the Windows Update service, which might be malfunctioning. It's probably a bit hard pinpointing the problem, since SVCHOST runs multiple processes, each responsible for one or more windows services. If you can see *which* instance of SVCHOST is eating the bandwidth (ie, the PID), you can use Process Explorer from Sysinternals to find that instance and see which services it is reponsible for.

Btw, if it's SCVHOST and not SVCHOST (note the subtle difference), you've got a trojan.
Posted on 2007-03-26 17:12:32 by f0dder

It could still be a trojan.
SVCHOST.EXE is responsible for all SERVICES (we knew that).
Many 'diallers' use Services to stay resident because they execute as SYSTEM privilege, and are thus higher privilege than your ADMIN account(s) !!!
Try this: boot up in SafeMode, with Networking.
This will load ONLY the critical Services.
If this solves the problem, then we're sure we have an issue with a Service..
While STILL in SafeMode, look in the ControlPanel/AdministrationTools/Services applet for suspicious Services (since if there is a Trojan Service, it will probably hide itself from this List when we boot normally).
Posted on 2007-03-26 21:05:56 by Homer
Does your firewall show the remote ip address and port of the suspect bandwidth hogging process ?

At a command prompt try

netstat -a -b

it will show the dlls used by the various svchost.
Posted on 2007-03-26 21:08:51 by dsouza123
I truly doubt it being a Trojan because I use to code Trojans before and know how they work. I removed SVCHOST from Zone Alarm?s access list and then connected to the internet again and let it attempt to open a connection and then took two screen shots of it (attached to this post). One was trying to connect to a DNS served (because I use dial-up and have a dynamic DNS) and one was trying to connect to an IP using HTTP. Zone Alarm showed the destination IPs to me and I tried pinging both of them but none of them could be pinged. I then used TRACERT and no dice there either.

I then disabled some of the services that I normally don?t use in the Services.msc applet. I also checked the paths below in the registry:

1. HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies
2. HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
3. HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
4. HKEY_CURRENT_USER\Software\Policies\Microsoft
5. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows
6. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies
7. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
8. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
9. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx

None of those contained any values pertaining to software I was not aware of. Since I am using WinXP SP2 I guess there is no benefit in checking Boot.ini and Win.ini for malicious software and/or Trojan. I also watched my CPU?s activities in the Task Manager and while I was connected to the internet and the damn SVCHOST was using the connection, there were no activities shown for any of its instances but one of them which the Task Manager showed as using 1% of the CPU. I also searched for ?S*HOST.*? in my hard drive and there was only one file found which was ?SVCHOST.EXE?.

Then I checked for connection established in my pc with NETSTAT ?n ?a and here is the log. The PIDs that I got here were exactly equal to those of SVCHOST?s.

Attachments:
     
    
Posted on 2007-03-27 09:55:10 by XCHG
Netstat isn't showing anything interesting. The IP reported by zonealarm is interesting - it doesn't have a reverse dns, and trying to browse there  gives a cryptic message.

Try sniffing network traffic?
Posted on 2007-03-27 10:06:40 by f0dder
The new version of Ethereal is free. Older versions were not and I'm downloading the new version. I will post the captured packets as soon as the download is complete. Thank you.
Posted on 2007-03-27 10:35:20 by XCHG
What about  netstat -a -b ?

The -b will show each svchost and which dlls it is using,


Proto  Local Address          Foreign Address        State          PID

UDP    machineABC:ntp        *:*                                    896
c:\windows\system32\WS2_32.dll
c:\windows\system32\w32time.dll
c:\windows\system32\ntdll.dll
C:\windows\system32\kernel32.dll



The above shows that this particular svchost is for the Windows Time service,
and it also uses three other dlls, Winsock2, NT and Kernel.
Posted on 2007-03-27 16:31:26 by dsouza123
dsouza123,

My netstat doesn't have a -b switch!


Okay I monitored the network traffic while no other programs were using any bandwidth and here is the picture. I have also attached the Ethereal captured packets to this post. This is an HTTP request that SVCHOST sends over and over again to the Microsoft's website as it's trying to download MSN messenger's installation package. I then uninstalled my MSN messenger and denied its access explicitly in Zone Alarm. I also disabled its services and prevented it from running in MMC. Any ideas?

Posted on 2007-03-28 08:46:19 by XCHG
I wonder if it's messenger itself that's trying to (and failing at) updating, or if it's Windows Update trying to (and failing at) updating messenger? :)
Posted on 2007-03-28 08:51:22 by f0dder

Note the range-bytes.

This is a partial get request.
We normally only see these in two situations:
-as a mechanism used for resuming a http download (for whatever reason)
-as a throttling mechanism in download managers

Since when did messenger have a background updater?
Anyway, the host sure looks legit.
Looking closer at the packet, we see that the User-Agent is BITS, the Microsoft Background Intelligent Transfer Service, meant to supposedly download deferred files using your idle bandwidth.
Just disable the BITS service.



Posted on 2007-03-28 09:15:23 by Homer

Just disable the BITS service.

...and down the drain goes the Windows Update service as well, right?
Posted on 2007-03-28 09:18:47 by f0dder
Looking closer at the packet, we see that the User-Agent is BITS, the Microsoft Background Intelligent Transfer Service, meant to supposedly download deferred files using your idle bandwidth.
Just disable the BITS service.


Problem solved. Thank you so much everyone. Thank you Homer.

f0dder,

Good thing I don't use the Windows Update. I don't think it's a good idea considering the fact that I'm on dial-up  :sad:


P.S: Background Intelligent Transfer Service  :lol:
Posted on 2007-03-28 09:22:25 by XCHG
Ugh, dialup >_<

Yeah, probably not a big loss getting rid of the BITSh then.
Posted on 2007-03-28 09:25:35 by f0dder
Yeah; although I'm wondering if these packets are really supposed to be sent and received or there is something wrong with BITS. I mean why should it attempt to download Messenger updates? if that's what it is trying to download. I have uninstalled msn messenger and prevented its execution explicitly both in Zone Alarm and in MMC.
Posted on 2007-03-28 09:28:10 by XCHG
Well, I know from experience that windows update can go haywire sometimes. Wouldn't surprise me at all if BITS was instructed to download a messenger update some time, something went wrong, and the request was never cancelled.
Posted on 2007-03-28 09:33:39 by f0dder