Inconsistent CIS - unsucessful malware both ignored and detected ? ! ! !

If malware is present in a C:\System Volume Information_restore{…} it has been detected and zapped.
It is probably less dangerous that what has not been detected and zapped.
If the system is restored then that malware would be re-instated,
That is inconvenient, but if it has been detected and zapped once it can be dealt with again ! ! !

That is my theory but in practice I play safe and go along with general accepted wisdom to purge malware regardless of location.

Even though System Volume Information can reach 1.8 GB and constitute up to 30% of the used space on C:, I have NOT added it to Virus scanner exclusions.

Why do my CIS default Virus scanner exclusions commence with “?:\Recycle?*” ?
Is not that the FAT32 equivalent of NTFS System Volume Information ?

Regards
Alan

Personally, I put the system restore files on my exclusion list.

Yes, I know malware can hide there, but it I also know that in my experience the system restore files are prone to false positives. Especially CIS.

I know this because I’ve tested it many times. I do a complete system scan with all the scanners at my disposal. They all come up clean. (Including CIS) I create a new restore point and low and behold, CIS finds something in the new restore point! If I then scan this restore point with my other scanners, they come up clean.

Avira also used to be problematic in regards to restore files, but it has improved.

CIS is my main line of defense, but aside from a weekly full system scan with CIS, I also run a scan with two other products weekly. (The other two products rotate weekly between the 5 scanners that I use for alternate opinions) It basically gets a full scan every other day with a different product. (Malwarebytes, Avira, Avast, Super Antispyware, A2 Free)

So I feel that my security regimen is stringent enough to keep my system clean and that anything detected in my restore points is a false positive and can be safely ignored. Your mileage may vary. :wink:

Thank you for your advice.

In a 30+ year career successfully designing real-time embedded software systems to protect nuclear power installations from fire and intruders my principle concern has been to ensure fail safe / roll-over that survives failure of components, equipment, and mains power supply.
I was always confident of my precautions against “Murphy’s Laws”.

I never had to deal with deliberately malicious and constantly evolving malware, hence I do not have the confidence to be the first one to abandon any generally accepted precaution, but I am quite happy to follow in your footsteps and to exclude system restore files.

My mileage has been that the only malware that CIS found was NOT present when the system was scanned as part of installation of CIS on 1st August, but some weeks later AV denounced
C:\Windows\system32\closeapp.exe, and because I was on a long coffee break it took default action.

Somewhat later another scan reported an instance of closeapp.exe within System Restore.
The only thing that could have placed it there was the normal Windows action when CIS deleted a virus.

CIS has never found anything other than this one instance in System Restore, and it was only there because CIS actions had put it there. N.B. I consider it a F.P. because that *.exe has been present a long time, and it was only a recent signature update that flagged it. It is not disguised - its name indicates it is powerful and should be used with care.

Regards
Alan

However you cannot rule out the possibility a System Restore point was made during the long coffee break. Did you check whether there was a restore point made during that time?

http://www.daveamenta.com/wp-content/uploads/2008/05/recycle_bin_full.png
That entry pertain Windows Recycle Bin and its corresponding folders on each disk.

Eric

I agree that a restore Point could have been created whilst I was not looking,
BUT I have observed that every time one is created it starts with registry hives only,
and the A0???.exe etc files are only added at a later stage when :-

  1. The original file is being modified (altered / deleted) ; or
  2. The file is selected and the context menu is launched so I can view the properties,
    in which case on rare occasions XP will get jittery and panic, and lock me out for many seconds whilst it frantically copies the file to the restore point structure just in case I am about to modify that file.
    I think this is a function of Windows File protection for “registered” files.
    e.g. I have just launched the context menu for the largest file in Windows\sytstem32\dllcache
    hwxjpn.dll = 13,463,552 bytes; modified 14/04/2008 05:39:40
    and the current restore point immediately received
    A0273745.dll = 13,463,552 bytes; modified 14/04/2008 05:39:40
    The long lock-out is noticeable with very large files.

I am satisfied that after a virus signature update an innocent C:\Windows\system32\closeapp.exe became branded as a virus, and either as a result of default actions during the scan, or default actions when I inspected the results and took over 120 seconds because the “help” system lost me in cul-de-sacs with the BACK buttons disabled, one way or another, that file got deleted and re-appeared in the restore point system.

Unrelated rant must let off steam :-
That hwxjpn.dll is unadulterated pure M.S. bloat, properties => comments describes it as
Microsoft Japanese Handwriting Recognizer
It is unusable bloat that wastes 34 MBytes. It exists in dllcache and also servicepackfiles\i386\lang
plus another 8 MB compressed variant in C:\I386\LANG, but it is not in system32 or any other location that normally holds executables ready for action.

Regards
Alan

Endymion

I agree with your explanation.

What I intended, but badly expressed, was the view that should an *.exe file be deleted it may become relocated to the Recycle Bin (option for both FAT32 and NTFS) or a Restore Point (option restricted to NTFS).

Regardless of whether it is in the Recycle bin or a Restore Point, and regardless of any name change :-

  1. A double click will launch it, and it may deliver the damage it was designed for ;
  2. It will be immediately restored to its pre-deletion folder when the appropriate restoration is performed, so all its “helper” files will be there as well, and any hacker using a back-door can still find it and launch it.

It seemed to me that the hazards of a virus are the same whether it is in the recycle bin or restore point,
and therefore it is inconsistent to exclude the recycle bin and include the restore points as items to scan.

I am happy to follow HeffeD and be consistent, disregarding both recycle bin and restore points as items to scan.

Regards
Alan.

Not sure what is your point so I might state the obvious again.

System restore folder is not featured in AV exception list and thus it is scanned.
"?:\Recycle?* featured in the exception list do not pertain System restore.
File in the recycle folder are usually placed there as a result of user manual deletions if recycle bin default "Do not move files to Recycle bin " is left unchanged.
File in the recycle folder cannot be executed due to windows design behavior.
When the AV detect a malware removal actions will not move the file to the Recycle bin folder.

Assuming the user who manually deleted a file would like to recover it back from the Recycle bin s/he ought to get an AV alert provided s/he didn’t previously manually exclude it before deletion (eg some riskware app like mIRC the user intentionally installed)

Otherwise s/he might not get alerted for a recycled file awaiting permanent deletion by emptying the Recycle bin.

Exactly, they are different animals but hold the same malware threats,
and CIS is inconsistent when it treats the same threats differently depending upon the “container”

Assume that Program Files contains a folder I no longer require and I choose to delete it.

If I allow the default action of deleting to the recycle bin then this folder, with any malware contents, will go into the recycle bin.
If instead I never want to see it again I can forbid the recycle option and insist upon a total deletion, in which case System Restore may intervene and preserve it as A0???.exe in the current Restore Point.

The malware was present before its signature was known.
If a new signature database update is able to identify it then upon the next A.V. scan :-

  1. If it is held in "?:\Recycle?* then it will NOT be scanned nor detected, and no actions performed ;
  2. Otherwise being in a restore point it WILL be scanned and detected, and removed / quarantined / etc. ;
    I consider CIS to be inconsistent.

If a user forgets (or was not aware of) this recent virus status, but wants his application back,
then an appropriate action can :-

  1. restore the folder from the recycle bin ; or
  2. put back the whole system to the previous restore point.

If the folder is retrieved from the recycle bin, it will still have an active virus for which no warning has occurred,
but the next scan should give a virus warning.

If retrieval was from a restore point the virus will NOT be present if it had been removed, but will be present and active if it had been ignored or quarantined,
and the old signature database will have been restored so there will be no virus warning.

Regards
Alan

I still fail to see your point even though it appears that Recycle bin is treated differently from System Restore (SR).

Even if both can store inactive samples windows and the user itself manage them differently.

Recycle bin repository is directly controlled by the user who supposedly delete thing he is aware and intends to.
Users are more likely to purge the whole recycle bin after a while than purge the SR repository at all.

On the other hand, In addition to the fact SR repository is retained for usually long times, generally SR is carried automatically and the user has no control, nor is aware, about what is actually saved in a restore point.

BTW It might be appropriate to point out, for example, that CIS AV database updates will be retained even after a SR rollback. SR do not backup nor restore them.

Whenever the user forgets or not, the real-time AV will scan SR repository and make him/her aware of potential threats, hopefully before s/he even feel compelled to rollback a previous restore point, and let him remove it without having to purge the whole SR repository.

In case of Deleted files in Recycle bin folder, the real-time AV will make the user aware of an eventual threat in the event s/he feel the need to revert the deletion as opposed to his/her initial intentions.

AFAIK having the AV scan the Recycle bin has no practical advantage though it might trigger alert for deleted riskwares the user previously used after placing an entry to their installed path in the exclusion list.

Removing ?:\Recycle?* from AV exclusion would make necessary to manually exclude each of those files as well requiring an appropriate number of exceptions related to recycle bin folder.

I would assume nobody would like to be altered for a classified file s/he is aware of and intended to delete.

Thank you. I was focussed upon the difference between how CIS treats malware in the Recycle and Restore systems,
but I accept your point that the User has far better control over the contents of the Recycle Bin

My bad. I was forgetting the S.R. distinction that excludes “User Data” from its jurisdiction.
In my defence it is a blurred line that confuses Microsoft -
before I go back to a previous date I first have to run CCleaner to purge from my private user profile the Firefox cache, otherwise when S.R has done its best I have both “…\cache” and “…\cache(2)” and some sort of explanation that one was the old preserved version and the other is what had been the current version. If Microsoft are unsure what is or is not User Data, what hope have us lesser mortals.
n.b. My wife and family are sure I will never die for lack of an excuse ! ! !

I would expect a similar AV warning if malware was resurrected from a Restore Point.

Thank you for your explanations. I am now satisfied.

Regards
Alan

There is a SR Monitored File Name Extensions list that mention what file types are protected.
There is also some info about how SR behave on different versions.

Threats ought to be detected as soon the AV is active though AFAIK alerts can only be displayed after welcome screen.

To actually test what happens an harmless testfile like eicar.com could be used.

Though deletion before restore rollback looks like the most compatible approach whereas not long ago it appeared that purging the whole SR repository was the only option.