Ransomware realities: In your normal life, strangers don't extort you. But here you are As "trendy" as ransomware is at the moment, it's a sobering thought when you remind yourself that in this case you're literally having to deal with some miscreant holding your data to ransom. In practical terms, when your systems become infected, the malware encodes your files using a strong encryption algorithm, and leaves …
You can try to teach the users but the incoming documents can look very realistic - today I'm getting dozens of emails from FedEx Shipment with very realistic, well formatted presentation and a link to "Invoice for shipment # 711438857155" ... the only error is that it's sent from fidix.com
The malware infections will continue until we secure the email system.
"the chance of the software you use being available on Linux is about the same."
Yes, if Wine can run malware under Linux then it could also run your Windows software so the chances are indeed about the same. Looking for the equivalent native Linux applications is a much better bet.
Something tells me that's not the reaction you were hoping for.
@Paul Crawford
Not disagreeing on your broader point, but that wouldn't have stopped Wannacry and the real danger of ransomware is the user writeable stuff. If a zero day exploit from your local friendly TLA is used to install the malware, losing kernel32.dll is nothing an hour with the recovery DVD isn't going to fix. On the other hand, losing 2017SalesLeads.xlsx is going to be somewhat more awkward.
My view is that we need to use heuristic analysis on the shared folders to detect and limit the damage. For example, certain accounts have no business overwriting folder upon folder, and copy on write can be used to quarantine the suspicious activity. Furthermore, the structure of the most common file types can be checked for consistency. An xlsx file is simply a zipped folder of XML documents and stylesheets with an open specification. The server can validate this. Same with many other formats like jpg, MP4, etc. Where suspicious behaviour is observed, test a random sample of files for validity by the server itself and suspend the account if if fails.
"The prospect of getting ransomware is probably close to zero"
As a small population of users we're not worth targeting. If Linux were to take off then that would change. I do wonder, however, what would happen with Linux and MS Office running via Wine. Office would be as vulnerable to macros and I don't see why Wine wouldn't support Windows malware if it were introduced. Best stick to running native LibreOffice.
THIS:
Or, the users don't access the files often enough to go 'hey, this thing is corrupted, maybe I should complain about it to the IT group'.
One of our users got hit last year, and just never told anyone that their home folder had been encrypted, even after we cleaned up the workstation as the A/V alarms got everyone's attention straight away. (we have our user's home folders redirected to a network share, so that it's backed up properly. the local clients? no backups taken, and it's stressed to our users not to keep stuff on the desktop unless they are ok with it vanishing without notice or change of recovery.)
We asked them if they wanted it fixed and never heard back, but we did anyway because reasons.
I've yet to see a single piece of ransomware that would transparently decrypt for the convenience of its users for a whole month to run out the backup clock, while at the same time serving encrypted bytes to backup software. Can you name a single one? Despite the obviousness, that's not a trivial creation; ransomware never bothers because they're all about the smash-and-grab, not nation-state injection.
In terms of mitigating against Ransomware, then get FSRM installed on your file server. It's standard from 2008 onwards and can be used to give instant warnings of any unusual activity. Setup is trivial (follow the instructions at http://jpelectron.com/stopcrypto) and it's easy to maintain. It also has many other uses, but is not one of the better known features of Windows server OSs.
Also applocker. Setup rules to whitelist only the applications you want if you can, or at the very least block executables and scripts running from obvious locations such as user profiles. This will prevent the malware from being able to run in the first place.
As a nice side benefit, it will also stop users installing stuff like dropbox unless you want to allow it.
Regarding FSRM, this site has tips on setup and maintains a list of files to look for:
https://fsrm.experiant.ca/
We have our file servers setup to alert on this list and to also add a deny permission to all shares for the user that attempts to write any of these files. Blocks access to that user without inconveniencing everybody else.
If you have previous versions setup on your file servers (which you should), it may be quicker to just roll the whole volume back to the last snapshot instead of trying to rollback affected files. You may lose more, but it will get you back to a good state a lot more quickly. Minutes instead of hours/days. Although some crypto malware will attempt to blow away previous versions I am not aware of any that can affect snapshots on remote machines. Assume it will come though, so make sure your offline backups are working and tested.
That was our saving grace when we got hit with cryptolocker two years ago. (has it really been that long?! crickey!)
Netapp's snapshotting facility is read only, and interfaces quite nicely with the Previous versions tab for windows users. and with compression and dedupe turned on, it doesn't chew up space all that much.
I've recently been looking at autosync via Webdav. Webdav where V is for Versioning. So if your file gets encrypted your last good version should still be on the server. The cost, of course, is providing adequate space on the server for multiple versions.
Another aspect of this is that the ransomware is going to make use of the file system; whatever it sees in the infected PCs file system it will have a go at encrypting whether it's local or remote. That will, of course will include anything in the autosynced directory. But, at least on Linux/Unix, running KDE I have the option of setting up a remote Webdav link in the Dolphin file manager. That doesn't, as far as I can see, appear in the file system at all; it looks like a directory to Dolphin but not to anything such as ls using normal file system semantics. I don't know if that facility is available in Windows or Macs; if it is it's less likely that ransomware will be coded to tap into it and follow it. On Linux it certainly is possible so adds an extra line of defence on top of Linux's advantage of being a relatively small targetmarket.
A third thing I came across is that LibreOffice (and, I understand, MS Office) can edit remote files by Webdav protocol so neither the client file system nor file manager need have the file exposed to them.
There seem to be a number of ways in which this protocol can be used to defend the actual files from ransomware. Just don't bypass it by also exposing the server as something that appears in the clients' file systems via SMB or NFS.
Having proper backups, instead of just an auto-sync, will keep your data safe.
A proper backup system will hold a history of datasets, all being immutable - so if your files are encrypted and even if a few backups are run on the encrypted files, you will always be able to go back in time and restore a previous copy.
This is one thing that separates proper backup from sync tools.
Inexpensive and simple on-line backup solutions are available both for businesses and the home user.
There's nothing inexpensive or simple about storing truly non-writeable backups of infinite depth. Solutions that the real-world home user might actually use (such as an external hard disk) can be encrypted retroactively even if the user is smart enough to keep more than a single latest version of everything...
Just reboot to your recovery drive. Reformat and restore.
People who don't have backups risk everything from drive failure to randsoms. It really is a tax on the dumb.
This is computer 101 and maybe people who don't grasp it should pay up or just turn off all technology.
It really is one of the first things you learn - hopefully not the hard way.
"Work on a system of “least privilege” – where users have access only to the files they need" Should read: "Work on a system of “least privilege” – where users have USER access only to the DEVICE".
Remove local admin privileges to staff (be able to respond quickly to requests to install/update applications) and you go a long way in preventing malware from running.
It's not a silver bullet (apparently(?) some types of ransomware will still run on the local machine) - but it does put up a significant block.
No, in the original statement, the user has user level access to just a handful of files and nothing else. The user can't even access the majority of the files on the device they're using, at any level. This is far more locked down than allowing user level access to the entire device.
Use rsync for your backups.
It's a damned good tool, anyway. Gives you what is effectively a full backup but uses little more than the bandwidth needed for an incremental backup. Remote backups even over poor ADSL are possible.
The "full backup for incremental cost" thing means you can do your backups daily. Or even more frequently, if you really want (and don't mind a little slow-down during working hours).
You can tell rsync to generate a directory tree of what has changed/been deleted since the last backup. Sorta like an incremental backup but going back in time. A decremental backup? The great thing about this is if you get hit by ransomware your change tree is going to be very, very large. A simple size test post-backup will tell you if something weird has happened (handy if it's stealth ransomware that encrypts your files but runs for a couple of days dispensing decrypted versions to make recovery harder).
If you want, your change trees can use the equivalent of shadow volumes so that they look like a full backup while only consuming the disk space of an incremental. Makes it harder to find what changed two days ago, but makes it a lot easier to restore to a state a couple of days ago (before you got infected). There are ways of having your cake and eating it (left as an exercise to the reader).
It's a Linux thing, but also available for Windows using Cygwin. Might even be in Microsoft's "sorta Linux CLI" extension, for all I know. Yeah, you'll have to learn all about shadow volumes so your backup will include files that Windows keeps open and would otherwise not be backupable, but it's possible to do it. I've done it.
For some businesses, even losing a few seconds of live data is catastrophic, and ransomware will leave them irretrievably fucked. For many businesses, the loss of a day's worth of data is going to be very bad but probably not catastrophic. For most businesses, the loss of a week's worth of data (if they only do weekly backups) is probably going to be lethal.
If you're not using rsync you really ought to ask yourself why.
We've been using a semi-custom GPO that blocks application execution from the usual malware sources (TEMP, appdata, etc.) that Thirdtier.net put out when cryptolocker hit mainstream (but before they started charging for it).
I've not actually tested if a ransomware can encrypt previous versions remotely; I know that at that point in time, we were using a Netapp filer for CIFS/SMB, which doesn't offer writable snapshots through the stock previous versions tab. With windows file servers? I don't know, and I'm slightly terrified to try it in anything but a completely air-gapped sandbox. Presumably, it may be a safe assumption that as long as the file server is not compromised, it should be safe? We've been focusing on preventing the stuff from executing to begin with.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
