Malware removes tdsskiller.exe ?

[Steve Pope]

Hi Folks.

On an XP machine, I mistyped a website URL in Explorer causing
an event caught by Malwarebyte's realtime protection. There
seemed to be no damage, but as a precaution I went through a
brief clean-up process including an immediate power-down and running
"System Restore" with a restore point a few days in the past.

Subsequent to the System Restore, there were certain instabilities,
which I have now cleaned up, and they are mostly explainable as
side effects of the System Restore and/or the abrupt power-down, but
there is one oddity I cannot explain:

I had previously saved a copy of Kaspersky tdsskiller.exe in a directory
(not a standard Windows directory, one of my own directories), and
it is now gone!

Is it possible that a malware would have searched for and deleted
tdsskiller.exe? Well, I know it's technically possible; so my real
question is: are there any reports of any malware actually doing this?

The system seems okay: Windows update and antivirus updates still work,
scans are clean including Avast, Malwarebytes, F-Secure Easyclean
and tdsskiller, I do not see any website redirection, I do not see
wrong IP's in netstat, the hosts file had not been written to.

Any thoughts?

Thanks

Steve

 

[David H. Lipman]

From: "Steve Pope" <[email protected]>

| Hi Folks.

| On an XP machine, I mistyped a website URL in Explorer causing
| an event caught by Malwarebyte's realtime protection. There
| seemed to be no damage, but as a precaution I went through a
| brief clean-up process including an immediate power-down and running
| "System Restore" with a restore point a few days in the past.

| Subsequent to the System Restore, there were certain instabilities,
| which I have now cleaned up, and they are mostly explainable as
| side effects of the System Restore and/or the abrupt power-down, but
| there is one oddity I cannot explain:

| I had previously saved a copy of Kaspersky tdsskiller.exe in a directory
| (not a standard Windows directory, one of my own directories), and
| it is now gone!

| Is it possible that a malware would have searched for and deleted
| tdsskiller.exe? Well, I know it's technically possible; so my real
| question is: are there any reports of any malware actually doing this?

| The system seems okay: Windows update and antivirus updates still work,
| scans are clean including Avast, Malwarebytes, F-Secure Easyclean
| and tdsskiller, I do not see any website redirection, I do not see
| wrong IP's in netstat, the hosts file had not been written to.

| Any thoughts?

You saved TDSSKiller.EXE in a folder on a date AFTER the day of the System Restore break
point your restored from.

The System Restore function works on EXE and DLL files the Registry and other OS
constructs but not on data files (ZIP, TXT, DOC, XLS, PPT, PDF, etc...).

Since you most likely restored to a break point PRIOR to saving the EXE file, the system
removed the file when you restored the system from that break point.

 

[Steve Pope]

You saved TDSSKiller.EXE in a folder on a date AFTER the day of the
System Restore break point your restored from.

The System Restore function works on EXE and DLL files the Registry and
other OS constructs but not on data files (ZIP, TXT, DOC, XLS, PPT,
PDF, etc...).

Since you most likely restored to a break point PRIOR to saving the EXE
file, the system removed the file when you restored the system from
that break point.

Thank you. I was thinking it was something like that, I just hadn't
previously noticed system restore removing .exe files. I guess
this removal only happens if the following occurs in sequence:

(1) A restore point is created
(2) A .exe file is created
(3) The file in (2) is executed (thus creating a registry entry?)
(4) The system is restored back to (1).

This does indeed explain my observations. Thanks


Steve

 

[David H. Lipman]

From: "Steve Pope" <[email protected]>


| Thank you. I was thinking it was something like that, I just hadn't
| previously noticed system restore removing .exe files. I guess
| this removal only happens if the following occurs in sequence:

| (1) A restore point is created
| (2) A .exe file is created
| (3) The file in (2) is executed (thus creating a registry entry?)
| (4) The system is restored back to (1).

| This does indeed explain my observations. Thanks

No...

A given executeable file will no longer exist when...

1. A System Restore point is created on Date/Time X

2. The .EXE file in question is saved subsequent to the event when the System Restore
point being created

3. The system is restored back the restore point which was was created on Date/Time X
when the .EXE file is question did not exist



....Alternatively...

A given executeable file will no longer exist when...


1. A System Restore point is created on Date/Time X

2. The .EXE file in question is saved subsequent to the event when the System Restore
point being created

3. The system is restored back the restore point which was was created on Date/Time X
when the .EXE file is question did not exist



....Additionally...

A given executeable file will revert back to its original condition (newer, size, version,
date of creation, etc) when...

1. A System Restore point is created on Date/Time X

2. The different.EXE file in is saved subsequently to the file that had existed when the
when the System Restore point being created

3. The system is restored back the restore point which was was created on Date/Time X
when the given file was at its original condition


....Alternatively...

A given Registry entry will will revert back to a pior setting when...

1. A System Restore point is created on Date/Time X

2. The given Registry entry in question is modified/altered subsequent to the event when
the System Restore had been created

3. The system is restored to the restorte point created on Date/Time X

4. The Registry entry exists in its prior condition to what it had been when the restore
point was created on Date/Time X

HTH

 

[David H. Lipman]

From: "David H. Lipman" <[email protected]>

I think I screwed that up :-(

 

[Steve Pope]

A given executeable file will no longer exist when...

1. A System Restore point is created on Date/Time X

2. The .EXE file in question is saved subsequent to the event when the
System Restore point being created

3. The system is restored back the restore point which was was created
on Date/Time X when the .EXE file is question did not exist

A given executeable file will revert back to its original condition
(newer, size, version, date of creation, etc) when...

1. A System Restore point is created on Date/Time X

2. The different.EXE file in is saved subsequently to the file that had
existed when the when the System Restore point being created

3. The system is restored back the restore point which was was created
on Date/Time X when the given file was at its original condition

Thanks. That makes more sense than what I had speculated. It does
however imply that System Restore scans the entire disk for executables
(or perhaps the filesystem already has them indexed or in a hash table
or some such).


S.

 

[Dustin]

From: "Steve Pope" <[email protected]>



| Thank you. I was thinking it was something like that, I just
| hadn't previously noticed system restore removing .exe files. I
| guess this removal only happens if the following occurs in
| sequence:

| (1) A restore point is created
| (2) A .exe file is created
| (3) The file in (2) is executed (thus creating a registry entry?)
| (4) The system is restored back to (1).

| This does indeed explain my observations. Thanks

No...

A given executeable file will no longer exist when...

1. A System Restore point is created on Date/Time X

2. The .EXE file in question is saved subsequent to the event when
the System Restore point being created

3. The system is restored back the restore point which was was
created on Date/Time X when the .EXE file is question did not exist



...Alternatively...

A given executeable file will no longer exist when...


1. A System Restore point is created on Date/Time X

2. The .EXE file in question is saved subsequent to the event when
the System Restore point being created

3. The system is restored back the restore point which was was
created on Date/Time X when the .EXE file is question did not exist



...Additionally...

A given executeable file will revert back to its original condition
(newer, size, version, date of creation, etc) when...

1. A System Restore point is created on Date/Time X

2. The different.EXE file in is saved subsequently to the file that
had existed when the when the System Restore point being created

3. The system is restored back the restore point which was was
created on Date/Time X when the given file was at its original
condition


...Alternatively...

A given Registry entry will will revert back to a pior setting
when...

1. A System Restore point is created on Date/Time X

2. The given Registry entry in question is modified/altered
subsequent to the event when the System Restore had been created

3. The system is restored to the restorte point created on
Date/Time X

4. The Registry entry exists in its prior condition to what it had
been when the restore point was created on Date/Time X

HTH

To add to what David wrote, not all EXE files on your system are done
this way. Only ones which live in \Windows home folder.

 

[Dustin]

(e-mail address removed) (Steve Pope) wrote in

Thanks. That makes more sense than what I had speculated. It does
however imply that System Restore scans the entire disk for
executables (or perhaps the filesystem already has them indexed or
in a hash table or some such).


S.

No, it's protecting the directory structure and contents of the
windows/below folders.

 

[Steve Pope]

To add to what David wrote, not all EXE files on your system are done
this way. Only ones which live in \Windows home folder.

Well that's the kicker. The file in question was not in the Windows
directory or any other system-defined directory. Nor was it any part
of an installed program. It was just a random .exe file. But it
did meet the creation-time constraints David describes.


Steve

 

[Dustin]

(e-mail address removed) (Steve Pope) wrote in @blue.rahul.net:

Well that's the kicker. The file in question was not in the Windows
directory or any other system-defined directory. Nor was it any part
of an installed program. It was just a random .exe file. But it
did meet the creation-time constraints David describes.


Steve

Hmm. That is very interesting. /me checks MS website.
http://preview.tinyurl.com/ycukdl5

Learn something new and cool everyday. Apparently, system restore is
different than how I remember it being. They don't specify, but they do
say "and other types of executable files on your computer." - That aspect
is new to me. It doesn't specify this as something Windows XP or Vista
and up only do, so I assume? it includes windows XP...

Thanks for taking the time to create this thread Steve.

 

[Steve Pope]

(e-mail address removed) (Steve Pope) wrote in news:ilulju$rlc$2

Hmm. That is very interesting. /me checks MS website.
http://preview.tinyurl.com/ycukdl5

Learn something new and cool everyday. Apparently, system restore is
different than how I remember it being. They don't specify, but they do
say "and other types of executable files on your computer."

Allright then. Thank you for looking this one up.

Steve

 

[David H. Lipman]

From: "Steve Pope" <[email protected]>


| Thanks. That makes more sense than what I had speculated. It does
| however imply that System Restore scans the entire disk for executables
| (or perhaps the filesystem already has them indexed or in a hash table
| or some such).


I presume the whole system (no matter how many fixed hard drives).

 

[David H. Lipman]

From: "Dustin" <[email protected]>

| (e-mail address removed) (Steve Pope) wrote in
|

| No, it's protecting the directory structure and contents of the
| windows/below folders.


Not really. It works for files/folders outside the %WIDIR%.

 

[David H. Lipman]

From: "Dustin" <[email protected]>



| To add to what David wrote, not all EXE files on your system are done
| this way. Only ones which live in \Windows home folder.


See my previous reply. It works outside of %WINDIR%.