Skip to main content

Ransomware paranoia - How to prevent backups

Thread needs solution

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?  

0 Users found this helpful

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.

See posts: 
118702: Acronis True Image 2016 vs Ransomware  
114970: Ransomware: mount/enable destination USB Disk as Pre-command and unmount/disable as Post-command?  
118140: Ransomware  
109928: Hypothetical: When restoring after ransomware encrytion wipe drive(s) first? 
118528: Ransomware / How to backup to Synology NAS with different user credentials?

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

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:

  1. 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.
  2. If the .bat file is not found Acronis considers this a failure.
  3. If the .bat file executes and gives a non-zero return code Acronis considers this a failure.
  4. 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.

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.  

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