Most of the cases the root problem of a successful 0-day infectino is that the very first piece of malicious code (most likely a downloader trojan) can successfully communicate to it CC (command and control centre).
Webroot today has a default allow action if user does not block via this popup window:
First of all: surely, admins never like the idea of giving such control to the user. User will never know the exact risks of clicking the Allow button here. When he clicks, it is already late to save the network from harm. Please refer to many many Cryptolocker cases around the Globe.
Secondly, the countdown counter here gives you 120 sec to decide. Who among the users can get proper help on what to click here in just 120 sec??? Who is that admin among us who could properly check this unknown process out it at the endpoint and advice in just 120 sec? (Anyone yes - I would employ you tomorrow and we will make big money... )
(please also read this idea - it might work in some cases:
Thirdly, actually, I have never seen any firewall (perimeter or personal) that has a "default allow" implementation. Eversince we have communicating systems we all learnt quite well: for any unknown process the only safe action is to block its communication, isnt' it? (Please note, blocking unknown processes' communication will not have any effect on known good processes.)
Sure, Webroot, you might say that implementing this could result in blocking too many legitim processes, but hey, this is your constant job to classify new processes and as quickly as you can and we purchase a WSA licence it means we do trust you can do this mandatory job for us, for our safety.
Also, even without your expert job (and cloud database updates), local admins could easily deal with those untrusted processes whose communications were blocked via the Admin Console, so they could easily classify any unknown process as "Good" if need be.
Dealing with some bloked communications is (to my opinion) still much better staff then dealing with tons of encrypted files... and neverending ransomware infcetions are just about to teach it for us all.
So why nort let us stay on the safer side?
WSA 6500+ endpoints inatalled and maintained daily, 12+ years Webroot sales & support, 2 yr Webroot MSP
The Webroot File Submission site (http://snup.webrootcloudav.com/SkyStoreFileUploade
To allow better access to it I would like to suggest that a link to the site is added to the WSA local client; either as a button under the 'Support/Community' tab or the 'Utilities' tab, so that in much the same way as the 'Support' button takes the user to the site directly to open a support ticket, so this would take the user to the File submission site and give them immediate access to:
1. File submission
2. MD5 Hash lookups
3. URL Reputation lookups
As such it should not add very much in terms of additional code to the installer and would provide further useful tools for the user to readily use.
How about the ability to have the Community login credentials the same as the Console login credentials? Since there is a link to go from Console to Community, I assumed I would already be fully logged in. This is not the case.
When Trojans get downloaded they are currently a) scanned by WRSA and b) may be further scanned by the user with a manual scan. On both these actions WRSA does not quaranteen these files because they are not considered active malware, according to your researcher Dan. I have checked more than 20 such files via Virustotal and not only ESET, Kapserky recognise them as Trojans but even the lowly Windows Defender. Of all these Trojans across 2 weeks, WRSA did not alert when downloaded not afterwards manually scanned, they were passed as OK.
Because the files may have been scanned twice, the average user is going to believe those files are OK and clean according to WRSA and they may pass them on to someone else in their business workflow or to a friend when in fact those files contained malware. Those files can then wreak havoc on another system that is not protected by WRSA.
Fundamental question and request: Upon download and manual scan WRSA is most likely checking those files against an online databse, so why not immediately quaranteen such suspect files or at least alert the user there may be a risk?
Can WRSA deal with such files immediately, using your own online lookup or add the feature to compare on Virustotal.
Thanks for your consideration
When visiting security websites websites that deal with proxies, anonymizers, VPNs, TOR, etc. Webroot blocks these websites with the usualy warning.
In Search Engines they get the "Reputation: HIGH RISK - When Visiting this website there is a high probability that you will be exposed to malicious links or payloads."
When visiting the sites the message is "Suspicious attack ahead. Webroot has blocked access to the website you tried to open. It has been reported to contain suspicious content."
For many of these sites, this warning is completely innacurate. The sites themselves are trustworthy, particularly websites like torproject.org which are highly reputable website/project run by a registered 501(c)(3) US non-profit organization.
When reporting this issue to Webroot, I've been informed that "Tor is flagged because it is a proxy that many admins would not want employees using. We have no plans to change this."
If Webroot has no plans to change this, I would like to propose that you change the way users are warned about these sites. Add different kinds of warnings that specify in more detail why the site is blocked. For example "This site contains content that may be offensive to your network administrator."
As it is, I, and I'm certain other webroot users, are in the habit of simply clicking "ignore" (more specifically, "tell me more about it" then "unblock page and continue") on every security oriented website that brings up this warning (I've seen it on security oriented news sites as well). The problem with this is that we are being forced to do this blindly. We have no idea if Webroot has blocked the website because of the content, or because it may actually contain "malicious links or payloads." Essentially, by being over-protective, webroot has become less effective in protecting us.
Please provide warnings that specify why a website is blocked. That way users can make an informed decision about whether or not they want to continue...
I (or rather my wife) recently had the issue described in this post. Basically, she changed her SIM card while abroad and the SIM card lock kicked in. when she tried to unlock, no keyboard would appear. I then learned that it's because the phone needs a data connection before unlocking is possible. There was no explanation of this from the phone itself, and I had to ask the community here to get an explanation.
My suggestion is to include a text message in the lock screen in such a case, saying something along the lines of 'It isn't possible to unlock this device at this time because no network signal is available.'
Just a quick question and nothing major.
Although when deleting Private Messages we are asked to confirm the deletion etc. when there are quite a few to delete it is very easy to acidentally delete one which you wanted especially if your housekeeping is not perfect.
Is there any way to protect certain ones from deletion as in locking them which we can do with text messages in mobiles phones.
I am sure I am not alone in accidentally deleting ones I wanted saved.
It would be usefull to me if WSA was able to generate events in the windows event log. It would make it easier to create scheduled tasks or incorporate data into a SEIM.
'Windows allows applications to report their own security events to the security log by registering through Authorization Manager with LSA as a security event source using the AuthzRegisterSecurityEventSource function. "
i. lptemp language files in temp folders. Reference: https://community.webroot.com/t5/Webroot-SecureAny
ii. Renamed, over time redundant WRkrn.sys files in Drivers folder. Ref: https://community.webroot.com/t5/Webroot-SecureAny
Any other files or remnants etc. which may also be reasonably included. Suggestions and additions welcome.
I am not sure how I would envisage achieving this, but ideally it would be optional, perhaps as an addition to the Optimizer, but that would exclude users not running the appropriate version of WSA.
Just a little idea I had looking at my keycodes as you do.
I am sure some of you have a lot of keycodes in your consoles. I for one dont have too many but I have a few, and somtimes I cannot quite remember which one goes to which so I end up going back and forth to try and locate and place each one.
My idea is to have another colum in the Manage Keycodes page to add a identifyer which the user or admin could change to help them remember which code belongs to which device. Such as "Gaming PC" "Laptop" "Tabet" "Phone" or whatever, you get the idea
What do you guys think?
Let's say a thief steals your phone, as phone thiefs tend to do. One of the first things they will do is turn the device off to help keep the product from being tracked, just in case. Once they get home or whever they want to toy with the phone, they will have to turn it back on to try to unlock the device or factory reset it.
Therefore, I would like to see Webroot SecureAnyhere upload the location of the device to the users Webroot account whenever the device is turned on or off. That could potentially be the one difference in locating a stolen device.
This enhancement/suggestion is certainly not necessary but would be helpful in certain situations.
By adding a more simple method to filter the viewing of the Active Connections and Active Processes, it would simplify and speed up the process of viewing (ONLY) those in a blocked or monitored condition.
While the current screens provide the above-mentioned information it is a bit unwieldy when forced to scroll through many lines of information while looking for blocked or monitored conditions. Sometimes an active process or connection is temporary and if you don’t catch it quickly while it is being executed, you can miss out on valuable troubleshooting information.
This would be most helpful to the non-techie user who is probably overwhelmed by the amount of information on the screen when trying to troubleshoot if WSA is preventing their application or function from working properly.
Whilst not a feature of the software itself, it cropped up in discussion (https://community.webroot.com/t5/Security-Industry
So a couple of us were wondering why this would be the case and would it not at last look better if the green padlock showed up immediately. I realise that as soon as you progress into the main site as far as inputting any data, then the padlock duly appears but the initial lack of a padlock may put some potential customers off.
There may well be a good reason for this but it would be nice to know what it is.
I reported a conflict and was asked to post this here so here is my original message: "I have been noticing a conflict between the webroot filtering extension and the ublock origin extension. I was experiencing extreme lag and slow load times until I disabled the ublock origin extension, which is unfortunate because I would prefer to use it instead of adblock or another adblocker. I mainly wanted you to be aware and hopefully something can be resolved with this."
When one clicks links in the GUI, for example the Submit Sample button or Get Customer Support, a lot of important info is inside the URL. I haven't been able to determine exactly all that is being sent, but I do see the persons email address and some kind of license ID.
Apart from the fact that this information can be intercepted easily, people may also post their links publicly, unaware of the fact that it may contain sensitive information.