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

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)

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