How exactly does Webroot allow you to restore files encrypted by cryptolocker?
Saw you guys post on Spiceworks that if cryptolocker manages to get on to a computer with Webroot installed and it encrypts your files webroot will be able undo it. As my boss eloquently put it, it "sounds like magic" how exactly do you guys do this, setting restore points or some other mechanism?
Already have an account? Login
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
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.
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.
I had assumed the second sentence implied that as long as Webroot SecureAnywhere was installed on every machine in the network, you were OK. Am I mistaken ??
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.
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.
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.
Yes I understand. That's the problem.
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.
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.