Ransomware attack via encryption of remote storage


Obviously, Duplicacy can protect against a ransomware attack where local files are encrypted and then a scheduled backup is made (which would now contain all of the newly encrypted files at a new backup revision) - the simple answer being to restore a previous version from a backup destination. But does Duplicacy offer any kind of protection against a ransomware attack that may get the app keys for, say, cloud storage from the local keyring or some other source and then encrypt or alter the cloud storage where the backup data is contained? My concern would be having my backup on the cloud encrypted as well and then having no access to perform the restore I previously mentioned. I haven’t seen any relevant discussion about this topic specifically on this forum or elsewhere. I understand this is more a question of securing the cloud app keys but I think this is a valid question and I’m curious about 1) what measures, if any, Duplicacy has to deal with this or prevent it, and 2) what others do to prevent such a situation or recover from it. A cold copy backup would work for this but I have no desire to burn 800 DVDs if you get what I mean.

Thank you

Duplicacy does not have control over what happens on the cloud and who else has access to that cloud. So all you can do pretty much is give duplicacy minimum required permissions to do backup that do not include ability to delete or modify files. (see similar thread here How secure is duplicacy?)

The simplest solution however would be not prevention – but recovery: simply implementing periodic snapshotting of the target storage completely eliminates the issue.

1 Like

Another complementary protection is to configure your cloud storage to keep files for a certain time after deletion. In my B2 buckets I configured to keep the files for 90 days.

@towerbr Is this 90 day retention on B2 a problem where :d: relies on hiding the files for fossil collection? Don’t hidden files on B2 get deleted after the retention policy days? And doesn’t this break the :d:/B2 backup model?

@saspus Understood. I have read the entirety of that thread and it is helpful for me to understand how :d: handles the fossil collection via hiding. Thank you for sharing. Doesn’t :d: require read/write (delete is just hiding, after all) to function correctly with its snapshot history?

Yes, prune requires deletions; but you can prune with different set of credentials, from different machine, or not prune at all…

1 Like

Which is what the guy on your linked post was saying. So there is never any hiding or deleting unless a prune is performed, is that right? (it does make sense on the surface)

Correct, backup does not delete anything. Only add.

But it DOES modify chunks on the cloud storage - which in the case or protecting from an encryption attack doesn’t help me a lot if I understand it right? (functionally this is the same as deleting, as the data is overwritten). What does rolling back the whole contents of a bucket on B2 to a certain date look like - because rolling back each individual file is just crazy?

Chunks are immutable. Filename is a hash of content. They are never modified. They are only created, renamed (in case of B2 — hidden) or deleted on prune.