+x+xI 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.