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
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.
The attack to IP addresses is the most dangerous because it is also the most common, people ignore or completely under estimate it, for that reason is so dangerous.
this week we are going to examine another area, the storage, 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 no often use above these core services use storage in some form or another.
Everything and anything in Azure depend by the storage service, Skype, Xbox, Office365, virtual machines, databases, app services, everything and anything depend by 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 organised using partitioned namespaces, because the very large number of storages Microsoft decided to leverage DNS as part of the storage namespace and organise the storage namespace in three parts account name, partition name, and object name, the URL of any object is organised as below:


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

From a hacker perspective this is very important information, from the DNS we can already collect come 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 organised 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 weakness points that we need to be aware to protect our data and infrastructure.

There are three ways to access to 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 which contains the key, below an example of SAS Token created by Azure Portal.

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 uses 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 developer 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.
Does exist a real risk of a ransomware attack in the cloud?, 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, 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

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 in 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 unauthorised 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 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 recognising 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 se 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 are specifically designed to check the content and they use Artificial intelligence to quickly understand if the content can be something usable 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, table or queue.
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 subscription.
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, the 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 defence, 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 in the team.

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


Please enter your comment!
Please enter your name here