First I’d suggest if there’s over a certain number of changed files to not do a backup. I assume in the case of ransomware that encrypts most user data there would basically be a full backup triggered by all the changes. Since it’s basically all junk data I’d prefer not to back it up and add a bunch of entries to the hash table. An email alert of this would be nice.
Even better would be to detect this and block the process or account making the changes. Say have a threshold that can be set that if more than x files are modified per second with the same extension block write access for the user account. I realize this is not really the job of backup software but urbackup is already watching for changes and it would help protect data.
I’m more interested in preventing ransomware before it hits the gates. I recommend macro-enabled document detection at your spam filter.
But I can see how this would be useful ( especially for us with dedup enabled.) A ransomeware attack would really kill my dedup ratios and then make me very sad.
Yep, I agree with blocking it when you can. I’ve had it hit terminal servers twice where they brute forced weak passwords and logged in to the terminal server to deploy it. I’ve also had it come in from a website despite having current antivirus on the workstation and a router scanning downloads. I’ve moved the servers behind RD gateways which seems to stop the scripted attacks for now.
No idea how many times it’s been stopped but it seems like urbackup is in a good position to at least send an alert if that behavior is detected and pause backups until it’s been checked out. Even better is for it to take some action when that behavior is detected - even just the option to run a script would do nicely if the username responsible for the changes could be passed as an argument to it.
That is a pretty serious threat. 2fa would resolve that attack vector at the gates.
Regarding the the website vector the likelihood of blocking ransomware with AV ( on the wire or on the host ) is so low it isn’t really considered a valid preventive measure. Typically we deploy a layered solution. Web protection to prevent users from accessing malicious sites, group security controls designed to limit the risk to data, spam filtering that includes macro enabled document detection, hybrid cloud backup, vulnerability identification and remediation and a well trained workforce.
I thought a bit about this. Detecting a program that encrypts a lot of files is in the purview of the behavioural detection of a virus scanners. The API UrBackup uses to watch for file changes doesn’t contain which program changed the files in any case. I also don’t really want to enter the virus scanner rat race
A more practical solution I thought of would be adding a randomly named canary word file to each clients document folder(s). Then check if the canary word document is encrypted/deleted before/after each backup. You’ll have to teach the users to not delete this file…
I would not have thought that having lots of useless encrypted backup data is actually a problem. This is the moment the backups are for anyway. What I thought would be a problem is the encryption persisting too long such that the unencrypted backups get deleted, because the encryption is not detected.
I don’t need to know the program that made the change but rather the user that did. I think in every case I’ve seen the owner of the file is changed to the account the virus runs under. Typically what I do if it’s caught while encrypting is deny write permissions to the user that owns the encrypted files.
If you could have urbackup create the canary file under each root backup path as a hidden system file starting with _ (should stop most users from seeing it and be the first file to be encrypted) and optionally run a script with the new canary file’s name as an argument that’d work. I can then run a script to check the owner of the new file name, deny write permissions for that user, and send an email to alert. Also make it optional to pause backups as long as that canary file isn’t as expected.
The last case I had this was a 2 TB share that was encrypted starting Friday night. They found it Monday morning. I’ve been worried about sqlite performance already and can’t imagine having possibly millions of entries for hash values for useless files is good for it. That combined with the fact that this could potentially prevent most damage it seems like a very worthwhile feature.
If it’s not a file share then it can change the owner back to its original or rewrite it inplace. It’s just sloppy programming with with the ransomware you have experience with, I guess. I’d avoid depending on that.
Which user made the change also isn’t included in the Windows file change log.
Hiding the file is also kind of borderline. The canary file should be indistinguishable from other (important) files. That’s why I was concerned about the users deleting them. Or they move the whole folder somewhere else or something.
For my cases I’m only thinking about file shares urbackup is set to backup as files so that may be why I’ve been able to rely on file ownership to identify the source.
I could see this getting more complicated for protecting a workstation, especially if the infected user doesn’t have admin permissions since it’s mostly their user directory that’d be encrypted which would mean you’d need a file in each user directory.
As to hiding the file are you thinking the ransomware would skip the file if it were set as a hidden or system file?
The other option is to monitor extensions or filenames but guessing this is probably too much like antivirus for your liking?
I’d be happy to help maintain a community based list. Let users submit new extensions, require review of new submissions so we don’t get somebody adding normal file extensions. Distribute this to urbackup clients on a a regular basis… like antivirus definitions.
