Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 12489 views
  • Users 0 members are here
Options
Suggested
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

Unable to delete threat due to on-access protection

Incoloy

This qusetion is in an office setting.

A lot of times when a threat is identified by Sophos, it is unable to cleanup automatically. A manual clean up (delete the file) is required. However, when I try to delete the file, Sophos does the on-access scanning and blocks the delete too!

What is the best and recommended way to delete the file?

I know I can go to the endpoint and disable the on-access on the client machine, but I prefer to be able to remotely access the infected computer, navigate to the threat location and simply delete it. All from the comfort of my desk.

Can someone kindly give me some advice? Thanks.

:53889


This thread was automatically locked due to age.
Parents
  • 0

    Hello Incoloy,

    What makes you think it **doesn't** block delete?

    First of all: it would be outright stupid to block a delete. Secondly: it works (and always did).

    But - it just occurred to me you might be using the "standard" delete (move to recycle bin). This is not a delete but a move (albeit to a special location) - and therefore is blocked. Shift+Delete (or the shell commands) will not get blocked. Try with EICAR (there's the savtest32.exe tool in the \Tools subfolder of the SEC install folder): Disable automatic cleanup  for On-Access with deny as alternate action, run savtest32 , click Drive to select a convenient location for eicar, then File-> On-Access Test. You should get an alert as well as a confirmation by savtest32 but eicar should still be there. Using a normal delete you'll get Access denied.

    Christian

    :53897
Reply
  • 0

    Hello Incoloy,

    What makes you think it **doesn't** block delete?

    First of all: it would be outright stupid to block a delete. Secondly: it works (and always did).

    But - it just occurred to me you might be using the "standard" delete (move to recycle bin). This is not a delete but a move (albeit to a special location) - and therefore is blocked. Shift+Delete (or the shell commands) will not get blocked. Try with EICAR (there's the savtest32.exe tool in the \Tools subfolder of the SEC install folder): Disable automatic cleanup  for On-Access with deny as alternate action, run savtest32 , click Drive to select a convenient location for eicar, then File-> On-Access Test. You should get an alert as well as a confirmation by savtest32 but eicar should still be there. Using a normal delete you'll get Access denied.

    Christian

    :53897
Children
No Data