Reverting files to previous versions

  • 29 May 2016
  • 7 replies
  • 106 views

Userlevel 1
Hi,
 
I am sure I've read about Webroot being the only one AV which has the possibility to revert files to previous versions (especially in case of *crypt* ransomware infection). But I have never seen such an option anywhere inside WRSA.
I know exactly what Previous Versions under Windows OS are. And I know how Windows works. But I was hoping Webroot has some ADDITIONAL MECHANISM to be able to revert to previous version, regardless of Windows native file history.
 
Did I get it wrong about Webroot possibilites? Or am I missing something?
 
Thanks!

This topic has been closed for comments

7 replies

Badge +7
Sorry to resurect an old thread, but I need to correct this statement about journaling:
 
...Journaling and Rollback is ONLY for the local C drive or where the OS resides. It doesn't monitor/rollback changes made to data residing on another partition or drive such as D E F etc.... nor does it do it for network or mapped drives...
 
The agent will monitor the activity of any unknown process running on the local machine. It will journal changes made to the local PC. That includes the local registry and any hard drive on that PC. So regardless of drive letter, it would journal file changes.  However it doesn’t journal across the network to shared drives, etc.
Userlevel 7
Badge +33
We manage over 5000+ endpoints and actually whitelisting internet connections across Enterprises and MSP's is very doable. It's just implementing the tools needed. We have several very large chain stores that have gone totally whitelist with DNSThingy and Webroot, and essentially there's no chance for infection or ransomware being able to communicate out, cause it's essentially traffic that's not allowed.
 
By implementing a whitelist only ruleset on an internet connection you essentially only allow what's needed to do the work you need to get done. Absolutely everything else is not allowed.
 
Also if you didn't know, Webroot functions on a whitelist type model and everything else is considered suspicious/unknown until proven otherwise.
 


 
Userlevel 2
Whitelisting is not possible in a larger enterprise nor for MSPs managing hundreds of clients, and too complicated for the average home user, so that leaves it mostly dead in the water across the board.
 
Also pretending a product could ever close all gaps in security and prevent all infections is a pipe dream that we have been hoping for in computing for 20+ years, all the while malware writers have gotten better and infections more damaging.
 
The biggest advancement I have seen since crypto is the cryptoguard stuff in sophos' new intercept-x endpoint application which includes tech they purchased from surfright.nl which catches crypto attacks at the endpoint in real time and provides easy roll-back functionality for encrypted files. I would love for webroot to come up with some similar functionality. If you haven't seen it in action you should, its a game changer and I'll be reviewing it for our MSP soon.
Userlevel 7
Badge +33
The reason why journaling for non system drives, even those locally, is that it becomes a space/performance issue where the agent has to record the changes in a hidden folder on the main system partition (usually C:). Can you imagine the amount of journaling/logging and resources that are needed to watch over all this.
 
Also crypto-ransomware will also first attempt to encrypt all files it was locally ran on first and again that being C: before moving onto other partitions (D,E,F...) and network accessible files/folders.
 
By then we hope that any AV product, especially Webroot, will be able to classify or make a determination that something bad is happening and stop it in it's tracks.
 
You need to have a reliable local backup that's air gapped when not in use, a cloud backup if you can (backblaze, crashplan, carbonite etc...) to be able to restore some lost files.
 
Also if you redirect or completely disable the Windows Script Host as well as disable autorun/autoplay, filter file types in email, add a great pop up/ad blocker to your browser (i use ublock origin), and simply use safe computing practices, then you'll generally be able to prevent youself and clients from getting it in the first place.
 
We need to get off the mindset of cleaning up and fighting after the fact (cause a lot of times if you are hit, it's already too late) to focusing on NOT getting it in the first place.
 
Heck, if you want to go the ultimate step further, setup whitelisting on your entire internet connection. Then crypto-ransomware will never be able to call home again. DNSThingy from dnsthingy.com does this. It blocks absolutely everything and only allows websites you set in a whitelist. It blocks ads, ad tracking, third party advertisors etc... Pair Webroot with DNSThingy and you'll never get Crypto-Ransomware again.
 
 
This seems to be the newest thread on the subject. I found another from 2013 speculating that as ransomware became worse, Webroot may enable more remediation options. I think we can safely say that ransomware has gotten much, much worse. I see though that still there's no journaling for network drives (which is understandable), but I don't understand why it wouldn't journal for non system, locally attached drives. Seems those are the most likely drives to contain the kind of data that ransomware would want to encrypt.
Userlevel 7
Badge +56
You covered it perfectly ?
Userlevel 7
Badge +33
Webroot from my understanding only monitors and journals changes made to files for things that it doesn't have a classification of known good/bad. We don't know the secret sauce behind this but it appears as though all that info is stored in the WRData folder on the local system.

Journaling and Rollback are completely automated and there is no way an admin/user can do anything. Webroot only calls upon this to revert stuff as a means to remediate after an infection or when a file/process is classificied as known bad. If it is classified to be known good, then the journaling is stopped and the program is allowed to continue on its merry way.
 
Also note the the Journaling and Rollback is ONLY for the local C drive or where the OS resides. It doesn't monitor/rollback changes made to data residing on another partition or drive such as D E F etc.... nor does it do it for network or mapped drives.