3 ms·

"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 comp

"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.

Someone 10y ago
The ransomware could decide to re-backup some of your unchanged data, too, overwriting the non-encrypted backup.
- khedoros 10y ago
  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.
  - sokoloff 10y ago
    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].
    - Someone 10y ago
      That's not my point, but close to it. 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)
      - khedoros 10y ago
        > 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.
    - khedoros 10y ago
      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.

Someone 10y ago

The ransomware could decide to re-backup some of your unchanged data, too, overwriting the non-encrypted backup.

khedoros 10y ago
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.
- sokoloff 10y ago
  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].
  - Someone 10y ago
    That's not my point, but close to it. 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)
    - khedoros 10y ago
      > 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.
  - khedoros 10y ago
    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.