The three most effective and dangerous cyberattacks to Azure and countermeasures (part 1 – attack all the public and private IP addresses in Azure)

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 essential areas in Microsoft Azure, RBACStorage and Networking, everything in Azure depends on 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 were not even aware of that behavior.

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 of how it works, go to 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 surprised 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.

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 underestimate the internal threats, if a hacker penetrates a VM, he will also have 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 measurable, 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 to 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 lock it then 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. It is good. The pros are, it is very easy to configure and to use, and you don’t need to make 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 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 it:

  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 organize 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:

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.

Related blog posts