How to have Webroot to do a FULL scan on all endpoints in the Management Console? (Sality infection)

We have Sality infections spreaded over 350+ endpoints.
Webroot support simply suggested to re-image endpoints - which is obviously the latest thing we want to do.
Some endpoints (the file servers and some clients) we cleaned with ESET/Kaspersky boot CDs. ESET/Kaspersky found 100-600 infected files per endpoint, one files server had 68.000+ infected files that Webroot did not find!
but still the company cannot work as infected endpoints reinfect file shares, and then from file shares even cleaned PCs got reinfected again. We use Webroot on the servers, too, and it does not stop reinfection of shared folders!
We think maybe we should do a full scan with Webroot on all endpoints, but we cannot see any agent commandfor that in the console. How could we command Webroot to do a FULL scan on all endpoints in the Management Console?
Any other idea how to get rid of Sality?

16 replies

Userlevel 3
Leaving aside that Webroot does not use traditional definitions (using file reputation from its online database and behavioural monitoring instead) could any AV not claim the same I.e real time protection combined with heuristic analysis negates the need for full scans ?
Userlevel 7
From our Enterprise Support Team:
The Webroot agent does not rely on traditional definitions to make its’ determinations. The existence of any particular file is less of a concern than the file's behavior and how it interacts with your system. Therefore, only files that present risk are currently active and are examined during the scan. This is one of many ways Webroot is able to keep a small footprint concerning resource usage on the end machines. If a file is dormant but for whatever reason becomes active while a scan is not taking place, Webroot's advanced heuristics involved with our Real-Time Shield should catch this behavior and prevent any malicious behavior/actions from taking place.
At this time there is not a method of initiating full scans from within your console, only the option to "Scan a Folder". This option at this time will not recognize "C:" as a folder; however, some specific folders would need to be in place if you decided to go this route. This Agent Command would be located within your Group Management tab of your Endpoint Protection console. More on Agent Commands can be reviewed here.
When it comes to frequency of scanning, the agent performs this action on its’ own once a day unless otherwise specified within the policy settings (More on policy settings can be reviewed here). You can, however, adjust the poll frequency to be a little as every 15 minutes to have the agent check into your console more frequently for any additional policy changes or commands sent, including additional scan commands. With this said, our Real-Time Shield is consistently running around the clock to keep the system protected between scans while working alongside the additional protection coming from our Web-Threat Shield, Firewall, and Identity Shields.
I found this (old) thread looking for the same answer to GyozoK's original question: how can I initiate a full scan on all of my endpoints? I'm hoping Webroot could help close this thread out with a slightly more detailed explanation to benefit other future Webroot customers who find this thread as I did.
The Webroot response I see indicates that initiating a full scan of all endpoints is not available by design, and that it's a matter of not enough resources on Webroot's end to handle this kind of bulk processing request. OK, let's accept that for the moment.
If manually initiating a full scan of all endpoints is not an available option, is the original line of thinking here flawed? Put another way, is there ever a need to initiate a full scan of all endpoints? Unless explained otherwise, GyozoK's reasoning makes sense to me: he's wanting to be reassured about whether a currently-known threat still exists in his environment.
I'm looking for Webroot to explain, not just from a technical reason as to why ("there aren't enough resources at Webroot to support this") but from a security standpoint as to why this is not a necessary feature for your customers.
Hey, come on, I bet you must be joking!
So do not scan for malware just because Webroot's resources are not enough out there??!!
Ooooh! Now this is not only technically, but also as marketing message would hurt your good recognition on the market.
So, guys, why do not you just go and invest more in resources so to allow your customers do malware scans?
Nothing is impossible, take a lok at Google's clusters...
Userlevel 7
Badge +56
There isn't a way of doing that, and I'm told it's by design. If you kicked of full scans on a whole bunch of systems at once then it would be a huge load on our servers, so we only allow you do it from the individual client for that reason.
Thank you nic for this many  information about Sality, I think I already got enough details of letting me know that this is unremovable for 100%, so let's not waiste any more words on this, please.

Rather, could we focus on my major question, the title of this post, please, as no words I got about that so far:
How to have Webroot to do a FULL scan on all endpoints via the Management Console?
Userlevel 7
Badge +56
It's not that we won't remove stuff, it's just that Sality is the kudzu of malware infections. There aren't any good tools to remove it that anyone makes, as far as we know.
?: "We're a prevention tool, not a remediation tool for a pre-existing infection, unfortunately...."
A customer who switched from another AV to Webroot, he switched _because_ he was not happy with that old AV. And he was not happy _because_ he got infected and could not remove the malware (Sality). So now he expects his new AV (Webroot) will do this job.
In other word, the customer was not about to switch AV until he found out that his that old AV (Panda) was bad at malware protection.
So, I can get your point that "we're a prevention tool, not a remediation tool for a pre-existing infection, ", but unfortunately this is not what the market needs (at least not those who switches AV - and frankly speaking only new companies may not swith AV, all others have something to switch from). Btw, Sophos had the same approach in the early 90's, they did not even had a removal functionality, only blocking in real-time. B ut once a malware could get through, you had no chance to remove. They said: "install Sophos on clean endpoints and then it will protect you". That turned out to be a bad approach years later: the market needed removal tools.
Yes, Sality was tere before WSA.
Hi Rocky,
Sure, it is easy: we did FULL scan manually using the client UI on some machines, but I want to do FULL scan on ALL endpoints NOT manually (initiated from the console). :)
Hope this helps.
Userlevel 3
? Could you clarify if the Sality infection pre-dates the installation of Webroot ?
Userlevel 7
Badge +56
To be fair, I doubt any other AV will clear Sality after the fact either. The remediation tools against this one aren't 100%. Same with rootkits - if you already have one, then installing an AV isn't going to help you. If you don't prevent some infections, there is no remedy other than a reinstall.
Userlevel 3
Concentrating on core competency seems an appropriate policy but , with respect, if prevention is the core competency should Webroot not really then be seen as best suited to operate in conjunction with another AV solution rather than as a full solution in its own right ? I can see where Gyozo is coming from.
@ GyozoK - your points are well made . One thing I don't understand - you say you found that Webroot findsmore infections on a Full scan rather than a DEEP scan but then ask for instruction as to how to do a FULL scan . I am not following what you are saying - how can you know about the results of a FULL scan without knowing how to run the full scan ?
Userlevel 7
Badge +56
We're a prevention tool, not a remediation tool for a pre-existing infection, unfortunately.  That's why we recommend other tools for the situation you're in.  We specialize in the former as that's our core competency.
Hi nic,
Thank you for taking care indeed!
All this sounds very bad, of course.
Re-imaging actually would mean that we have to re-image the whole office (including many servers and ~400 endpoints).
I expect Webroot support / threat research team to give more feasible advices.
Firstly, the very first task to do for an AV supporter is always: STOP MALWARE PROPAGATION.
So instead of talking about where WSA is week at and giving us 3rd party utilities, rather Webroot should explain us the ways Sality propagates / infects new files and how to block them doing it.
Eg. I experienced that Sality creates an autorun.inf file in the root dir of every network dive (mapped shared folder). Then an endpoint can get infected by simply the user opening that mapped drive in Explorer (when autorun.inf starts Sality in the background). So we can block this way of propagation in 2 ways:
a. disable autorun.inf execution on every endpoint
b. WSA client shall block creation of autorun.inf files pointing to malware (on the servers that are protected (?) by WSA)
So regarding point a., Webroot Support should have taken a look at our console to find out that we have Windows XP + Windows 7 desktops and Windows 2000, 2003, 2008 R2 servers running. They shall be able to check it in 1 minute in Group Management. After that, Webroot Support should have sent us this article in order to give advice how to disable autorun on endpoints:
Regarding point b. Webroot shall double-check if WSA client can block creation of autorun.inf files pointing to malware or not, and if not, they shall develop this, or basically, they could develop a "Block aurtorun.inf files from execution". Both feature can be solution not against Sality, but basically all the malware that try to propagate the same old-school way using autorun.inf.
So the above was steps Webroot support should have adviced at least.
Then again, we wanted to do a FULL scan on every endpoint via the console. I did not find out how to do it, so I wrote this question here. I still have no answer: how can we do it? Can anyone tell it, please?
This very is important, because we found that WSA finds and quarantines many infections if we do a FULL scan, but does not find any if we do a DEEP scan. So DEEP scan is not enough. We plan to remove as much malware as we can, and disable autorun.
Obviously, we think that new infections may not be anymore, as WSA is installed and protects yet uninfected files, doesn't it?
So we shall find files infected before WSA installation, and maybe reinstall some apps only.
After all, I expect Webroot Support really think about our situation much more parctically, and let us know all the ways of propagation + advice how to block that with Webroot or any other way + how to remove existing infections.
Can you talk to Support, please?
Userlevel 7
Badge +56
I went down and chatted with the support folks on this one to get a good understanding of the issue.  I'm assuming the Sality infection pre-dates you installing Webroot?  We're good at preventing it, but we're not the best remediation tool for after the computer gets infected.  In the case of Sality, there are some removal tools that our support folks will recommend, but they're hit or miss.  And if you managed to clean 349 endpoints and one of them isn't properly cleaned, the it will re-infect all the other machines on the network and all your work will be in vain.  Which is why support is recommending re-imaging everything as the best approach.  If you do want to try removal tools, here's what our threat researchers recommend as the best ones for Sality:
Again, as to whether these tools can get 100% of the infection off of 100% of the machines, that's not guaranteed.
Also the reason Webroot doesn't find all the infected files is that we stop scanning after we encounter Sality, as continuing to scan just helps the infection to propagate further.  At that point Webroot notifies you that the infection is present, but then stops to let you decide how to proceed.  Hope that helps!


    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept or continue browsing you agree to our cookie policy. Learn more about our cookies.

    Accept cookies Cookie settings