SVCHOST & LSASS hogging CPU, no virus found. I'm completely stuck! (detailed)

[Philip Herlihy]

(Thanks for looking!)

I have a friend's machine (running XP Home, fully patched) which is unusably
slow. I can see that LSASS.exe together with one instance of SVCHOST.exe
are effectively using all CPU resources. I've run updated versions of:
# Norton Antivirus
# McAfee Stinger
# Panda Online scan
# Trend Micro Online scan
# Adaware
# Spybot
... and although a few nasties were removed, the problem remains.

I've downloaded the (excellent) Process Explorer from Sysinternals.com.
I've found that if I suspend that one SVCHOST instance, the LSASS process
goes quiet. Looking inside the SVCHOST I can see that the thread
TERMSRV.dll appears to be accounting for the activity, and if I selectively
kill that thread, the machine goes back to normal.

I've studied the registry keys:
# HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
# HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost
... but my untutored eye can't spot anything wrong.

A typical stack trace of the TERMSRV thread is:
ntdll.dll+0x8090304
RPCRT4.dll!I_RpcTransGetThreadEvent+0x9d7
RPCRT4.dll!I_RpcTransGetThreadEvent+0x147b
RPCRT4.dll!NdrContextHandleInitialize+0x82e
RPCRT4.dll!I_RpcTransGetThreadEvent+0x5d0
RPCRT4.dll!I_RpcTransGetThreadEvent+0x557
RPCRT4.dll!I_RpcTransGetThreadEvent+0x3bc
RPCRT4.dll!I_RpcTransGetThreadEvent+0x2f6
RPCRT4.dll!I_RpcTransGetThreadEvent+0x26f
RPCRT4.dll!I_RpcSendReceive+0x1f
ADVAPI32.dll!LsaRetrievePrivateData+0xdf
termsrv.dll+0x201d9
termsrv.dll+0x20428
termsrv.dll+0xd1fc
kernel32.dll!RegisterWaitForInputIdle+0x43

I thought I was a smart geezer, but this one has me beaten. Next step is a
format and reinstall, unless someone has an idea.

 

[Carey Frisch [MVP]]

Install the following patch:

Windows XP Patch: Remote Assistance
http://www.microsoft.com/downloads/...FamilyID=9C91C448-D1D1-4614-B8BA-9A33857ECEBA

--
Carey Frisch
Microsoft MVP
Windows XP - Shell/User

Be Smart! Protect your PC!
http://www.microsoft.com/security/protect/\

-------------------------------------------------------------------------------------------


| (Thanks for looking!)
|
| I have a friend's machine (running XP Home, fully patched) which is unusably
| slow. I can see that LSASS.exe together with one instance of SVCHOST.exe
| are effectively using all CPU resources. I've run updated versions of:
| # Norton Antivirus
| # McAfee Stinger
| # Panda Online scan
| # Trend Micro Online scan
| # Adaware
| # Spybot
| .. and although a few nasties were removed, the problem remains.
|
| I've downloaded the (excellent) Process Explorer from Sysinternals.com.
| I've found that if I suspend that one SVCHOST instance, the LSASS process
| goes quiet. Looking inside the SVCHOST I can see that the thread
| TERMSRV.dll appears to be accounting for the activity, and if I selectively
| kill that thread, the machine goes back to normal.
|
| I've studied the registry keys:
| # HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
| # HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost
| .. but my untutored eye can't spot anything wrong.
|
| A typical stack trace of the TERMSRV thread is:
| ntdll.dll+0x8090304
| RPCRT4.dll!I_RpcTransGetThreadEvent+0x9d7
| RPCRT4.dll!I_RpcTransGetThreadEvent+0x147b
| RPCRT4.dll!NdrContextHandleInitialize+0x82e
| RPCRT4.dll!I_RpcTransGetThreadEvent+0x5d0
| RPCRT4.dll!I_RpcTransGetThreadEvent+0x557
| RPCRT4.dll!I_RpcTransGetThreadEvent+0x3bc
| RPCRT4.dll!I_RpcTransGetThreadEvent+0x2f6
| RPCRT4.dll!I_RpcTransGetThreadEvent+0x26f
| RPCRT4.dll!I_RpcSendReceive+0x1f
| ADVAPI32.dll!LsaRetrievePrivateData+0xdf
| termsrv.dll+0x201d9
| termsrv.dll+0x20428
| termsrv.dll+0xd1fc
| kernel32.dll!RegisterWaitForInputIdle+0x43
|
| I thought I was a smart geezer, but this one has me beaten. Next step is a
| format and reinstall, unless someone has an idea.
|
| --
| ####################
| ## PH, London
| ####################
|
|

 

[Philip Herlihy]

Thanks, Carey. I'm very grateful for the suggestion, but it didn't work.
The machine has XP Home with SP1 (I should have specified this) and the
patch is apparently pre-SP1 (an error-message said it could only be applied
if no SPs were already there.

I'm becoming increasingly resigned to a re-format and install, but my
relatively untechnical friend will lose heaps of settings, passwords and so
on. :-(

 

[Quaoar]

Thanks, Carey. I'm very grateful for the suggestion, but it didn't
work. The machine has XP Home with SP1 (I should have specified this)
and the patch is apparently pre-SP1 (an error-message said it could
only be applied if no SPs were already there.

I'm becoming increasingly resigned to a re-format and install, but my
relatively untechnical friend will lose heaps of settings, passwords
and so on. :-(

http://www.microsoft.com/downloads/...FamilyID=9C91C448-D1D1-4614-B8BA-9A33857ECEBA

What is being run at startup as indicated in msconfig/startup tab? Can
you track the source of this problem by selectively unchecking the
startups one at a time?

Q

 

[Philip Herlihy]

What is being run at startup as indicated in msconfig/startup tab? Can
you track the source of this problem by selectively unchecking the
startups one at a time?

Q

I've gazed at the startup list but I haven't tried selectively unchecking
them. Part of the problem is that the thing can take an hour to boot, it's
so slow! It'll take me several days. I'll ponder whether I can face it...

 

[Rocket J. Squirrel]

Quaoar's advice is the only way for you to determine whether something being
run at startup is the cause of your problem. You need to follow that advice
no matter how long it takes.

Rocky

 

[Philip Herlihy]

Well, that was a lot quicker than I expected. I disabled "Terminal
Services" and it booted (otherwise) normally. But I've already run the
System File Checker, and nothing was found to be amiss. Why would TS go
bonkers?

 

[cquirke (MVP Win9x)]

On Wed, 14 Apr 2004 18:46:38 +0100, "Philip Herlihy"

Thanks, Carey. I'm very grateful for the suggestion, but it didn't work.

The machine has XP Home with SP1 (I should have specified this) and the
patch is apparently pre-SP1 (an error-message said it could only be applied
if no SPs were already there.

Two things come to mind:

1) There are new (April 2004) patches involving LSASS and DCOM

Seek and apply these - in case what is happening is an exploit of the
newly-announced holes involving these things.

2) Malware use of SVCHost

Malware can either use the "real" SVCHost to shell themselves (so that
firewalls set to allow the "real" SVCHost allows the malware too) or
can drop thier own "SVCHost" files that are running.

CoolWebSearch is a common, frequently-updated commercial malware that
exploits a wide range of holes and attack methods, often including
SVCHost. There's a web site and utility dedicated to killing CWS;
Google for it (merjin) and check it out - they document the variations
and evolve the killer tool to manage the matest ones.


As usual, I'd start with a formal virus check to exclude traditional
malware, then drill down to commercial malware through Windows using
AdAware, Spybot, and the dedicated CWS killer.

-------------------- ----- ---- --- -- - - - -

Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.

 

[Rocket J. Squirrel]

Interesting sig ("Running Windows-based av..."). Could you explain why you
feel that way?

Rocky

On Wed, 14 Apr 2004 18:46:38 +0100, "Philip Herlihy"



Two things come to mind:

<snip>

 

[Philip Herlihy]

Thanks - I'll look into these possibilities!

 

[cquirke (MVP Win9x)]

On Fri, 16 Apr 2004 16:19:40 -0400, "Rocket J. Squirrel"

Interesting sig ("Running Windows-based av..."). Could you explain why you
feel that way?

Basically, whichever code runs first has the potential to assert "air
superiority", i.e. is in a position to block other code from running,
monitor its files and threads to detect attempts to kill itself, and
take punitive action, e.g. a "poison-pill" effect.

There are two easy ways for malware to take countermeasures against
antivirus software. The first - which is routine these days - is to
watch for known av process names. It's a little bit like a virus
scanning for antivirus software, and a lot easier for the malware to
do - given there are far more viruses (that the av successfully looks
for) than there are antivirus programs for the malware to look for.

The second is to be self-aware, i.e. to watch the malware's own
startup and integration settings and files. If these vanish, it can
re-assert them, or take revenge. Some malware spawn multiple threads,
which watch each other; when one thread is terminated, the other acts.

For this reason, it's safest to detect the malware while it is not
active. As you don't know where in the HD the malware has patched in
(that's what you are scanning to find out), it's best to run no code
off the HD at all. Then you *know* the malware's inactive and it's
safe to identify it, if not necessary to delete it. You also have
more confidence that a negative result doesn't just mean the malware
has found a way to hide itself via some runtime duck and jive.

Once you know what you are dealing with (and can believe the results),
you can look up reference info on the malware to see whether it's safe
to clean it, or whether particular caveats apply.

Trouble is, there's no maintenance OS for NTFS - the only OS that can
read NTFS without any compatibility FUD is NT, and NT can only run
from the ?infected HD. MS has what could be a maintenance OS (the PE
disk) but it's so tightly held that techs who need it can't get it,
and with such a tiny market, av vendors won't write products to run
from it. Bart's PE builder is an alternative, but once again it's an
uncertain market for av vendors to develop for.

-------------------- ----- ---- --- -- - - - -

Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.

 

[Rocket J. Squirrel]

Perhaps you should alert the folks at Symantec (for example.) According to
you, they've completely missed the boat.

I've been using Norton AntiVirus since 1997 and never once has my computer
been infected. Talk about a string of luck!

Rocky

 

[cquirke (MVP Win9x)]

On Sat, 17 Apr 2004 16:58:58 -0400, "Rocket J. Squirrel"

I've been using Norton AntiVirus since 1997 and never once has my computer
been infected. Talk about a string of luck!

That's what you'd expect a good av to do - *prevent* malware from
going active by detecting and killing it beforehand!

As long as your av is already running at the time the malware tries to
run, the av has the upper hand and should manage the problem fine.

When the av fails to detect the malware - usually because it's a new
variant that doesn't match the known detection tests - the opportunity
to stop the malware cold has been lost. If the malware then goes
active, I would not use the same av that has already failed to detect
the malware to chase after it while it's running.

Instead, I might use the "rescue" facility of that av to tackle it
formally. Most Windows-based av have a "rescue' facility that
basically prepares boot and av diskettes for formal scanning, but
obviously two problems come to mind:

1) Your file system may be incompatible with the rescue disks

Rescue disks tends to be DOS-based, and while a DOS mode diskette from
Win95 SR2 or later can read FAT32, they can't read NTFS

2) You can't really trust av disks prepared within infected OS

Many malware will knock down your resident av, or block the ability to
update it - so you should prepare the diskettes on another, clean PC.

Because of (2), it's often more practical to download and use an
arbitrary free DOS-based av, rather than the "rescue" facility of your
installed av, if the clean PC you use doesn't use the same av.

-------------------- ----- ---- --- -- - - - -

Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.