Discussions related to using object storage as a backup target.
Post Reply
murdocmk
Enthusiast
Posts: 25
Liked: 4 times
Joined: Dec 14, 2009 5:10 pm
Contact:

Azure Blob Storage and Ransomware

Post by murdocmk »

I was looking at some options for ransomware protection for our Azure blob storage backups, as a stop-gap until Microsoft and Veeam get immutability working in a product release. I've read, in the documentation and in other places on this forum, that features such as versioning and soft delete were not supported and would probably not work, so I decided to run a test. Here's what I did:
  • I created a new scale-out repository associated with a new Azure blob storage container, and configured it to send any backups out to Azure immediately.
  • I enabled point-in-time restore for containers in my test storage account in Azure, which also enables versioning and soft delete.
  • I created a Backup Copy job for some of my existing backups, which would copy them to the new scale-out repository.
  • I waited for the job to run, and verified that the backup file was copied out to the new Azure blob storage container.
  • I then deleted the backups from the scale-out repository, simulating what an attacker might do to remove our offsite backups if they gained access to the Veeam B&R console.
  • I verified that the deleted backups were gone from the scale-out repository, and also that they were deleted from the Azure blob storage container.
  • I then went to my Azure storage account and restored the blob storage container to an idle point in time, meaning a time in which no jobs were running or cloud syncing was occurring.
  • After the restore was done, I re-scanned my scale-out repository and found that my offsite backups were visible in Object Storage (Imported).
  • I used Instant Recovery to verify that my backups were intact and that I could boot and log into a VM that I powered on from the object storage backups
Our Azure storage account is in a tenant that is not connected to our on-premise AD, and requires cloud-only accounts with MFA enabled to access. So it's my assumption that an attacker gaining access to our internal infrastructure would not readily have access to it. It's not impossible that they could get access to it, but it would certainly not be easy.

Can someone help me understand whether this is or is not a reasonable protection for offsite backups against a typical ransomware attack chain? As long as we can determine that we've been breached and our backups have been compromised within the window of our point-in-time blob container restore window, couldn't we use this method to restore our blob storage container to an idle point in time between the last offsite sync and the time they were deleted, and then scan our repository and begin restoring VMs?

Thanks,
Mark
soncscy
Veteran
Posts: 643
Liked: 312 times
Joined: Aug 04, 2019 2:57 pm
Full Name: Harvey
Contact:

Re: Azure Blob Storage and Ransomware

Post by soncscy » 2 people like this post

> I then deleted the backups from the scale-out repository, simulating what an attacker might do to remove our offsite backups if they gained access to the Veeam B&R console.

An attacker that can do this has admin rights, which means they own the entire VBR server and can also delete from Object Storage; even with soft-delete, it's not perfect and likely such an attacker can get your Azure creds: https://docs.microsoft.com/en-us/azure/ ... ckup-items. Since Veeam doesn't do MFA, it would mean that somehow they likely could get access.

Focus on archive tier which supports immutability, or another S3 provider that provides "real" S3 immutability. Azure's offerings are half-baked from my point of view.

If you must use Azure, use v11 with Veeam and Azure Archive Tier
Post Reply

Who is online

Users browsing this forum: RedVision81, sfirmes and 16 guests