Azure Backup: Built-in Ransomware Defense

[Music] all right this is a quick overview of capabilities that are built into Azure that allow customers to protect themselves against ransomware attacks and what that means is that if you're an unfortunate target of a ransomware attack and they are able to take control of your on-premises Active Directory by using cryptographic technology or cryptolocker attack it allows you to recover your domain controllers and the other servers that you choose to protect very effectively and quickly and it's a very inexpensive and easy way to get these services up and running to protect you using a couple of features that are built into Azure the first one I want to discuss is called as your backup and I have the link to the documentation on where you can find the detailed articles on how to set it up and how it can help you prevent against attacks and I'm gonna walk through a really short screen by screen show for those who want to see how it is done how this allows you to protect yourself so many public sector customers already have domain controllers because they're using office 365 and they may have set up a DFS servers with domain controllers so they can have single sign-on into office 365 and in that case you may already have domain controllers running in Azure where you can very easily set up as your backup to backup your domain controllers and frankly any other servers that you have running in Azure and turn on some advanced security features to protect yourself against these type of crypto attacks and what it is is it's built in additional features that do not allow administrative accounts to go back and remove things or change certain settings within the azure backup software that would be a typical attack pattern for a crypto attack where first things they do is find your backups and delete them and then they encrypt you're running production systems and then you're left stuck and I'm sure you've read plenty of news articles about how bad that can be and how long it can take to recover from so very quickly the first thing that you do in your Azure tenant is you create an azure recovery services vault this is the storage load the backups of the different virtual machines will be stored and there's a special security settings blade there at the bottom middle of the page that allows you to turn on this highly effective security feature that prevents these types of attacks by stopping a person from altering changing and/or deleting your actual backup data these features force a certain retention policy to make sure that there's adequate time to recover things and they disable certain features like a hacker turning off your security alerts or turning off the number of restore points that you have in your backups though they would prevent your backups from being effective so once you do turn this on you cannot turn it off and think of that that's by design otherwise a hacker could go turn it off so once you turn it on its irreversible and these particular policies will be enforced if you do need to edit policies there is a setting that allows you to set up a special pin and of course it's always recommended to have multi-factor authentication and it will alert everybody in the appropriate email distribution group that somebody's making changes to your backup software from the documentation retention policy that will be enforced as if you're using daily backups a minimum of seven and weekly a minimum of four monthly a minimum of three and at least one yearly if you're using that and these things are more of an art than a science we talk about recovery point objectives for most customers a typical scenario would be to store your weekly backups in this manner at a minimum and there'll be other examples as well as we go through the story you select the virtual machine in this case I have an example domain controller right next to my Azure Active Directory Connect server that's running in Azure I select it and I assign the backup policy to it and then you can see that it's been running for a period of time and I have several iterations of snapshots as well as full backups in the vault that I can recover from going back as far as I have chosen to set the retention policy so in this demo environment where I took screenshots from my oldest restore point was set for September 12th and if I had a 90 day policy on this it could have gone as far back as that before I would be able to remove or delete these backups from the vault how restoring to a separate network in the event of a cryptolocker attack is also very easy and it's perhaps one of the biggest benefits I can just create a new virtual machine install it into a new private network I can restore my domain controller that I think is the most appropriate restore point whether that's I believe the attack happened 30 days ago or 45 days ago I can actually restore two different ones that I can compare the difference between the two so I can try to find out what changed which account may have been compromised and how an attacker obtained elevated credentials into my Active Directory forest and this is the first step in conducting forensics to excise any compromised accounts that may have existed in your Active Directory once you have that right then you go through the normal process of rebuilding an Active Directory for us you have your FISMA roles which are the flexible single master that allows you to create additional Active Directory Sites and from that point I can rebuild my domain controllers on-premises and connect them into this newly restored one that I set up in Azure so that's a very brief overview of how quickly and easy this can be set up for you if you already have domain controllers running in Azure using Azure backup and it applies equally well to any other servers that you have running in Azure so now I'm going to move on to the second type of defense which is a mutable blob storage now this requires a little bit more of an explanation into why and how that you would want to use it so as your blob storage is really just a massive amount of disk space that's extremely inexpensive that you can procure with in Azure you create what's called a storage account you create containers underneath that storage account and you give them names and you're allowed to from that point forward drop objects into storage and the best example of an object in this scenario is an actual copy of a backup file that I have may have taken on-premises so in my environment I may have be using backup software such as Veritas or CommVault or Veeam it doesn't matter who and I'm writing these to a file system somewhere so I have my own backup software and I can recover files and recover entire servers if need be well using immutable storage I can take a cop be of that backup and I can put it into Azure blob containers and I could use the flags built into the platform to turn it into a worm drive which worm stands for right once read many which essentially means that it's immutable and can't be changed so even in the event that an attacker took control of my own premises environment founded my backup servers found my backup files and either deleted them or encrypted them I would still have this immutable storage container up in Azure or I can recover the most recent backup that I wanted to use for store process or the most appropriate backup based upon the length of the attack or the duration of the attack and once again go through the recovery process in a very similar manner to what I outlined using Azure backup so here are screenshots of how to set that up this is a storage account and I create a new blob container and I give it a name and I create additional containers and I put an access policy on them and in this example selecting the access policy I choose a mutable blob storage with time-based retention and I can set the number of days that I want that to be set for so in this screenshot I only have it at 3 days where I'm doing a lot of testing and making sure things work the way they want but in the real world you would set that interval to be much longer for how long you want to keep your data and have it be immutable and then I lock it after I have created it and this effectively prevents any changes from happening to the policy itself and I have a mutable storage from that point forward for the duration and any objects that I put into that file from that into that container from that point forward inherit the amount of time that's associated with that policy and I'm asked to confirm this and say hey do you really want to do this and the reason for this confirmation is somewhat self obvious in it once I start putting data in here if it's a confirmed and locked retention policy I have no ability to go back and make changes to it that's by design therefore if I put big stuff in there and I put a super-long retention policy on it I have no way to get rid of things that I don't really want anymore so the setup of this requires a little bit of planning and that's an important consideration but once I have it if I tried to delete something out of the container the container itself or the storage account you're going to get a failure even if you're an administrator because that policy is immediately put into effect as soon as I created it in any files that were already in it or any subsequent files that were put into it you inherit that policy and the time duration that is associated with it so this brings us to the discussion on how you would want to consider using this so a 90 day policy makes a lot of sense to me because if you have a lurked attacker in your environment for greater than 90 days that would be probably extraordinary but if you have more comfort and you want to keep a longer retention policy that's fine and go to 180 days or a full year but these recovery point objectives are usually different from regular backups where you might want to do just a single item recovery so in this example I'm saying created a storage account with a 90 day retention policy at each of your containers and place a copy of your weekly backup files in those containers and then you can age them out appropriately you can add domain controllers file servers data servers database servers application servers almost any kind of data type from a backup file could be dropped in there and allow you to protect more things than just domain controllers and then as the container ages and once it's reached a date and time that you would no longer consider it useful for being restored you can go ahead and delete those objects but the delete operation of course will fail until you've passed the end date of the last object that was placed in the container so if it's a day before the policy expires and I drop a new backup in there it's still going to protect that container for another 90 days if that's what the 90 day retention policy was and as mentioned earlier we can adjust this for longer if there's discomfort in a 90 day policy now this type of storage is used for many scenarios many of our backup vendors have direct integration with Azure storage in the backend and so an example here is conv alt they'll help you configure within their console the warm storage mode in their cloud storage and it'll actually allow you to use the conv all backup console to continue to do all the backups that you want and just target and as your storage account and take advantage of them storage feature within a sure there are other vendors that do this as well I'm just using this one as an example and there's specific documentation on how to set this up and that it supports all those different storage types within a sure so having said that I want to take a minute break into a quick demonstration on how you might go about using this so inside a sure this is an example of an azure tenant and US government asher and these are all resource groups and a resource group is just a role based access control boundary where I can go create things so I have created resource groups and inside them or a storage account and inside this storage account are the containers that we talked about and I can play different retention policies on each of these containers so if we're back to the 90-day policy test could be one quarter test two could be another quarter and test three could be another quarter and each of them would have a separate retention policy so I'm gonna run a real script script here very quickly and it's gonna show you how to create a new one I'm just gonna increment these numbers for people who like to go a little bit more technical and want to understand how this works so this is a PowerShell script and all it's doing is it's creating a new storage account and giving it a name and then it's applying a really quick policy to it down here and I have the immutability period set for one container to just two days and the immutable period set for the second container to three days and of course I can easily change that this is just for testing purposes and then I upload a couple of small files within the script just to prove that it works so I'm going to go ahead and save this and then go to the console go ahead and say run it and once I thought Center Kade there are a couple script so I can validate the settings and make sure I'm happy with them these could be removed if you wanted it to run faster it's just creating the things that I put in the script setting up the storage account you can see it's named crypto defense 16 in the bottom terminal window you and yes it does take a couple of seconds for it to create the storage account then it moves on to create the storage context in the containers and apply the policy you and now the script is complete so if I put this down and look at it I go back into the resource group view and i refresh this you can see the new container you can see the new storage account you can see the new items and if I come over here and show you the access policy you can see that it's set to a time-based retention of two days and it's locked and you can see the second one actually has data copied up into it oops also has an access policy and it's set to unlocked so I'll come over here and explicitly lock it and say yes I have a locked retention policy on that container as well for three days so if any point in the future I copy files in there they will inherit that policy and will be good for three days from the time that I drop anything new into that container now you may be asking is this a manual processor can I oughta mate this and you most definitely can so this is a different kind of PowerShell script and this is intended to be run on premises or on an actual server that could go to the location where you store your backup files so in my case I have some example files stored in a folder here on my local hard drive the script could actually be running locally in your own data center and it could use the AZ copy command to push things directly into account so I'm gonna create a container for it a new container I'm gonna call it test 0-3 that's created and I'm gonna come and set the policy on it one more time so you can see what that looks like if you want to do all of this manually and not script anything I'm gonna choose a time based retention policy I'm going to set it for three days and I'm gonna say okay and then I'm gonna lock it say yes now the policy cannot be changed in any data that I put into there is going to inherit that policy so now if I go back to my script I see that I'm pointing at the correct storage account pointing at the correct container I have to do something with this particular string here at the end that's called a SAS token which is a shared access signature this for the very technical parts this is how I'm allowed to connect to this storage account and actually not get prompted for an interactive login which allows me to fully automate this and not have to sit at the keyboard and type in credentials so this stored access signature allows me to grant all kinds of different permissions so if I was setting this up for a 90 day policy in a particular storage account I would pick 90 days worth of stuff but for the purposes of this demonstration this token is only going to be good for 8 hours so just today I'm going to say go ahead and generate it this is the token itself it's really gnarly looking string that starts with this question mark SV I'm gonna copy that into my clipboard I'm gonna put it into my session starting right here I paste it in there and now this copy command will not prompt me for credentials it'll take the files that are on my local hard drive and it will push them up into this newly created storage group and this newly created container named test 0-3 so let me save this file and then go ahead and run it you'll see that it created a log file and it copied two files directly in since they were small files it ran really fast now if I go back into my group there's my storage account here's my container test zero three and here's my two files that I put in there we will go ahead and download one take a look at it and you can see that we have a seal one of our customers that concludes the demonstration part I just want to point out how simple and easy that was to set up and do manually so you could in very very short number of days complete cryptolocker defense protection against your domain controllers and other backups just by creating a storage account marking it and saving it with a mutable policy it becomes a worm drive at that point any files that I put in there inherit that policy and even though I'm an administrator I cannot delete these files no matter how hard I try I try to delete them even though I'm an admin I get the deletion fail failed to delete the blob this operations not permitted because it's immutable doing a policy if I come up a layer and try to delete the entire container it won't let me do that either because it said the container is protected and if I tried to delete the entire storage account the same thing would happen you you you get a failure and that concludes the demonstration for today failed to delete you

Channel: Azure Ninjas

Views: 889

Keywords: ransomware, backup.resilient

Id: 4Y0evlH6nb0

Length: 20min 59sec (1259 seconds)

Published: Tue Oct 01 2019