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.
Hi. I love Webroot's 'set and forget' aspects, but I find the mobile features profoundly difficult to use.
I would suggest a capacity to integrate it with a google app or a browser app on a mobile (cell) phone, or if this is technologically problematic, then a dedicated 'vault' app such that you could enter your 'vault' master password once, and then be able to access individual passwords/sites with ease.
Perhaps it could have a timeout feature.
Perhaps it could have a feature where the most common sites you visit/access have a 'slide out' page with a series of easy finger-width 'tiles' (with each tile a 'button' to select and visit said page).
Taking this suggestion further, if you could have a way of sliding out a page for each of the site categories that you have created, and in this way easily find the relevant site from whereever you have categorised it.
The current 'secure web' app is (putting it politely) clunky, and not so politely...painful.
You have to access the additional menu to find the vault. It's the 5th option in the list, not making it stand out and making it harder to find if you rarely use the secure web app.
You then have to select vault again.
You then fill in your master password.
It then gives you an un-categorised list of all sites in alpha-numeric order only (if you have a lot of stores sites this is frustrating).
Here's where is particularly get's frustrating.
If you simply press on a site, it opens the site on a new tab within the app, it does NOT pre-populate the site login details, and it closes the vault so you can't then readily access the site details you require to login.
If you remember to instead press and hold on the listing of the particular site, it opens a menu that gives 2 options.
The first is to Open the site in a new tab, but again, if you do this, it does not populate your login data, and once again closes the vault so you have to go to an original tab, re-open the vault, view site details, and write the details down (because it will not allow you to copy/paste the information), then navigate back to the recently opened tab and manually enter the data. It is SUPER useless quite frankly.
I have found that occasionally it will open the requested site, and it will fill the required details, but this does not happen consistently, and if it does, there is a profound delay of sometimes 5-10 sec, which in this day and age of tech is a lifetime - you assume nothing is happening, get frustrated, and exit the app.
Also, if you have previously opened another site (as mentioned, this is occasionally successful) and then go back into the vault to open a DIFFERENT site (in a new tab) the app just fails. No indication that it has done anything. No new site opened, no attempt to fill data. Just a return to the Webroot app homepage.
The problem with the second option in the menu is inferred in the previous paragraph. It is an option to view site details, but it does not give you an option to copy the data to your clipboard. Who in this day and age would carry a pen and paper around as well as a phone? Useless and frustrating feature.
I would REALLY love some attempts to improve this app and functionality
As a new member I was nonplussed and disappointed to see that every post on the forum is not date stamped but rather mention being made to 'n weeks ago'. I do find that strange and I personally would love to see the date and time post was made added to the posts.
Having said that I have no idea if it is even feasible!
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...
Request a "Console Tree" on the Backup & Sync in the members account. The way it's set up now you have to double click your life away. Example: to get to a document that was backed up you have to
Double click the Backup Storage Folder
Double click the Root C: Folder
Double click the Users Folder
Double click the Users Folder (Name)
Double click the Users Folder (Doc / Pics......)
.....and a bunch more double clicks to get to where you want to be. I think you see my point on a Console Tree in members account for Backup & Sync..
About once a month or so I go into backup and delete files that I deleted from my computer that I don't need anymore. A Console Tree would speed up my cleaning and also speed up finding a file that was backed up.
When you launch unknown applications: display a pop-up message
This will increase the security, so the user will be notified in advance
It will be more convenient, the user will know that in system is running suspicious process
At the moment the user doesn't receive notification of monitoring active process
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?
Can we have two separate lists, Protect and Allow/Deny, to the Identity Shield as some have said that they would like to Protect an App but they also want to be able to Allow or Deny an App from seeing Protected Data. I can see the benefit of this option myself and other Advanced users.
We get a lot of questions/issues/complaints around PUA's. They are one of the most irritating things. WSA blocks many of them, but for a variety of reasons not all. Specifically PUA's that are bundled with other software, are not hidden, have an opt out ability, are not currently blocked by Webroot.
Would it be possible to add a feature that the end user can choose when installing new software to block ALL bundled software? That would:
1) Be an active choice by the user to block the bundles
2) Reduce vastly the number of PUA issues that we see
3) Keep things quite legal.
4) Help keep Webroot above and beyone the competition.