The three most effective and dangerous cyberattacks to Azure and countermeasures (part 2 – attack the Azure Storage Service)

Microsoft Azure, a beast forged from the hell of the fabric controller hosted by the Windows Azure kernel operating system, it is solid and big, full of everything and anything, however, as any beast, it has weak points. Weak points that you should know well in order to defend yourself from cyberattacks.

Azure runs on top of three major pillars, Authentication and Authorization (Azure AD and RBAC), Storage and Network, and these are also the weak points, these are the most critical and vulnerable areas.

Last week, in Part 1, I presented the attack to the private and public IP, there are many other types of attacks to the network, some of them extremely sneaky, especially if you are able to think like a bad guy and you know Azure. Nevertheless, the attack to IP addresses is the most dangerous because it is also the most common type of attack and people ignore or completely underestimate it. For these reasons, it is also the most dangerous type of attack.

This week we are going to examine another area, the storage, and why storage is so important?

I remember streaming on channel 9 in 2015 where the Azure Storage PM was explaining the Azure Storage service and he said, every Azure service that you use and don’t often use above these core services use storage in some form or another. Everything and anything in Azure depends on the storage service, Skype, Xbox, Office365, virtual machines, databases, app services. Everything and anything depends on storage service, you hit the storage service and you hit the core, for that reason, it needs much more consideration than any other service, with Network, Azure AD and RBAC.

Azure Storage Service was released in 2008 and it is the file system of the cloud platform with a different type of abstractions called blobs, disks, tables, queues, files and it is reliable, durable and extremely scalable, trillion of transactions a second, that’s is pure power no doubts. It exposes a huge REST API interface and many client libraries like .NET, Python, Java, Node.js almost everything, you name it and you find the library, but let go deeper, blob, table, and others are just abstractions, like the files for the NTFS file system, how Storage Service works?

Azure Storage Service is organized using partitioned namespaces because the very large number of storages Microsoft decided to leverage DNS as part of the storage namespace and organize the storage namespace in three parts:

  • account name;
  • partition name;
  • and object name;

The URL of any object is organized as below:

  • http(s)://AccountName.<service>

Where <service> can be blob, table, and queue.

From a hacker perspective, this is very important information, from the DNS we can already collect some very important data:

  • The Account name is extremely important because it is used by Azure to locate the primary storage cluster and the datacentre where the storage is located, all the requests for this account are directed to this location, an application can use a different account for different locations.
  • The Partition name identifies the storage node of the cluster and it is used to scale-out access to the data, the ObjectName is the specific object in the partition, the transactions are atomic and managed across the different objects inside the same PartitionName.
  • The Account Storage architecture has been organized to provide the maximum capacity and scaling, the let see the most important components and how it works.

  • The Storage Stamp is a cluster of N racks of storage nodes, and each rack is a separate fault domain, the challenge is to maintain the storage provisioned in production as highly utilized as possible if a rack reach lower then 70% the account is migrated in another rack
  • The Location Service manages the account namespace across all stamps and all the storage stamps, it is also responsible for disaster recovery and load balancing, the LS updates the DNS and allow the requests from the name to that storage stamp’s virtual IP (VIP, an IP address the storage stamp exposes for external traffic).

The three layers in the Storage Stamps:

  • Stream Layer is like a distributed file system layer within the stamps, it understands files, called streams, and it manages how to store, replicate them and more but it doesn’t have any clue about the data or the semantics.
  • The Partition Layers manages and understands the high data abstraction layer (Blob, Table, Queues, and Files), caching objects, and storing objects on top of the streaming.
  • The Front-End layer manages the authentication and authorizations for the account though SAS token or Access Key, and it governs the relations between account and partitions.

All the data are encrypted and decrypted transparently using 256-bit AES encryption, one of the strongest block ciphers available, and is FIPS 140-2 compliant, the Azure Storage encryption is similar to BitLocker encryption on Windows.

The replication is composed by two main replication areas, the Inter-Stamp Replication layer (Partition layer, synchronous replication) and stream replication layer (Intra-Stamp Replication, asynchronous replication), the data are replicated across the storages stamps all time.

This is a high-level description of the architecture, but it gives us a clear idea about how it works, there are some very strong and consolidate patterns and features. However, there are also weak points that we need to be aware of to protect our data and infrastructure.

There are three ways to access the internal objects (Blobs, Tables, Queues, and Files), SAS Token, Account Keys and RBAC.

  • SAS Token is a long string hashed key (256256) that we can create at any time we like to provide temporary access to any of the internal object, it is a hash string that we can create at any time from the portal or using PowerShell or Azure API.
    The hash key is provided with a URL that contains the key, below an example of SAS Token created by Azure Portal.

Note: The SAS token is used for temporary use and it provides access to specific objects, not to the entire account.

  • The Account Keys are two, the primary and the secondary, we can set expiration and we have access to the entire storage account, this is the most common approach used by applications and developers, and we can set an expiration.

  • RBAC is used to provide access to the storage account to a specific user, using this approach we have access to all the storage account, this is the classic method used to manage the storage account by people through the Azure Portal.

Let now examine in deeper some potential weakness areas and the type of attacks that we can perform.

Attack01 – Access using account keys: Red Team

Developers use account keys everywhere, they send by email, they write in the code and often they take notes in files and there are different techniques to use.

Google Dorks are used by a hacker to collect any type of information on the internet, it is a very powerful technique, especially if used is a smart way, the query is an example.

allintext:accountkey blob filetype:config

The query will search in all Google database for any file indexed of type config, containing the world accountkey in the web sites and

The githup is not a typo, google may filter some query types, using this technique you can evade them.

The query shows some links and the first is containing a key, this is a very simple query but we can do much more.

Developers often share critical information on the internet and sometime the key may provide access to something very important or critical. We can also find this information in source code repositories, in Azure DevOps, this is another great area to find these kinds of information.

Attack01 – Countermeasures: Blue Team

  • Create Azure policy to block any unauthorize key vault creation (use a dedicated AD group/user)
  • Set less permission privilege to the Key Vault, monitor any access and notify by email any change
  • Store any sensitive information in Key Vaults and force developers on using this practice.
  • Execute automation source code scanning with Azure DevOps

Attack02 – Ransomware attack and encryption

We now know that Azure encrypts any data in the storage account, and this is good, especially because this is a requirement for certifications like ISO 27001, ISO 9001, GDPR and others. Nevertheless, you should question yourself if:

  • Does exist a real risk of a ransomware attack in the cloud?
    • And the answer is yes.
  • What an attacker could encrypt?
    • Potentially the entire storage account, all virtual machines, and disks.

A hacker could achieve a privilege escalation attack to the cloud or find the account keys and access to the storage account, in that case, the hacker has different choices. One quick and very dangerous attack is on the encryption keys, using this technique an attacker is able to encrypt the entire storage account very quickly, we will explain below how it works.

Azure uses two mechanisms to encrypt the data:

  • one using the internal encryption key;
  • and the second is using an arbitrary key created by the customer.

We are now going to simulate an attack to the encryption keys, I assume a basic knowledge of Storage Account and Key Vault.

Note* – that all these steps can be easily replicated using different scripting options, I use the portal for a better understanding of the procedure, below the link


Yellow Team scope

  • Create a Storage Account and create a file share.

  • Upload a test file, click on Connect and copy the second command

  • Open a Windows console and execute the command, we now have the Azure folder shared, this will be useful to better understand the experiment.

Red Team scope

To execute a privilege escalation attack to Azure, you need at least contributor access to the resource group.

  • Create a Key Vault

  • Now create a key

  • Select the key and execute a backup and save the file on disk.

  • Select the current version of the key and copy the Key Identifier

Now we are going to assign our encryption key.

  • Enter in the Azure portal in the storage account under Encryption and check to Use my own key, paste the value and click save.

Now the storage account is using our key and it will encrypt all data in the account.

The attacker now will delete the key from the key vault, enter the key vault and delete the key.

Yellow Team scope

  • Check the status of the share, after a while, you will receive an error, delete the share and try to reconnect.

We are not able to connect to the share anymore.

Attack02 – Countermeasures: Blue Team

The best option is using policies and blocks any unauthorized usage, especially creation.

  • Create Azure policy to block any unauthorize key vault creation (use a dedicated AD group/user)
  • Set less permission privilege to the Key Vault, monitor any access and notify by email any change
  • Use Multi-Factor Authentication in any sensitive location of the company.

Other considerations:

My first attempt as Blue Team has been trying to regenerate the storage account key and try to access the folder.

But the storage account has been compromised

Also if I try to access from the Azure portal

I also tried to disable my own key option but this is not an option either.

It looks like the only solution now is restoring the storage account key.

Attack03 – attack VMs and Disks: Red Team

Another option is encrypting the content of the storage account, for example, all disks, this is a procedure that we can achieve using Powershell and remotely, below a link with an example:

The attacker could also encrypt the entire VM using BitLocker and PowerShell:

Attack03 – Countermeasures: Blue Team

  • Create Azure policy to block any unauthorize encrypting operation (use a dedicated AD group/user)
  • Set less permission privilege to the resources
  • Use Multi-Factor Authentication in any sensitive location of the company.

Attack04 – Storage Tampering attack: Red Team

This is an extremely effective and dangerous attack, the hacker found the storage account keys and will execute a scan in the account, below an example to list Blobs using Azure CLI.

az storage blob list -c MyContainer --prefix foo

The link below is the full guideline:

The attacker has now a clear idea about the content and he will inject in the storage account-specific malicious content. The hacker could upload malicious scripts, PDF files tampered and more.

Developers and IT administrators use the queues to execute specific infrastructure tasks and execution following a specific FIFO order, the hacker could inject messages in the queue and execute arbitrary code and script.

This Azure storage tampering is usually used in conjunction with the phishing attack.

Attack04– Countermeasures: Blue Team

The prevention is the best countermeasure, we must prevent access to the resource.

  • Create Azure policy to block any unauthorized usage (use a dedicated AD group/user)
  • Set less permission privilege to the storage account and to the specific resource, monitor any access and notify by email any change
  • Refer to Attack01 regarding the protection of the keys
  • Use Multi-Factor Authentication in any sensitive location of the company.

Attack05 – a Phishing attack

This is a very used attack because able to be combined in many different combinations, the concept is very simple.

Any blob exposed by the storage account is using the same domain, see an example below:

The domain is trusted because hosted by a Microsoft service, let navigate to this endpoint and check the certificate.

And see the certificate

This is a trusted web site, the attacker can send email using this URL without being intercepted or blocked, and it looks a legitimate URL. The hacker can simulate an internal communication and an employee could click on the URL and open a malicious file hosted in the blob.

This is a very simple example, in the future we will examine some nasty phishing attacks using a blob storage account.

Attack05 – Countermeasures: Blue Team

  • Robust email security solutions are actually the best option, also filtering any email containing the domain.
  • Educate employees about recognizing different types of phishing attacks and avoid clicking any link.
  • Use multi security layers, scanning email, antivirus and use the red team to test malicious attack.
  • Educate everybody in the companies, also the very top management.
  • Use Multi-Factor Authentication in any sensitive location of the company.

Attack06 – Attack to Blob and resource using anonymous access: Red Team

We can set the reading access type of the container and blob as anonymous, see the picture below.

We may need to use this setting because we want to provide public access to our content, hackers use this setting for phishing attacks.
Black hats daily scan the public internet and they check the contents of these blobs, let see some easy techniques.

Option 1 – Using Shodan

Login with a free account to and use the search string below:


As you can see we have already found many blob storage to check on the internet.

We can now filter for organizations or companies

Option 2 – Using scripting
This is the most productive and effective way to collect anonymous blob storages, we can use any script type technique, the concept is quite simple.

During an HTTP GET to request the anonymous blob storage responds in a different way from a private one, this is the discriminant, let see an example below:

We can easily create a program or script to create any possible combination of the account name and check for any possible public blob on the internet. The procedure below is a simple representation of what criminal companies do using very high calculation power, think about entire datacentres used for this scope.

The program used by these companies is specifically designed to check the content and they use Artificial intelligence to quickly understand if the content can be something useful or not.

Attack06 – Countermeasures: Blue Team

  • Don’t publish any sensitive information in public storage.
Important Note
The usage of public blobs can be a good honey trap, criminals will be focused on that specific area of attack, you may also put false and misleading information.
The honey trap is an interesting strategy and it can be extremely effective if well planned, we can also make the criminal think what we want and discourage them from continuing any more investigation to the company.

About the Privacy

Privacy is another important aspect because not easy to achieve without significant actions. Any user, with Reader role at the storage account level, can read everything in containers, files, tables or queues. We can assign or deny specific access to specific user or group to a specific internal object, see below an example with a blob

The problem is that the storage account will inherit the account from the top levels like resource groups and subscriptions.

If you require a very high-security level, I recommend to isolate these storage accounts in a different subscription and, in case, also using a different tenant tied to that subscription.

Last considerations

In this article we examined the most important and dangerous attacks to the Storage Account, prevention is always the best practice and in order to achieve that we need to use Azure Policies.

Azure Policies are the first line of defense, the first opportunity to stop the attack. This is what we need to achieve, we need to stop the attack from the beginning and not in the during.

We also must remember that the most dangerous attack always starts from the internal, we need to make our home secure from any risk.
Don’t trust anybody, even yourself, if you are not sure about something, better ask and discuss it in the team.

In the next article, we will examine the last and most dangerous type of attack, the privilege escalation.

Related blog posts