How exactly does Webroot allow you to restore files encrypted by cryptolocker?

[Warning: Business users have access to an advanced console I refer to, home users can do the same stuff but it has to be done by Webroot support]
 
If a process is not known to be non-malicious WSA intercepts and logs all changes it makes, allows them to proceed as long as they aren't rootkit-like or to credential storage, and adds the original data and settings to a compressed file store. If the file determination ever gets change to malicious then it goes through and reverts every change that was made. Note the primary weakness is that it does not revert on network shares.
 
In the case of something like ransomware, once a file in the chain of infection it uses is detected as a virus the whole things gets reverted and you basically can't tell the computer was ever infected. Plus, as long as a client can communicate with the internet you can go into the console, look at what's suspicious on the machine, tell Webroot it's bad, and the whole infection is reverted before your eyes. I've done it - it's pretty neato. Because of the journaling, WSA isn't as badly hurt if they don't detect something right away. You can basically stop infections from every happening - retroactively.

https://community.webroot.com/t5/Webroot-Education/What-Happens-if-Webroot-quot-Misses-quot-a-Virus/ta-p/10202#.UnQyw6mrRUQ
 
It's not perfect against greyware like toolbars and such since there are legitimate pieces in the installation chain but it's very reliable against malicious stuff. .
 
If you want to see for yourself, the journaling and file databases are under %PROGRAMDATA%WRData. Note that the .log files are largely correct but not authoritative - the juicy play by play stuff is in propriety formats only they can use. The lack of data given to administrators about what really happens is the main issue with the product for business users who like intense control, but it works so well without intervention and their support is so responsive they get away with it. Unfortunately, that makes most of their claims just seem like magic - you don't _understand_ until you see it do what it says it does.
 
The closest you'll get to the raw stuff is the ace*.db files which are actually just text files with the raw remediation and restoration scripts it generates and runs to clean up infections.

Hi Muddy,
As far as I know, WSA clients do not ever directly interact with eachother or work together to resolve a local network infection. Because the changes being made on a file server are made remotely over the network, the server WSA installation can't know that they're suspicious. Thus it can't journal the changes or revert them.
 
I think @ was saying that the best bet to stop the network share changes is to make sure that every computer that ever connects to it has WSA, since they are very likely to stop the infection before it can do damage outside of the machine. You can enforce this with a NAP/NAC product like what Cisco or Microsoft provide to certify client health before they can access the network or network resources. In the case of Microsoft you can do that for free if you have Software Assurance and you have someone to set it up and maintain it.
 
Other than using a product that integrates administrator-controlled HIPS and thresholds, WSA is not in the category that could stop the encryption of network data. Cryptolocker just completely encrypts the files, it doesn't turn them into viruses themselves or provide any possible signatures other than passing randomness tests. As far as the network server knows, you edited them all with Microsoft Word.
 
The Cryptolocker approach to ransomware is pretty smart since the answers are not easy unless you risk stopping legitimate processes with heuristics about network access, do process whitelisting, or pay someone to run and customize a HIPS product for your environment. There are other approaches and other products I could mention, but lets assume you're not a giant enterprise with $$$ going against the Chinese government.

@ wrote:
@ 
 
OK.
 
I'm afraid that network drives are a bit of a black art for me, and anyway I don't currently work with a network server so the question for me is academic.
 
However if I understand correctly, this means that the "magic" of WSA rollback becomes impotent if a malware attacks network server data files. Somewhat worrying for a company or a large organisation. Or for that matter, for anyone who uses a network.

Basically WSA doesn't see cryptolocker telling the host to encrypt the files as bad because all the file server sees is the legitimate client saying that it would like to encrypt these files that it legimately can access and doesnt ask "why does the host want to encryot all the things?"

You're correct @ . That's what makes Cryptolocker style of extortion so dangerous and so effective - if you're using normal antivirus for protection and it misses it the only resolution is to pay the ransom or restore from backup.
 
As threats like these become more commonplace, antivirus suites will become much more aggressive about suspicious network share access. But as it is they are not geared against that - Cryptolocker is using resources the user is already specifically given access to.
 
Webroot already has the technology to journal these changes if they wanted to. Eventually the pain of network share encryption will be a big enough threat that Webroot will expose this ability rather than avoid it out of fear of versioning issues.
 
In the end, this is just further evidence that the future is about turning the desktop into an app store model, where every application has a defined manifest of what it is allowed to modify. In the future, the fact that we had problems like this at all is going to seem incredibly stupid.

Important clarification

If a malicious file gets put on a network share it will happily detect it and remove it.
 
What I'm talking about is if you have a file not yet detected as malicious deleting or encrypting stuff like pdf files on the network share from someone's machine that has access to do that. WSA fixing the malicious file does not involve reverting the changes it made to the network share. There's not much in antivirus-land that could do that, regardless of what product you use. It only comes up as an issue with Webroot because their journaling technology, which is above and beyond what other suites do, does not provide coverage there.