This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos cleaning

Any suggestions as to why Sophos can't clean a user's recycle bin, appdata (also local appdata), and areas where temp internet files are stored under the user?

Thanks.

:44907


This thread was automatically locked due to age.
Parents
  • Hello LimonPaani,

    thanks for the examples. It's not the areas but the threats - that they are in specific areas is part due to the nature of their "vectors" (e.g. the .js and .php files in a browser's cache). The items in the $Recycle.Bin have either been deleted or put there by the malware (yes, it is possible to use $Recycle.Bin like any other location).

    Cleanup unavailable

    Just what it says - it's not feasible to reliably remove just the offending code (or a dependable cleanup routine has not yet been written - you wouldn't want that the publishing of a detection is delayed, and you are therefore unnecessarily exposed, just because the cleanup routine is not yet completed). If the alternate action is Delete (use with caution!) the entire file will be deleted. Clean means either remove the threatening part and leave the rest intact or delete the entire file - the latter is not automatically done for "generic" detections though.

    belongs to adware or PUA 'SAHAgent'  

    Adware and PUA is a specific class of (potential) threats, please see the Overview article. They will not be automatically cleaned up by on-access.

    If the user's permissions apply then how do we proceed to correct them

    There's nothing to correct - if a user attempts to execute some malware from a location he's not permitted to write to the file can naturally neither be cleaned nor deleted under the user context. Or a yet unknown malware might modify the permissions of its components (or other malware it downloads) to prevent deletion by the user.  

    As far as I can see, everything is working correctly. Many of the threats which aren't cleaned up need a certain context to execute (this applies e.g. for all the stuff in the browser's cache). As long as on-access is functioning correctly these "leftovers" pose no risk - if it isn't, you must be much more worried about "new" threats coming in undetected than some residual accidentally getting activated. Except for a few exceptions you can delete the stuff either with an "aggressive" on-access setting (not recommended) or a scheduled scan.

    Christian

    :45159
Reply
  • Hello LimonPaani,

    thanks for the examples. It's not the areas but the threats - that they are in specific areas is part due to the nature of their "vectors" (e.g. the .js and .php files in a browser's cache). The items in the $Recycle.Bin have either been deleted or put there by the malware (yes, it is possible to use $Recycle.Bin like any other location).

    Cleanup unavailable

    Just what it says - it's not feasible to reliably remove just the offending code (or a dependable cleanup routine has not yet been written - you wouldn't want that the publishing of a detection is delayed, and you are therefore unnecessarily exposed, just because the cleanup routine is not yet completed). If the alternate action is Delete (use with caution!) the entire file will be deleted. Clean means either remove the threatening part and leave the rest intact or delete the entire file - the latter is not automatically done for "generic" detections though.

    belongs to adware or PUA 'SAHAgent'  

    Adware and PUA is a specific class of (potential) threats, please see the Overview article. They will not be automatically cleaned up by on-access.

    If the user's permissions apply then how do we proceed to correct them

    There's nothing to correct - if a user attempts to execute some malware from a location he's not permitted to write to the file can naturally neither be cleaned nor deleted under the user context. Or a yet unknown malware might modify the permissions of its components (or other malware it downloads) to prevent deletion by the user.  

    As far as I can see, everything is working correctly. Many of the threats which aren't cleaned up need a certain context to execute (this applies e.g. for all the stuff in the browser's cache). As long as on-access is functioning correctly these "leftovers" pose no risk - if it isn't, you must be much more worried about "new" threats coming in undetected than some residual accidentally getting activated. Except for a few exceptions you can delete the stuff either with an "aggressive" on-access setting (not recommended) or a scheduled scan.

    Christian

    :45159
Children
No Data