Supposedly a researcher asked them to, since they're switching to a different ransomware/provider of ransomware(?)
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.
I didn't get that the developers were switching to something new, but that the developers were shutting down and the distributors (people actually working to get TeslaCrypt onto PCs) were switching to something new - presumably because the TeslaCrypt folks were going away.
The Bleeping Computer article has much better information (and comments) than the TechCrunch reporting of it.
>I didn't get that the developers were switching to something new, but that the developers were shutting down and the distributors (people actually working to get TeslaCrypt onto PCs) were switching to something new - presumably because the TeslaCrypt folks were going away.
Aw, that makes more sense. I thought the devs and distributors were one and the same.
Or a deal with the FBI (unless by mother you mean FBI). They be nice, release the key, work for them for a few years, and avoid getting gang raped in an overcrowded jail for 10 years.
And vice-versa. "You should've seen the other guy."
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.
Seems like the only way Ransomware will ever die is if people start releasing non-functional ransomware implementations that accept payment but leave data encrypted, so people become skeptical of whether paying will actually get their data back.
Only takes one well spread one who wants to save on actual crypto effort but reap similar rewards to ruin it for everyone. In the absence of good communication the tragedy of the commons is... well its common.
Failing to return your victims' data doesn't just poison the well for other, more sensible ransomware makers -- it poisons it for you. Once you take the first guy's money and leave him with his files destroyed, why would the second guy pay you?
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.
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.
Versioned / snapshot backups that you don't have full write access to (just append) prevents this. Even if all files are encrypted you'll maintain the previous version.
Regular ZFS Snapshots taken through NAS4Free (served to my Windows box through CIFS)
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.
If the ransomware encrypts all of your files, you will need 2x space to keep an old snapshot. If it repeatedly re-encrypts them, it could cause all of your unencrypted snapshots to expire.
An alarm or quota on disk IO volume could mitigate this.
Could this kind of attack be thwarted by keeping free disk space to a minimum - such as 15% free space? That way, the attack wouldn't have enough free disk space to happen. This would be difficult in systems with highly-dynamic storage needs, but could be done on application or caching servers.
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.
Or paying attention to your NAS on a regular basis. Granted, this is my home network with only like 5 machines connected to it max. (My desktop, my laptop, my NAS, my home-theater PC, and my tablet).
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".
"Good enough" backups can include incremental backups, where changes are tracked at a sub-file level. You end up only actually backing up the parts of your computer that change (after an initial full backup of the system).
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.
I'm not talking about rsync'ing a bunch of files onto a NAS, I'm talking about an actual backup system. You'd just restore from the file revision immediately before the encrypted data.
Someone's point is that, when ransomware encrypts all your files, they have all changed (from the computer/backup system's point of view, not from the user point of view). With systems that do rolling incremental backups of changed files [until the backup volume is full and has to discard older versions], this will cause the oldest (pre-encrypted) files to be discarded far more quickly than during normal operations [and far more quickly than the user has become accustomed to].
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)
> 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.
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.
That's a more believable attack than what most of the other posters have suggested. I suspect that the first step to fight that might be to store a value for the entropy of each backed-up file. A massive change in a file's entropy would be something to flag and require manual intervention on. Also, maybe some controls to limit the damage of a "push off the cliff by adding new data", like a way to set specific directories as "critical" to prevent the last copies of files in them from expiring.
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.
> 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.
If I was hit by ransomware and needed to restore from backup, I'd make damn sure to mount that backup drive readonly.
I think your parent is saying that if you are connecting to backup media frequently to make backups (in write mode, of course), then the ransomware has an opportunity to silently encrypt that too before you know you're infected, thus rendering your backups useles.
"You will pay $1000 to recover your now encrypted data, unless you pay $59 per year to backup service x to backup the data we have locked which may be important you you!"
Ransomware infects your machine, silently encrypts and decrypts everything for a period of months then stops. Your backups are encrypted and only the ransomware can decrypt them.
Perhaps RAM snapshots could be employed as part of the backup to allow retrieval of the encryption key.
Now that you mention it, I'm shocked there hasn't been any high-profile ransomware that threatens to post your browser history to Facebook if you don't pay up. Perhaps there are certain lines even criminals won't cross.
And ransomware mimicking other ransomware. The mimicry doesn't even have to be perfect, if it's good enough to provide the impression that "CryptoVault 3.2" only decrypts your data occasionally, after you pay.
Considering how effective 419 and cat-fishing scams are, I doubt ransomware will ever die. No matter how unreliable it becomes, there will always be another sucker.
The ransomware makers themselves have an incentive to do this. Making a ransomware that just deletes all your files is much easier than proper encryption. And they can still take your money!
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.
> The ransomware makers themselves have an incentive to do this. Making a ransomware that just deletes all your files is much easier than proper encryption. And they can still take your money!
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.
For better or worse, that's already the case. There are several pieces of ransomware where if you pay, your money effectively just disappears into a void.
Why were they targeting video games? Seems like you can just reinstall and that corporate or personal information would be much more valuable and high ransom.
> 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.
What's the point of encrypting video games? I'd rather wipe out the drive and reinstall the games than pay, not be certain it will work, and know my PC still has some potentially active malware somewhere, waiting to be sold to a botnet.
99 comments
[ 2.1 ms ] story [ 165 ms ] threadPeople 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.
http://www.bleepingcomputer.com/news/security/teslacrypt-shu...
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.
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.
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.
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.
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.
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".
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.
If I was hit by ransomware and needed to restore from backup, I'd make damn sure to mount that backup drive readonly.
Perhaps RAM snapshots could be employed as part of the backup to allow retrieval of the encryption key.
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.
440A241DD80FCC5664E861989DB716E08CE627D8D40C7EA360AE855C727A49EE
And software: https://github.com/Googulator/TeslaCrack
https://github.com/Googulator/TeslaCrack/commit/ca30a5320ebb...
> 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...