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

Xref: kermit microsoft.public.windowsxp.help_and_support:482799 microsoft.public.windowsxp.perform_maintain:171354

Thanks - I'll look into these possibilities!

--
####################
## PH, London
####################
"cquirke (MVP Win9x)" wrote in message
...
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.
-------------------- ----- ---- --- -- - - - -

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.

"cquirke (MVP Win9x)" wrote this sig:



-------------------- ----- ---- --- -- - - - -
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.
-------------------- ----- ---- --- -- - - - -

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.

"cquirke (MVP Win9x)" wrote this sig:



-------------------- ----- ---- --- -- - - - -
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.
-------------------- ----- ---- --- -- - - - -

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.

"cquirke (MVP Win9x)" wrote this sig:



-------------------- ----- ---- --- -- - - - -
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.
-------------------- ----- ---- --- -- - - - -

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.

"cquirke (MVP Win9x)" wrote this sig:



-------------------- ----- ---- --- -- - - - -
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.
-------------------- ----- ---- --- -- - - - -

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.

"cquirke (MVP Win9x)" wrote this sig:



-------------------- ----- ---- --- -- - - - -
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.
-------------------- ----- ---- --- -- - - - -

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.

"cquirke (MVP Win9x)" wrote this sig:



-------------------- ----- ---- --- -- - - - -
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.
-------------------- ----- ---- --- -- - - - -

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)" wrote in message
...
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.

"cquirke (MVP Win9x)" wrote this sig:



-------------------- ----- ---- --- -- - - - -
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.
-------------------- ----- ---- --- -- - - - -

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)" wrote in message
...
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.

"cquirke (MVP Win9x)" wrote this sig:



-------------------- ----- ---- --- -- - - - -
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.
-------------------- ----- ---- --- -- - - - -

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)" wrote in message
...
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.

"cquirke (MVP Win9x)" wrote this sig:



-------------------- ----- ---- --- -- - - - -
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.
-------------------- ----- ---- --- -- - - - -

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)" wrote in message
...
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.

"cquirke (MVP Win9x)" wrote this sig:



-------------------- ----- ---- --- -- - - - -
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.
-------------------- ----- ---- --- -- - - - -

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)" wrote in message
...
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.

"cquirke (MVP Win9x)" wrote this sig:



-------------------- ----- ---- --- -- - - - -
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.
-------------------- ----- ---- --- -- - - - -

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)" wrote in message
...
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.

"cquirke (MVP Win9x)" wrote this sig:



-------------------- ----- ---- --- -- - - - -
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.
-------------------- ----- ---- --- -- - - - -

Xref: kermit microsoft.public.windowsxp.help_and_support:482799 microsoft.public.windowsxp.perform_maintain:171354

Thanks - I'll look into these possibilities!

--
####################
## PH, London
####################
"cquirke (MVP Win9x)" wrote in message
...
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.
-------------------- ----- ---- --- -- - - - -

Xref: kermit microsoft.public.windowsxp.help_and_support:482799 microsoft.public.windowsxp.perform_maintain:171354

Thanks - I'll look into these possibilities!

--
####################
## PH, London
####################
"cquirke (MVP Win9x)" wrote in message
...
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.
-------------------- ----- ---- --- -- - - - -