Why Control PowerShell In Azure

PowerShell brings automation and automation can be key to running an environment. The problem is, if it isn’t controlled, “automation” can be used against you.

If you have an Azure environment, you may know that you can connect using either PowerShell or Bash. You can set this up on any machine by loading PowerShell for example and running:

• Install-Module az
• Connect-AzAccount

This will give you a login box in which you can use your Azure credentials.

This is the first step that requires a little locking down. It will make more sense later on however, you should defiantly look to enable Conditional Access around the application Microsoft Azure Management. This application includes PowerShell.

If you didn’t want to worry about the location and endpoint however, there is a strict enforce in preview:

If MFA is not enabled, this prompt can be passed using single factor. Once in, I could run the following:

Now if I didn’t add the -WhatIf, it would have deleted all my VMs. The disks and NICs would remain, however this is just an example. I can just end the original with an ; and add additional resource such as groups:

I do obviously need to have the privilege and remove the -WhatIf but hopefully you can see that you can do some damage with a single line of code.

With the addition to the conditional access, It might be worth adding locks to resource. These locks can be applied to different layers of resource and give you the option to apply either a read-only or delete lock. The delete meaning that you can delete the resource until the lock is removed and red-only meaning you can’t make changes.

Even if the attacker used PowerShell with an Owner account, the Remove-az* action cannot run. Even with the -Force. This is because the lock is stopping it. They could in theory run Get-AzResourceLock | Remove-AzResourceLock but the locks could help prevent accidental or poorly coded malicious scripts.

Another area of PowerShell to be aware of is that scripts can be ran remotely through the Portal itself.

If you went into a VM and clicked the Run command tab, you can actually execute a PowerShell script/command using the SYSTEM account. This you would need to control by IAM on the resources themselves.

There are restrictions however, but as you can see, it’s defiantly worth being aware of. https://docs.microsoft.com/en-us/azure/virtual-machines/windows/run-command

There are more elements to this but hopefully you can see the need to apply basic countermeasures to keep your cloud safe. The MFA control should be a standard and if you want to go further, I would suggest locking to down to corporate IPs. The reason why is that the flip to this is that, even if you have a locks and controls in place, an attacker can still cause damage. They could either, spin-up resources to cost you money or even lift the Public access to your networks. If not auditing or monitored, you may only be made aware after an attack has occurred.