I had an HDD that is going flaky: started having spin-up errors. That was for drive D: (one partition encompassing entire disk). Macrium backups are saved on drive E: (one partition encompassing another disk). Before the bad drive fails completely, I wanted to put the files on drive D: onto a partition on the 2nd HDD that would then become drive D:. Using a partition manager, I resized E: to make room to create another partition and named it drive F:. I copied the folders and files from D: to F:. Then I unassigned drive D: for the partition on the old and failing HDD and assigned D: to the new partition on the 2nd HDD. After the change, drive D: became the 2nd partition on the 2nd HDD and E: would remain as the old (but reduced) drive E: partition on the 2nd HDD.   E: is where the Macrium backup files are saved.

While doing its work, the partition manager ended up moving files in E: to reduce the size of that partition. I had thought the files would be at the beginning of the partition but apparently not, so the partition manager had to move them to be wholly inside the changed (reduced) partition size. That made me start to question if Image Guardian could protect the backup files since they could be re-positioned during a boot-time partition resize. If a boot-time partition manager can move around the backup files, why couldn't boot-time ransomware also rename the files and also encrypt them?

One mode of operation for ransomware is to add a boot-time program that pretends to be running chkdsk. Whenever the user happens to restart Windows (a restart or shutdown followed by boot), the user thinks the OS instigated the chkdsk operation. It is a fake chkdsk just to get the user in to give the ransomware the time it needs to encrypt the files. If a partition manager during a boot can move around files within a partition (drive letter) that is protected by Image Guardian then why can't boot-time ransomware corrupt the backup files at boot time?

Image Guardian might run as a rootkit, like a stacked driver for system I/O functions, to intercept actions on files at the backup destination. Okay, but that is protection only after the OS loads which then loads the Image Guardian driver; i.e., using a kernel-mode driver only offers in-session protection (after THAT instance of Windows has loaded in which Image Guardian was installed). Having the in-session protection of backup files is nice but it appears Image Guardian cannot protect against boot-time malware, like that which replaces the bootstrap code in the MBR or runs a malicious program on boot of Windows.

I'll be curious to get Macrium's official answer on this, but while I know that MIG does protect against certain processes that happen during boot (for example, there's a Windows API that allows an application to schedule a file for deletion during the next boot, and Image Guardian prevents that from happening), I doubt that it's a full boot-time solution.  It's also worth noting that when you're performing a partition operation like that, the application is acting at a block level against data blocks within the partition, not at a file level against the backup files directly, and Image Guardian doesn't protect against partition/block-level operations, even within Windows.  For example, Image Guardian would not prevent you or anything else from formatting the partition on which your backups reside.  That's simply not what it's meant to do.  However, both that operation and the scenario you describe assume that the malware has gained admin privileges to begin with, and frankly once you have admin privileges it's technically game over anyway, because at that point although Macrium can (and I believe did) take steps to make it difficult for another application to tamper with MIG, ultimately if you have admin privileges on the system you can do whatever you want, including disabling or uninstalling MIG.  The reason MIG is still useful is because ransomware quite often does NOT attempt to obtain admin privileges because they're not necessary for ransomware to do its damage.  Typically ransomware focuses on encrypting documents within your own user profile folders, such as your Desktop and Documents folders, and those files can be modified with standard user privileges.  Image Guardian does protect against that type of activity.

I personally wouldn't want Image Guardian trying to shim itself into the system at a sufficiently low and early level to act as an anti-rootkit measure.  I believe it simply opens up too many potential issues around system stability, potential conflicts created with other anti-malware solutions the user may have installed, problems when upgrading to a newer release of Windows 10 that arrives every 6 months, etc.  If you want to protect against ransomware at that level, frankly there's still no true substitute for having another copy of your backups that is always (or almost always) offline and ideally off-site.  I myself have two external hard drives.  One is always connected and protected by MIG.  The other is always DISconencted except when I'm cloning my main external drive to it, which I do periodically through Reflect.  Ultimately, even the best software protection can't guard against everything, especially if you assume your adversary has admin privileges, which is why you want to have copies of things in locations that simply can't be reached by said software.

+x

 

vanguardlh - 28 January 2019 8:25 AM

I had an HDD that is going flaky: started having spin-up errors. That was for drive D: (one partition encompassing entire disk). Macrium backups are saved on drive E: (one partition encompassing another disk). Before the bad drive fails completely, I wanted to put the files on drive D: onto a partition on the 2nd HDD that would then become drive D:. Using a partition manager, I resized E: to make room to create another partition and named it drive F:. I copied the folders and files from D: to F:. Then I unassigned drive D: for the partition on the old and failing HDD and assigned D: to the new partition on the 2nd HDD. After the change, drive D: became the 2nd partition on the 2nd HDD and E: would remain as the old (but reduced) drive E: partition on the 2nd HDD.   E: is where the Macrium backup files are saved.

While doing its work, the partition manager ended up moving files in E: to reduce the size of that partition. I had thought the files would be at the beginning of the partition but apparently not, so the partition manager had to move them to be wholly inside the changed (reduced) partition size. That made me start to question if Image Guardian could protect the backup files since they could be re-positioned during a boot-time partition resize. If a boot-time partition manager can move around the backup files, why couldn't boot-time ransomware also rename the files and also encrypt them?

One mode of operation for ransomware is to add a boot-time program that pretends to be running chkdsk. Whenever the user happens to restart Windows (a restart or shutdown followed by boot), the user thinks the OS instigated the chkdsk operation. It is a fake chkdsk just to get the user in to give the ransomware the time it needs to encrypt the files. If a partition manager during a boot can move around files within a partition (drive letter) that is protected by Image Guardian then why can't boot-time ransomware corrupt the backup files at boot time?

Image Guardian might run as a rootkit, like a stacked driver for system I/O functions, to intercept actions on files at the backup destination. Okay, but that is protection only after the OS loads which then loads the Image Guardian driver; i.e., using a kernel-mode driver only offers in-session protection (after THAT instance of Windows has loaded in which Image Guardian was installed). Having the in-session protection of backup files is nice but it appears Image Guardian cannot protect against boot-time malware, like that which replaces the bootstrap code in the MBR or runs a malicious program on boot of Windows.

Thanks for posting.

You are correct in that MIG doesn't protect against boot time legacy MBR code modified by ransomware. However, Modern PCs use UEFI/GPT booting rather than legacy MBR. The UEFI/GPT boot process uses EFI boot code located in the EFI system partition and this is normally protected using 'secure boot' digital signature authentication. 

With that said, the safest method is to backup to a locked down network share on another PC protected by Image Guardian.  Please see 'Macrium Image Guardian protecting backups in a networked environment' here:

https://knowledgebase.macrium.com/display/KNOW7/_MIG_Overview

Kind Regards

Nick - Macrium Support

+x

 

Nick - 28 January 2019 5:01 PM

+x

 

vanguardlh - 28 January 2019 8:25 AM

I had an HDD that is going flaky: started having spin-up errors. That was for drive D: (one partition encompassing entire disk). Macrium backups are saved on drive E: (one partition encompassing another disk). Before the bad drive fails completely, I wanted to put the files on drive D: onto a partition on the 2nd HDD that would then become drive D:. Using a partition manager, I resized E: to make room to create another partition and named it drive F:. I copied the folders and files from D: to F:. Then I unassigned drive D: for the partition on the old and failing HDD and assigned D: to the new partition on the 2nd HDD. After the change, drive D: became the 2nd partition on the 2nd HDD and E: would remain as the old (but reduced) drive E: partition on the 2nd HDD.   E: is where the Macrium backup files are saved.

While doing its work, the partition manager ended up moving files in E: to reduce the size of that partition. I had thought the files would be at the beginning of the partition but apparently not, so the partition manager had to move them to be wholly inside the changed (reduced) partition size. That made me start to question if Image Guardian could protect the backup files since they could be re-positioned during a boot-time partition resize. If a boot-time partition manager can move around the backup files, why couldn't boot-time ransomware also rename the files and also encrypt them?

One mode of operation for ransomware is to add a boot-time program that pretends to be running chkdsk. Whenever the user happens to restart Windows (a restart or shutdown followed by boot), the user thinks the OS instigated the chkdsk operation. It is a fake chkdsk just to get the user in to give the ransomware the time it needs to encrypt the files. If a partition manager during a boot can move around files within a partition (drive letter) that is protected by Image Guardian then why can't boot-time ransomware corrupt the backup files at boot time?

Image Guardian might run as a rootkit, like a stacked driver for system I/O functions, to intercept actions on files at the backup destination. Okay, but that is protection only after the OS loads which then loads the Image Guardian driver; i.e., using a kernel-mode driver only offers in-session protection (after THAT instance of Windows has loaded in which Image Guardian was installed). Having the in-session protection of backup files is nice but it appears Image Guardian cannot protect against boot-time malware, like that which replaces the bootstrap code in the MBR or runs a malicious program on boot of Windows.

Thanks for posting.

You are correct in that MIG doesn't protect against boot time legacy MBR code modified by ransomware. However, Modern PCs use UEFI/GPT booting rather than legacy MBR. The UEFI/GPT boot process uses EFI boot code located in the EFI system partition and this is normally protected using 'secure boot' digital signature authentication. 

With that said, the safest method is to backup to a locked down network share on another PC protected by Image Guardian.  Please see 'Macrium Image Guardian protecting backups in a networked environment' here:

https://knowledgebase.macrium.com/display/KNOW7/_MIG_Overview

Alas, not everyone has hardware that is newer than when UEFI took off.  UEFI 2.1 was introduced in 2007 but it takes a few years before mass adoption by the motherboard manufacturers.  My PC's mobo build date is back to 2009, so it uses MBR.  Plus, anyone wanting to multi-boot will have to disable the secure boot function.  I don't see that secure boot is going to prevent a program configured to start with Windows boot.  For example, Reflect can add itself as a boot menu choice.  Programs can add themselves to run on Windows startup which is before Windows loads the non-critical kernel drivers.  The digitally signed OS is loading specified by secure boot but how does that stop a program within Windows configuring Windows to start a program when Window starts (before loading non-critical drivers and before the normal startup programs locations, like Startup folder, registry Run keys, Logon events, logon scripts, etc).

I also don't have another host to use as a networked host for saving files to a shared volume over there.  That might happen when I get around to building a new PC.  However, anything that I can see then malware can see, too, like mapped drives.  It is unclear in the article to which you linked if the shared volume is a mapped drive or a shared volume accessible using UNC syntax.  Mapped drives are easy to find since they have a drive letter assignment and appear as local drives.  UNC is a bit more difficult to ferret out unless the malware goes looking in the registry for mount points.  Since the shared volume is always accessible, I don't see it offers any more protection than copying the backup files to a USB-attached drive.

I was hoping Macrium Reflect supported saving backups to an FTP server but it doesn't.  The best that I can figure out is to use a post-command in the backup job to copy the backup file to an FTP server; however, that means divulging the login credentials in the command line.  If Reflect did FTP itself then it could save the login credentials but use the crypto API in Windows to encrypt them in the registry or in a key file.  To use an sFTP but secrete the login credentials, I'd have to use a 3rd party FTP client that can store the encrypted login credentials and also has a CLI (command line interface) to let me have Reflect run the FTP job as a post-command to a backup job but without having to specify the login credentials in the command line.  

Adding an integrated sFTP client into Reflect is a long-time user request.  I know Easeus ToDo Backup has a built-in FTP client; however, I am unsure if they encrypt the configuration to prevent malware from digging out the login credentials to connect to the FTP server.

I don't have another host to use for shared volumes or to run an FTP server, so those scenarios are not applicable to my home setup.  UEFI might add another hurdle to malware but that isn't an option until I build my next new PC.  It dawned on me that MIG is only an in-session (or after-boot) protection method which doesn't protect against boot-time ransomware.

Thanks for your reply.  I'll still have to research how to protect the backup files from boot-time malware.