Windows XP Virus

[Daave]

Thanks for posting back

my main point was to alert people who think their systems are secured

to think again!

We are all on the same page as far as that is concerned, philo. The
point I was making was that even if you are able to delete rootkit files
in the restore volume, you aren't necessarily rootkit-free. If the
rootkit was indeed phoning home, it is highly unlikely it was doing so
from that location (then again, I appreciate your link; I will read that
in depth). Chances are it was phoning home from another location you
were unable to detect.

 

[MowGreen]

Read the article again, BroBear. And, 'bear' in mind that the author
has NOT analyzed any newer generations than what existed in *August 2008*.
A check of the MS Malware Protection's encyclopedia shows plenty more
variants of Dogrobot that have appeared since then:

http://www.microsoft.com/security/p...rue&CBF=True&sortby=date&sortdir=desc&size=10

" Fifth generation
The ï¬fth generation of Dogrobot was noticed in the wild in
August 2008. In this generation, Dogrobot uses a new
technique, PASS_THROUGH, in order to penetrate through
System Restore. Windows OS provides three I/O control
codes: IOCTL_SCSI_PASS_THROUGH (0x4D004),
IOCTL_ATA_PASS_THROUGH (0x4D02C) and IOCTL_
IDE_PASS_THROUGH (0x4D028), and user-mode
applications can send IRP with these I/O control codes via
DeviceIoControl( ) to the disk.sys driver. These IRPs will be
forwarded directly down to the lower driver (e.g. atapi.sys) in
order to perform disk read/write or other disk operations [10].
Some System Restore solutions don’t intercept the read/write
access via PASS_THROUGH and this is exploited by the ï¬ fth
generation to compromise System Restore. The disassembly
of the code used by Dogrobot to write to disk via IOCTL_
ATA_PASS_THROUGH is depicted in Figure 11. "

Does atapi.sys ring a bell ? Remember the TDSS rookit ?


MowGreen
================
*-343-* FDNY
Never Forgotten
================

banthecheck.com
"Security updates should *never* have *non-security content* prechecked

 

[glee]

I ran numerous scans using four different root kit detection programs.

It appears to be clean and the user has since made on-line financial
transactions without getting hacked...

but with root kits...I don't know of one can ever be 100% sure

nasty stuff!

Did you run those rootkit programs while the drive was slaved to another
computer, rather than being booted from the drive being scanned? I ask
for obvious reasons.

The safest method is to scan from outside the OS with a rootkit scanner
AND an anti-virus app AND a spyware detection app like MBAM. I think we
all agree on that as a *preferred* protocol.

What is being described in the articles both you and Mow posted, is not
conclusive that the malware is actually being run (and therefore
"active") from within the SVI folders. It appears that the folder
created by the infection inside the SVI folder was used to store
components used for the initial installation of the infection, but the
infection itself is actually executing as a service out of the System32
folder tree and loading from the Service Registry Key.....note please
the quote from the article you cited: "....running as a service allows
the rootkit to survive a reboot".

Even if this is the case, that it isn't active in the SVI, the fact that
the folder was easily hacked for storage makes it possible that sooner
or later, a rootkit will come along that will succeed in actually
running from there. It just get nastier all the time....and we can't
afford to be smug and say it can "never" happen. Never say
never...especially about malware. ;-)

 

[MowGreen]

Did you run those rootkit programs while the drive was slaved to another
computer, rather than being booted from the drive being scanned? I ask
for obvious reasons.

The safest method is to scan from outside the OS with a rootkit scanner
AND an anti-virus app AND a spyware detection app like MBAM. I think we
all agree on that as a *preferred* protocol.

What is being described in the articles both you and Mow posted, is not
conclusive that the malware is actually being run (and therefore
"active") from within the SVI folders. It appears that the folder
created by the infection inside the SVI folder was used to store
components used for the initial installation of the infection, but the
infection itself is actually executing as a service out of the System32
folder tree and loading from the Service Registry Key.....note please
the quote from the article you cited: "....running as a service allows
the rootkit to survive a reboot".

Even if this is the case, that it isn't active in the SVI, the fact that
the folder was easily hacked for storage makes it possible that sooner
or later, a rootkit will come along that will succeed in actually
running from there. It just get nastier all the time....and we can't
afford to be smug and say it can "never" happen. Never say
never...especially about malware. ;-)

Mal-coders stash executables in TIF but they are not executed until
something outside of TIF calls them to run. So, technically speaking,
malware executables are not active in TIF.
It's the same with executables in SVI but ... the prevailing notion was
that one needed to utilize an infected restore point to pWn the system.

Another anti-malware warrior explained how this Vista System Restore
Rootkit functions: http://www.rootkit.com/newsread.php?newsid=900

" This is not a rootkit that runs from SVI either. The rootkit
initiates a system restore, and it then intercepts and diverts SR
execution so malicious files and registry keys are restored. Once the PC
is shutdown and restarted the infected file(s) and autostart(s) that
were introduced by the subverted SR, will take effect. The advantage of
using such a rootkit, is that it is enables malware to silently install
without activating any HIPS or security program alerts. "



MowGreen
================
*-343-* FDNY
Never Forgotten
================

banthecheck.com
"Security updates should *never* have *non-security content* prechecked