In many years in IT I learned one important lesson, which is also my first rule, everything and anything is hackable and vulnerable in some way.
Working in the security space opens your mind, anything you do during your job is related to hacking and finding vulnerabilities.
I almost play with anything in Azure and when I do I always make these questions to myself:

  • is this functionality secure?
  • is this functionality vulnerable?
  • if yes, how can be exploited and how much damage a person could cause?

You must always think like a bad guy if you want to fight them.

Internal attacks are much more dangerous and effective than the externals, and companies often underestimate that.
Cloud is more secure than on-premise, we can rely on a much more solid infrastructure but we know cloud has weaknesses.
In my experience on the field, there are three most important areas in Microsoft Azure, RBAC, Storage and Networking, everything in Azure depends by these three main pillars,
and considering these areas, I identified the 3 topmost dangerous cyberattacks, below the TOP Parade.

  1. Privilege escalation to Azure PIM and the Global Admin Account
  2. Ransomware Attack
  3. Attack to the public and private IP addresses

All these attacks are extremely dangerous and effective, however the privilege escalation is the most dangerous because it can escalate a top level, which means no more control in the entire cloud and company.

The attack to the public and private IP addresses (Red Team)

Companies share VM and resources in the public internet very easily, I think the problem is due by a wrong culture of the past, since some months ago, the creation of a public IP was a kind of default action during the creation of a Virtual Machine, many people where not even aware about that behaviour.
A public IP is attacked by a hacker after the first five minutes of life on the internet, this is a standard procedure, these people are not just kids playing with tools, these are criminal organizations looking for information to use against the company and employee.
You can find public IP exposed in Azure very easily, some of them are so easy to find that even a kid with no hacking experience at all can do, Shodan website is a very good example, Shodan.io is the top search engine for raw data on the Internet.
To give you a quick understanding go in https://www.shodan.io.

Create an account and execute the query below

azure org:”Microsoft Azure” port:”3389″

First finding a Windows OS exposed on the internet with username on a screen locked.

This VM is exposed and can be attacked using brute force and Mimikatz, and you will be surprise seeing how many old operating systems like Windows XP you will find.
Yes I know, this is very scary, but this is what people can do even without any specific hacking knowledge, let see in practice how hacker operate.

Tools like ZMap, NMap and others, are used by ethical hackers to scan the networks, the same tools used by a criminal.
Can we scan the entire Azure infrastructure for any public IP?

The answer is yes, we could scan the entire internet for any RDP port open in Azure using the command below

zmap -p 3389 0.0.0.0/8

but we can do much easier downloading the entire Azure IP range from below and scanning just the service we need, and these are public information.
https://hackazure.com/data-resources-dictionaries-other

Below a scanning example of private VNet looking for any RDP port open and saving the result in a CSV file, and we can also perform fingerprint/banner grabbing and much more complex operations.

These attacks are not just directed to the public IP but also to the private IP, which is often more exposed than the public one.
Never under estimate the internal threats, if a hacker penetrates a VM, he will have also access to the internal network, at least in the subnet, and if the VM is in the domain then the escalation of the damage is not calculable, it depends by the Azure experience of the hacker.

Let now think like a bad guy and see what he could do at the worst, the hacker could penetrate the VM and for the VM perform a privilege escalation into the accounts, if the VM is in the domain then the hacker could potentially escalate to the Global Admin account.
The hacker could escalate in another domain account and if the account has Azure PIM permission he can easily escalate to Global Admin, and from there, he can enable RBAC (Access management for Azure resources) for that account.
At this point the hacker has access to all the Azure EA contracts, resources and subscriptions tied to that company tenant, essentially the company is at the mercy of the hacker.

The Countermeasures (Blue Team)

There are some good options and practices to apply, let start from the easier and we will go with the more complex.

Option 1 – Don’t use public IP and if you really need then lock it and masquerade.

If you can avoid the using of a public IP then don’t use it at all, there are a lot of options to use, we will see them in the next options.
Assuming that for some kind of reason we need to then lock it and masquerade, to lock a public IP you can filter the sources for just some specific IP addresses.
Filtering the sources IP able to contact out public IP is a great option, we can also change the RDP port number and use a different one, this is not a great option to put on top but it is not a great solution.

Option 2 – Control the creation of new Public IP

Using Azure Policies, we can control this behavior, below a policy I created to control the creation of new Public IP.

{

  “properties”: {

    “displayName”“Block Public IP address creation in VM”,

    “policyType”“Custom”,

    “mode”“All”,

    “description”“This policy block the creation of public IP in the VM”,

    “metadata”: {

      “category”“Network”,

      “createdBy”“er-3151-4212-a25a-er”,

      “createdOn”“2019-06-17T12:01:45.0626421Z”,

      “updatedBy”null,

      “updatedOn”null

    },

    “parameters”: {},

    “policyRule”: {

      “if”: {

        “allOf”: [

          {

            “field”“type”,

            “equals”“Microsoft.Network/networkInterfaces”

          },

          {

            “field”“Microsoft.Network/networkInterfaces/ipconfigurations[*].publicIpAddress.id”,

            “exists”“true”

          }

        ]

      },

      “then”: {

        “effect”“deny”

      }

    }

  },

  “id”“/providers/Microsoft.Management/managementGroups/HexagonMIGroup/providers/Microsoft.Authorization/policyDefinitions/deas0-aa2c-4f18-b36c-dfdf”,

  “type”“Microsoft.Authorization/policyDefinitions”,

  “name”” deas0-aa2c-4f18-b36c-dfdf”

}

Below a good article explaining how to use it
https://docs.microsoft.com/en-us/azure/governance/policy/tutorials/create-and-manage

Option 3 – Use Azure Bastion

Azure Bastion is a great choice, I will write more in the challenge about it, and the concept is very simple.
We install an Azure Bastion in the VNet, the Bastion will expose a 443 port to the public internet and, from the Bastion console, we can reach our internal VMs using the private network and the 3389/22 ports.

I tried it and I am using it and it is good, the pros are, it is very easy to configure and to use and you don’t need to do any change on your network, the cons, you need to use your browser to work on the VM remotely and it is not the best option for people that need to work on that VM all day, like a developer for example, I think I could kill my boss at the end of the day.

Option 4 – Use VPN

We have three options to connect our on-premise resource to Microsoft Azure:

Point-to-site virtual private network (P2S VPN): this is a dedicate VPN from a single computer, each computer needs to configure the VPN connectivity in order to connect to the Azure VPN Gateway and through an encrypted channel over the internet.
The P2S VPN is used to connect a specific device or a person to Azure without using a more complex connectivity scenario, for example to connect a developer or a specific computer.

Site-to-site VPN (S2S VPN): in that case our on-premise VPN is connected to the Azure VPN Gateway and all computers in our on-premise VPN will be connected to Azure through an encrypted channel over the internet.

Azure ExpressRoute: this is the first-class connectivity, essentially, we create a private connection to the Azure backbone, we become part of the Azure backbone.

The VPN is the best option and we avoid an exposure to the internet however we still need to handle the private IPs because we can face an internal attack.

The Best practice (Blue Team)

As I said we also need to handle the private IPs and this is a much more complicated discussion, from my experience in the field there are just some very important aspects to look at and we can extend in the others if we need.

  1. Centralize the security control and access using a good subscription structure and firewalling appliance.
  2. Create a Base subscription, install ExpressRoute and firewalling and propagate the connectivity to the other subscriptions, this will give you a lot of control.
  3. Use a proper segmentation of the network and organise your IP Schemas and VNet by Regions.
  4. Create Azure policies and force your network rules
  5. Use Zero trust approach and limit any access

Microsoft publishes a very good guideline for that, check below

https://docs.microsoft.com/en-us/azure/security/fundamentals/network-best-practices

In conclusion, as you can see this attack is extremely dangerous, I hope you enjoyed this reading you found some good bits of advice to protect yourself and your company.

LEAVE A REPLY

Please enter your comment!
Please enter your name here