Through testing some "unknown to Webroot (or any other AV)" malware, I feel WebRoot may be insufficient protection for my clients. By allowing untrusted code to run, it seems a lot of ransomware can get through without a lot of difficulty (the first ransomware-as-a-service a colleague tried with Webroot was successful while other well known competing AVs were able to block it with their own heuristics. Webroots heuristics were turned to max also.
While it might be possible to do rollback, WebRoot doesn't do rollback on network drives and unknown applications are allowed access to these resources. Since this is often deployed as a business AV solution, this is unacceptable.
Is there functionality in WebRoot currently, or that could be easily added to straight up block execution of unknown executables (as a configurable option of course) -- ideally whitelisting anything SIGNED by a trusted entity (eg. Microsoft)? Or is there a way I can already do this?
I know that I could use SRP in Windows, but I feel this would be better handled within Webroot since it already has such a vast intelligence pool of known good and bad hashes. Also SRP may be deprecated in future releases based on notes in Win 10 1809. And Applocker requires Windows 10 Enterprise, an expense many businesses are unwilling to budget for.
Thanks in advance for either a configuration setting that would allow this, or to have this feature added to your roadmap.
Solved
Block execution of unknown software
+3Best answer by coscooper
There is a feature within the Heuristics area that you can apply to do what you're suggesting. In the Heuristics area you can change the setting to "warn when program launches that's not known good", in effect making it a whitelist function. However, it is a warn so the user can still make a choice.
There are two caveats:
1 - it is vector by vector, meaning you'll have to set this setting on each watched area, like USB etc...
2 - it's a warning popup and the reason is so in the case of a line of business application that is not known to our threat data a user can allow it to run, otherwise, if it was hard set to "always" block unknowns, there would be a higher level of false positives.
NOTE: The Webroot agents heuristics are behavior based and being agnostics take an innocent until proven guilty approach. If you're interesting in more details regarding your test results, you can supply the "files" in question to our threat team for analysis. It could be that the files were detected as benign based upon fake internal content code and the binary was targeted as such in our threat data, meaning our agent saw it as non-malicous.
There are many reasons why the WR agent may have ignored a file, which may require a more in depth analysis with our team.
If it was in an isolated computer and your testing team threw real malware at the agent, then a conversation with our threat team would be helpful for everyone.
HTH
+3Some addition details-- I mean that the existing whitelisting functionality gets trusted publishers added to it as well- to avoid common software getting borked by a "Block all untrusted executions" policy being enabled. Then an untrusted event could throw an alert (like a virus detection would) and an admin could go into Webroot cloud console, and whitelist either the executable itself or trust the publisher (if it's signed). This sort of a feature set would/should make Webroot nearly bulletproof assuming it has good malicious script detection (eg any script that is obfuscated is considered untrusted and must be whitelisted, and whatever other common tricks could be added if they are not there already).
The sample malware didn't require elevated permissions/UAC to run in my colleague's test case, nor did it require Internet access (so it didn't show up in Webroot's firewall list).
The sample malware didn't require elevated permissions/UAC to run in my colleague's test case, nor did it require Internet access (so it didn't show up in Webroot's firewall list).
+26There is a feature within the Heuristics area that you can apply to do what you're suggesting. In the Heuristics area you can change the setting to "warn when program launches that's not known good", in effect making it a whitelist function. However, it is a warn so the user can still make a choice.
There are two caveats:
1 - it is vector by vector, meaning you'll have to set this setting on each watched area, like USB etc...
2 - it's a warning popup and the reason is so in the case of a line of business application that is not known to our threat data a user can allow it to run, otherwise, if it was hard set to "always" block unknowns, there would be a higher level of false positives.
NOTE: The Webroot agents heuristics are behavior based and being agnostics take an innocent until proven guilty approach. If you're interesting in more details regarding your test results, you can supply the "files" in question to our threat team for analysis. It could be that the files were detected as benign based upon fake internal content code and the binary was targeted as such in our threat data, meaning our agent saw it as non-malicous.
There are many reasons why the WR agent may have ignored a file, which may require a more in depth analysis with our team.
If it was in an isolated computer and your testing team threw real malware at the agent, then a conversation with our threat team would be helpful for everyone.
HTH
+3WR detects it now, so it just took a while to do the determination. I'll generate a new custom malware and re-test with some of these settings. Thank you for your response!
If I set the "warn when a program launches that's not known good" along with "apply default without asking user" (I forget where I saw that in policies but the way it looked was that it would default to the 'safest' behaviour without interacting with the user -- will that block unknown exe's by default until webroot has had a chance to analyze them? Will I get a notification so I can whitelist that particular file? Is webroot smart enough to auto-whitelist windows/windows updates etc so that I can use a configuration like this would boning/bluescreening an endpoint?
Also question on the vectors, are they applicable to the current location of the file or it's SOURCE? So if I copy a malware from USB to the desktop, does the USB vector still apply or is that now "local"? Similarly, something download from the Internet I assume falls under the Internet vector? So I could set block by default for anything from the Internet/USB but leave local stuff alone? (and if I push out LOB apps via RMM or GPO, would that be considered local?)
Thanks!
If I set the "warn when a program launches that's not known good" along with "apply default without asking user" (I forget where I saw that in policies but the way it looked was that it would default to the 'safest' behaviour without interacting with the user -- will that block unknown exe's by default until webroot has had a chance to analyze them? Will I get a notification so I can whitelist that particular file? Is webroot smart enough to auto-whitelist windows/windows updates etc so that I can use a configuration like this would boning/bluescreening an endpoint?
Also question on the vectors, are they applicable to the current location of the file or it's SOURCE? So if I copy a malware from USB to the desktop, does the USB vector still apply or is that now "local"? Similarly, something download from the Internet I assume falls under the Internet vector? So I could set block by default for anything from the Internet/USB but leave local stuff alone? (and if I push out LOB apps via RMM or GPO, would that be considered local?)
Thanks!
+26Heuristics are source based, so copying from USB would be based upon USB settings, but also as a backup, the realtime scan on write will kick in as well IF the source check was passed for some reason.
+8I'm curious about your claim that "a lot of ransomware can get through without a lot of difficulty."
We've been running on well over a thousand endpoints worldwide for a couple of years, including MANY users who don't practice "safe computing" at all. Not a single ransomware issue.
Your test is vastly unrealistic: since when would "a lot" of ransomware target network drives before attempting to touch local files? That's highly unlikely, to say the least.
What we've seen: ransomware crunches through local files, typically to the exclusion of anything else (because it wants to remain hidden the entire time it is "preprocessing" files!)
It's true: if one is concerned about such a highly targeted form of malware, it would be best to ensure a higher level of protection, including in particular very good backups for all network file resources.
However, I would challenge you and your team to come up with a realistic context that matches the malware scenario you've created.
We've been running on well over a thousand endpoints worldwide for a couple of years, including MANY users who don't practice "safe computing" at all. Not a single ransomware issue.
Your test is vastly unrealistic: since when would "a lot" of ransomware target network drives before attempting to touch local files? That's highly unlikely, to say the least.
What we've seen: ransomware crunches through local files, typically to the exclusion of anything else (because it wants to remain hidden the entire time it is "preprocessing" files!)
It's true: if one is concerned about such a highly targeted form of malware, it would be best to ensure a higher level of protection, including in particular very good backups for all network file resources.
However, I would challenge you and your team to come up with a realistic context that matches the malware scenario you've created.
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.