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

Is any one else seing this alert - Shh/Updater-B False positives

Virus/spyware 'Shh/Updater-B' has been detected in "C:\Program Files\Sophos\Sophos Anti-Virus\Web Intelligence\swi_update.exe". Cleanup unavailable. This is trickling in as alerts but at an alarming rate.

:29723


This thread was automatically locked due to age.
Parents

  • Azurus wrote:

    jkillebrew wrote:

    Azurus wrote:

    @jkillbrew

    You are correct, but after the script has been run and the issue corrected, it will not detect those 3rd party updaters as malicious any longer. The exceptions are added so you can run the script without re-quarantining the updater upon running the script.

    Once the issues are solved across the board, you can re-enable On-Access or remove the exceptions.


    True, but only way this will work is if you remove the bad definition as part of the script. Some scripts do remove the definition and restart SAV service, and those will work just fine, but those do not restore adobe and other updaters. Scripts that do restore those files do not fix the definition. Maybe I or someone should combine the various scripts together...

    What I mean is shouldnt SAV catch the updater file during the script's process of copying the file back to its original location, outside of an exception folder, such as an adobe updater file?


    The script I have removes the offending IDE, therefor the next access, whether it be from a script or other method will proceed as normal. The script to move files back to their original locations should run after the commands to remove the offending IDE and after getting Sophos back on track.

    Right, so in your case the exceptions mean nothing in the immediate situation. Regardless of whether you put them in, you'd fix the problem.

    There are a few ways to fix this, clearly. We need direction from sophos, something official. We on this forum had at least 4 scripts posted within a few hours after this hit us. I guess we're awesome. High fives all around!

    :31741
Reply

  • Azurus wrote:

    jkillebrew wrote:

    Azurus wrote:

    @jkillbrew

    You are correct, but after the script has been run and the issue corrected, it will not detect those 3rd party updaters as malicious any longer. The exceptions are added so you can run the script without re-quarantining the updater upon running the script.

    Once the issues are solved across the board, you can re-enable On-Access or remove the exceptions.


    True, but only way this will work is if you remove the bad definition as part of the script. Some scripts do remove the definition and restart SAV service, and those will work just fine, but those do not restore adobe and other updaters. Scripts that do restore those files do not fix the definition. Maybe I or someone should combine the various scripts together...

    What I mean is shouldnt SAV catch the updater file during the script's process of copying the file back to its original location, outside of an exception folder, such as an adobe updater file?


    The script I have removes the offending IDE, therefor the next access, whether it be from a script or other method will proceed as normal. The script to move files back to their original locations should run after the commands to remove the offending IDE and after getting Sophos back on track.

    Right, so in your case the exceptions mean nothing in the immediate situation. Regardless of whether you put them in, you'd fix the problem.

    There are a few ways to fix this, clearly. We need direction from sophos, something official. We on this forum had at least 4 scripts posted within a few hours after this hit us. I guess we're awesome. High fives all around!

    :31741
Children
No Data