If you don't back up very frequently, you're always vulnerable to having something recent taken.
If you do back up very frequently, you need to make some hard choices:
You need to connect to your backup media very frequently. But, you don't want any ransomware that may find you to also find your backup media; that would defeat the purpose of the backups.
Backing up a lot of data very frequently will end up requiring a lot of storage. If you erase old backups to save on storage, you're vulnerable to your latest backup turning out to contain only ransomware-encrypted data.
If I was hit by ransomware and needed to restore from backup, I'd make damn sure to mount that backup drive readonly.
Everything but the requirement to have your backup media connected frequently is a long-solved problem in corporate-level software, we just need to start seeing it at the consumer level.
The ransomware, while still in silent mode, will decrypt the data before the backup software sees it, so that the backup software doesn't see any changed data.
The ransomware could, however, know about a fixed set of backup programs, and, when it detects one is running, silently encrypt (parts of) backups of old data.
Things will get complicated for the ransomware, though. While in stealth mode, it must be smart enough to discriminate between files it encrypted and those that it didn't encrypt (yet). Otherwise, a test restore could fail. I would use an extended file attribute or a separate database (would be a single point of failure, but hey, it would not be _my_ data) for that, but from what I read here, lots of ransomware just encrypts everything in a target directory and then uses 'everything under directory foo is encrypted' (that should be done in a transaction, but ransomware writers wouldn't be too concerned about that)
That assumes that the ransomware has direct access to the stored backup data, which seems like a flaw in the backup system that you're imagining.
I've got a particular backup system in mind, which I've been basing my assumptions on when I reply. It has a way to add a new backup, a way to retrieve any old backup that hasn't been expired yet, and a way to see if a piece of a file has been backed up in the past, but the server itself doesn't provide a way to remotely change past backup data directly.
Flooding the system with new data to push old backups out (as sokoloff mentioned) would be possible, assuming that the ransomware generated enough new backup data to fill up the backing storage, especially if it were scaled to give enough storage just for one or two computers.
I'm just playing with ideas =) The software I'm familiar with comes with hardware, generally scaled to keep a few months of nightly backups of a few hundred workstations and some fairly powerful rulesets for data expiration...so I've never really had to consider malicious backup expiration by ransomware. It's an interesting set of problems to consider.
Done and done. Additional storage is only taken if a file changes. You can always use a snapshot to revert to an earlier version of the filesystem (in the case of a malware attack).
Actual backups of the NASBox do happen of course, should the case fall over and all the hard-drives get scratched simultaneously.
An alarm or quota on disk IO volume could mitigate this.
Since the NAS is the center of my important data, I pay attention to it more.
A business solution would probably need an alarm of some kind, because a busy IT professional isn't going to have the time to baby a machine like I do.
Its just the whole "computers are cattle in professional IT settings" but are "pets for the home user".
The attack happens on a file-by-file basis, within the free space that you have allocated on the live filesystem. foo.txt, bar.pdf, and baz.jpg are all encrypted in place, consuming only marginal free space during the operation.
Then, when the incremental backup happens, THAT will notice that ALL the non-OS files have changed and the backup consumption will explode.
Perhaps RAM snapshots could be employed as part of the backup to allow retrieval of the encryption key.
Because the second guy can either guarantee himself to be screwed or pay some nominal amount below his pain threshhold to at least have a chance of recovering his files.
The only issue is that people would take it to computer repair shops, who surely would know which ransomwares are real or not. You'd need to successfully disguise your ransomware as other people's ransomware, and that's slightly harder.
By doing that, they reduce the chances of people taking the bait next time, and therefore reduce their future source of income. So I have to completely disagree, they have a strong incentive to actually provide unlock keys when someone pays.
And software: https://github.com/Googulator/TeslaCrack
> The extensions '.xxx', '.micro', '.mp3' and '.ttt' have been reported for new variants of TeslaCrypt (3.0 and 4.0), and this tool cannot decrypt them, anyway. Please use TeslaDecoder instead, with 440A241DD80FCC5664E861989DB716E08CE627D8D40C7EA360AE855C727A49EE as the key.
TeslaDecoder, as mentioned in the article, is hosted here: http://www.bleepingcomputer.com/forums/t/576600/tesladecoder...
People won't pay the ransom if they lose their data anyways. So since they no longer accept payments from [X] ransomware they released the key. This way when they infect people with [Y] ransomware they are more likely to pay.
It's this weird sort of racket where they hold to their word (they'll give you a key to unlock your data!) but they're the ones locking away your data to begin with... but people are more likely to pay if they hold to their word.
The Bleeping Computer article has much better information (and comments) than the TechCrunch reporting of it.
Aw, that makes more sense. I thought the devs and distributors were one and the same.
Full disclosure: I was a gamer (never swatted, but said a few inappropriate things in my day).
You raise some good questions, but you've unfortunately left them unanswered.
Rookie mistake. No wonder they had to shut down!
Yeah, it don't scale. One or two smart-asses in a small group, it's a good time. Couple dozen firing at will in a forum for hundreds or thousands, it's poison in the well.
Someone get sociologists on it, to earn their stipends.