---
title: "Exposed Azure Blob"
canonical: "https://kb.cynergy.app/space/MD/899416227/Exposed%20Azure%20Blob"
format: markdown
---
**Description **

Azure storage accounts (Blobs) are used to store data in Azure. An organization’s cloud storage is a prime target for attackers looking to identify sensitive information for exfiltration. Depending on the settings set on Azure Storage accounts, companies could be unknowingly exposing their containers/blobs to the internet for direct access. 

Azure Storage is Microsoft’s solution for data management and storage in the cloud. Depending on the permissions set on an organization’s storage account and if the access keys / shared access signature (SAS) URIs are uncovered by an attacker – attackers can connect to an organization’s storage account and pull the data stored.

**Hacker's View**

As a hacker, I can run scanners to detect open and misconfigured Azure Blobs using tools like [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) 

[MicroBurst](https://github.com/NetSPI/MicroBurst) or Azure Portal or use platforms like [Grayhatwarfare](https://buckets.grayhatwarfare.com/) once I have identified a Blob that is accessible and which contains interesting/sensitive information. I would download the information and try extorting the organization. If the information contains secret keys or other information that may help me to get even stronger access to the organization’s assets. 

Manually test access to a bucket using the following convention:

- <Storage_Account>.blob.core.windows.net”

Finding out the container name, followed by discovering the access keys (using Azure CLI). Since it is not possible to download files from a blob without knowing the exact name, I will run an enumeration attack to identify the file names in the blob.

The data extraction can be done using the [SAS URI](https://docs.microsoft.com/en-us/rest/api/storageservices/create-account-sas) and Azure Storage Explorer. 

Once I have access to the sensitive data, I will then try to extort the organization or use the data collected for other attacks. 

**Mitigation**

Change the blob access policy based on the below references per the Azure recommendation. 

<u>Data Protection:</u>

- Use the Azure Resource Manager deployment model
- Enable Microsoft Defender for all of your storage accounts
- Turn on soft delete for blobs
- Turn on soft delete for containers
- Lock storage account to prevent accidental or malicious deletion or configuration changes
- Store business-critical data in immutable blobs
- Require secure transfer (HTTPS) to the storage account
- Limit shared access signature (SAS) tokens to HTTPS connections only

<u>Identity and access management</u>

- Use Azure Active Directory (Azure AD) to authorize access to blob data
- Keep in mind the principle of least privilege when assigning permissions to an Azure AD security principal via Azure RBAC
- Use a user delegation SAS to grant limited access to blob data to clients
- Secure your account access keys with Azure Key Vault
- Regenerate your account keys periodically
- Disallow Shared Key authorization
- Keep in mind the principle of least privilege when assigning permissions to a SAS
- Have a revocation plan in place for any SAS that you issue to clients
- If a service SAS is not associated with a stored access policy, then set the expiry time to one hour or less
- Disable anonymous public read access to containers and blobs

<u>Networking</u>

- Configure the minimum required version of Transport Layer Security (TLS) for a storage account.
- Enable the Secure transfer required option on all of your storage accounts
- Enable firewall rules
- Allow trusted Microsoft services to access the storage account
- Use private endpoints
- Use VNet service tags
- Limit network access to specific networks
- Configure network routing preference

<u>Logging / Monitoring</u>

- Track how requests are authorized
- Set up alerts in Azure Monitor

<u>Manual Fix</u>

##### In Azure Console

1. Log in to the Azure portal
2. Navigate to 'Storage Accounts'
3. Select the reported storage account
4. Under 'Blob service' section, Select 'Containers'
5. Select the blob container you need to modify
6. Click on 'Change access level'
7. Set 'Public access level' to 'Private (no anonymous access)'
8. Click on 'OK'

##### During Build

##### Terraform

- **Resource:** azurerm_storage_account
- **Argument:** allow_blob_public_access

Go

```
resource "azurerm_storage_account" "example" {
              ...
+             allow_blob_public_access = false
              ...
            }
```



**Cynergy’s View**

Cynergy detects the publicly exposed blobs and notifies the client regarding the exposure. In addition, Cynergy identifies all the exposed files in the specific blob and contextualizes the exposure. differentiating between different file types and exposed content. 

Cynergy is constantly comparing your environment to a baseline of appropriate configurations and behavior, looking for deviation. The moment a deviation is detected, such as a public-facing Microsoft Azure blob, Cynergy would flag the issue.

A few things to note: a lot of vendors today provide Cloud Security Posture Management (CSPM) solutions including this monitoring and detection, but next-generation platforms such as Cynergy take things a step further. Let’s say there is a misconfiguration, like a lack of authentication needed to access the content of a Blob, and your CSPM tool detects it and issues a ticket to your security team. This ticket will sit at the back of a queue of other security concerns, or the alert can get lost in a sea of notifications the security team receives. Or maybe there’s a specific team responsible for tackling the issue, but this alert goes to a general queue. What if it’s Friday evening and your employees are signing off for the weekend?

In this case, your organization needs an efficient way for the correct team responsible to receive the alert, and it needs context in order to recognize that this specific alert, among so many others, is a pressing concern deserving immediate attention. Even a step further, it needs a way to remediate the concern without manual action.

This is why Cynergy aims to automate the process from detection via contextualization and remediation of the exposure. 

**Reference**

Azure official recommendation- [https://docs.microsoft.com/en-us/azure/storage/blobs/security-recommendations](https://docs.microsoft.com/en-us/azure/storage/blobs/security-recommendations) 

Inversecos - [https://www.inversecos.com/2022/01/how-to-detect-and-compromise-azure.html](https://www.inversecos.com/2022/01/how-to-detect-and-compromise-azure.html) 

Ibtimes - [https://www.ibtimes.com/british-council-massive-data-breach-exposes-144000-student-files-heres-how-stay-3391283](https://www.ibtimes.com/british-council-massive-data-breach-exposes-144000-student-files-heres-how-stay-3391283)