Zoheb here again with my colleague Tim Beasley. Today, we will be sharing some best practices to help ensure that your VMs (virtual machines) (including Domain Controllers) are secure in your Azure/Cloud environment.
I would like to start this blog with an African Proverb “If you want to go fast, go alone. If you want to go far go together.”
This proverb is one of the principals we refer to internally at Microsoft (#OneMicrosoft). It helps us utilize the synergy to build / leverage great ideas from other Microsoft employees across the globe.
This proverb sums it up perfectly of what occurred during the creation of this blog post. There were multiple contributors (Tristan Kington, Akhlesh Sharma, Pierre Audonnet and Shobhit Garg) who also helped provide details and additional information in hopes of benefiting our customers.
The Initial Problem I found myself facing – I forgot my Administrator Password!
While working in my lab environment in Azure, I sometimes forget what the Administrator password is (This rarely happens. Am I right? :p). Considering this is an important environment I needed to regain access to, I started thinking about different ways of retrieving my password.
Initially, I tried guessing what password was using a few random ones. However, this did not work (I have Azure AD Password Protection configured in my lab to help protect against known passwords :smiling_face_with_smiling_eyes:). I then tried the VM Password Reset option, but that only works for members of the local Administrators group.
Suddenly, I had an epiphany! I remembered the Extensions setting that is available for VMs running in Azure where you can execute scripts running under the System Context.
To achieve this, I located and selected the Azure Virtual Machine I was targeting and clicked on Extensions which is located under Settings. Here is where I will upload and execute a Custom Script Extension as shown below:
Figure 1. Click on Extensions.
Figure 2. Select Custom ScriptExtension.
Figure 3. Browse for the custom PowerShell script you wish to upload.
Figure 4. Select Upload to upload your custom PowerShell script.
As you can see below, I uploaded the testreset.ps1 PowerShell script (to be added as a custom script extension) and ran it on the virtual machine in my lab environment. The PowerShell script uses the native Command Prompt utility Net.exe. In this example, we used Net User to reset the password for an Administrator account named zdcadm using DontKeepe@syPassw0rd$ as the password.
Net User zdcadm DontKeepe@syPassw0rd$
Figure 5. Custom PowerShell script was uploaded.
After the extension was applied and executed against the VM, it successfully reset the password for my Administrator account (zdcadm), which allowed me to regain access to that VM.
We managed to achieve this because Azure VM Agent is installed by default on any Windows VM deployed from an Azure Marketplace image. When you deploy an Azure Marketplace image from the portal, PowerShell, Command Line Interface, or an Azure Resource Manager template, the Azure VM Agent is also installed.
Though I was happy that this allowed me to log back into the VM, it also started to concern me. So, I started thinking about how this could potentially affect our customers and whether they are protecting their environment from such risks where Privilege escalation can be gained by Azure operators to domain admin (and by extension, domain admin on-prem).
We found similar concerns that were raised / discussed for our traditional infrastructure (Hypervisors) where we provide broad guidance on how to secure them. You can learn more about this by reading the Virtualizing Domain Controllers using Hyper-V Microsoft article.
Why should you be concerned?
You as an organization who have DC’s in Azure or cloud you should check who has access to them in Azure & is the access to Subscription controlled well.
Do you have any Azure Operators who could do Privilege Escalation to become a Domain Admin?
Remember when you let someone else administer a lower layer than your own, you are implicitly trusting that person equivalently to yourself.
Increasingly we see permissions being mis managed in many organization and Identity team is not always managing subscriptions, this can lead to some loose permissions on your resources if left unmonitored/checked.
How can you check who has access to your Domain Controllers or Azure Resources ?
There are many ways you could see who has access to resources, I am listing one of the easier ways where you can get full information from a single dashboard.
Use the Azure Continuous Cloud Optimization dashboard, this can show the Azure RBAC (role-based access control) permissions from all the subscriptions a given Azure account has access to. You will be able to identify the roles applied to all Azure resources and if the subscriptions have custom roles. You can filter the information by:
The Solution to this little dilemma:
This made us think about the “Level of Protection” we should recommend to our customers that have important VMs (e.g. Domain Controllers) running in Azure. After several internal discussions along with reviewing publicly available Microsoft documentation, we decided that the following recommendations below will add an extra layer of protection to help secure your Azure IaaS VMs / environment (Not all, but heavy hitters)