Ransomware paranoia - How to prevent backups
I have no reason to assume I'll be hit with encryption ransomeware. However, I want to stop taking backups if I am; backing up corrupted data does not aid recovery. Maybe I'd be luck and Acronis would just stop, but I don't want to count on that. Can pre/post command processing be used to prevent a backup? I assume an encrypted .bat file would fail and trigger "Abort the operation if the user command fails". Is that a good assumption? If the .bat file is also renamed, then Acronis would not find it. Is that enough of a failure to abort the backup?
Any other ideas?


- Log in to post comments

@Steve...thanks for putting the Ransomware bookmarks together. I am going to include this thread in MVP Utilities.
@Patrick...the links in Steve's response contain a lot of good info on ransomware & strategies for protection.
- Log in to post comments

I didn't get an email mentioning these updates to the thread so I missed them. Sorry to be late in responding. :-(
Steve Smith wrote:Patrick, I would suggest setting up a simple small backup task and trying out different options here - you could try renaming a bat file used in a pre command to see how ATIH handles it, or changing the content to 'garbage' etc.
I gave that a try. I'm not sure I actually believe the following results, but I'm reporting them anyway.
Update: I've erased the results I reported earlier because today I get completely different (and very satisfactory) results.
What I've found is:
- As far as AHTI is concerned, "command" is a .bat or .cmd file. You can't just put in a Windows (DOS) command. At least I couldn't get that to work.
- If the .bat file is not found Acronis considers this a failure.
- If the .bat file executes and gives a non-zero return code Acronis considers this a failure.
- If the .bat file contains garbage that cannot be executed Acronis considers this a failure.
These results are completely at odds with the results I got yesterday, but they are what I want so I'm going to trust them.
I now have a file named Verification.txt on my C drive and a .bat file conaining dir "C:\Verification.txt || exit /B 1" . If the .bat file is deleted, renamed, encrypted, or password protected, the command will fail. If the .bat file is ok but the verification file is deleted, renamed, encrypted, or password protected, the command will fail. This obviously is not foolproof, but it's a beginning.
- Log in to post comments

But now the bad guys know what your .bat file is named so they're going to leave that one particular file alone to circumvent your efforts. OK, probably not really, but you know how they gather information bit by bit to get the full picture. Overall though, sounds like you have a good plan.
- Log in to post comments

Well, if I were really paranoid I would worry about that. But all I have to do is pick a different validation file name (and have one with a different name on each drive I'm going to back up). I suppose some ransomware could examine the contents of evey .bat and .cmd file it finds looking for possible ransomware tests and not modify the targets of those tests, but I doubt it. (If that's a possibility maybe I'll build a .bat file that touches every important file I've got. :-) )
- Log in to post comments