0

While having "too much time" and after some careful thinking from my side, I kinda "found" that if you authenticate at application level, ransomware would have to carefully analyze all known settings files to recover login credentials and then implement backend-access protocols to actually also take this data ransom.

So far for the introduction and the "TL;DR", now for a more specific description:

  • Assume we have a computer which we want to secure from ransomware.
  • Assume further this computer runs regular backups.
  • Assume these backups are done by an application or service on the computer to a server, this application may be very popular (but not shipped with the OS).
  • Assume the OS isn't directly involved in the backup process / doesn't provide the target drive as mapped drive.
  • Assume the application authenticates itself (with PK auth or username+password) to the backend server.
  • Assume the authentication credentials are stored clear-text on the computer to be secured (as is usual).
  • Finally assume the server itself is guaranteed to be clean from ransomware.

Is the computer's backup now safe from being successfully attacked by (non-targeted) ransomware?

1
  • From my personal experience common ransomware fails to deal with things like dropbox (i.e. it encrypts the folder like a normal one, thus producing a new revision for the files where they are encrypted but you can easily revert the files to their latest good state).
    – Bakuriu
    Commented Nov 11, 2016 at 21:24

1 Answer 1

4

The answer to this question depends entirely on how smart the ransomware you want to defend against is. If you're dealing with standard ransomware, the answer is most likely yes, your backups are safe.

If you're dealing with ransomware which is aware of your application and targets it specifically, then obviously no, your backups are still at risk.

Note that in the first case, while the ransomware can't reach the backup server disk directly, it can still encrypt the local files and if your backup application doesn't stop backing them up, sooner or later backup rotation will rotate all valid backups out of existence.

May I suggest a different approach:

Keep several backup revisions. After you made a backup, sample a nontrivial number of important files to see if they pass various statistics for random data (eg even distribution of bytes, no known file type, almost 0 compression rate etc) . If most or all of your files look like random data, they are probably encrypted and you can disable the backup and alert the sysadmins, so while you've lost the most recent backup, all your earlier revisions are still available.

You could also do the tests on the live system before starting the backup, but I'd check the backup itself even if it meant losing one.

This will protect against ALL ransomware.

2
  • ITYM uniform (or informally even) distribution of byte values not normal. Of course the ransomware could just tack a zip or gzip header on the ciphertext and a quick check would have to accept it; you need to decompress at least a pretty good chunk before checking. Commented Nov 12, 2016 at 13:03
  • You're right, of course, normal is wrong. Sorry. Updated the answer accordingly.About the zip trick: That's easily countered with various methods: a) keep statistics about the distribution of word, excel, pdf,... and zip files. If that changes noticably, alert someone. b) even simpler, completely ignore the supposed file type and simply alert someone if the percentage of random looking files is higher than normal for your data. What constitutes "normal" depends on your data, but if it approaches 100%, that's a sure sign of ransomware. Commented Nov 12, 2016 at 19:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .