How long does it take to detect and identify attacks on cloud resources? And how much time does it take for the Azure Blob container? Do you know if your cloud storage is part of a malicious attack? Or, if adversaries recon your cloud storage? Defenders have a lot to cover.

This post will be focused on How to defend with specific scenarios and research the existing environment, to search for the security issues and misconfiguration on Azure Blob Container. This post continues the previous post that focused on the Azure Blob Container Threats & Attacks. This post won’t provide ways to block access with Private Link or via other Auth methods. The next post will be focused on Blocks and remediations.

The questions I raised are a tiny part of the questions that each Blue Team needs to ask themselves because your current situation, visibility, and security controls don’t allow them to know what is exactly happening in the cloud and specifically in the cloud storage – a known situation for 95% of the environments.

So how can we prevent unauthorized access to Azure Storage and prevent the use as a conduit for malware artifacts such as ransomware payloads or malicious Javascript or moving malicious code laterally? We can minimize security issues using basic security hygiene procedures and specific recommendations.

Let’s review the capabilities and the options that can help every environment in a multi-cloud scenario. The following instructions and security tools are based on Microsoft Sentinel, Defender for Cloud, Azure Policy, and security hygiene.

Public Access and Blob Containers

Anonymous public read access to containers and blobs in Azure Storage is a convenient way to share data but may also present a security risk. Operational complexity, human error, or malicious attack against data that is publicly accessible can result in costly data breaches. It’s essential to manage anonymous access judiciously and understand how to evaluate anonymous access to your data. Microsoft recommends enabling anonymous access only when necessary for your application scenario.

For enhanced security, you can disallow all public access to storage accounts, regardless of the public access setting for an individual container. By default, public access to your blob data is always prohibited. However, the default configuration for a storage account permits a user with appropriate permissions to configure public access to containers and blobs in a storage account.

Disallowing public access to the storage account prevents a user from enabling public access to a container in the account. Microsoft recommends that you disallow public access to a storage account unless your scenario requires it. Disallowing public access helps to prevent data breaches caused by undesired anonymous access.

When you disallow public blob access for the storage account, Azure Storage rejects all anonymous requests to that account. After public access is disallowed for an account, containers in that account cannot be subsequently configured for public access. Any containers that have already been configured for public access will no longer accept anonymous requests.

from Azurestack

When you disallow public read access for a storage account, you risk rejecting requests to containers and blobs currently configured for public access. Disallowing public access to a storage account overrides the public access settings for individual containers in that storage account. When public access is disallowed for the storage account, any future anonymous requests to that account will fail.

To understand how disallowing public access may affect client applications, Microsoft recommends that you enable logging and metrics for that account and analyze patterns of anonymous requests over an interval of time. Use metrics to determine the number of anonymous requests to the storage account, and use logs to determine which containers are accessed anonymously.

Know what you have

As with any other scenario, we need to know what we have in order to know what we can defend. Cloud inventory is the first action that needs to perform in order to know what exactly you have got. The built-in Azure tools can be suitable for Azure resources and Blob Container, so let’s use the first tool.

Azure Resource Graph Explorer

The Azure Resource Graph Explorer is designed to extend Azure Resource Management by providing efficient and performant resource exploration with the ability to query at scale across a given set of subscriptions so that you can effectively govern your environment. Now that we know it can query resources with complex filtering, grouping, and sorting by resource properties, we can use some of them to identify our resources.

The following query provides all storage accounts with network ACL, public access, private endpoint connection, etc.

resources
| where type == "microsoft.storage/storageaccounts"
| extend RG = substring(id, 0, indexof(id, '/providers'))
| extend supportsHttpsTrafficOnly = properties.supportsHttpsTrafficOnly
| extend allowBlobPublicAccess = properties.allowBlobPublicAccess
| extend networkAcls = tostring(properties.networkAcls.virtualNetworkRules)
| extend privateEndpointConnections = tostring(properties.privateEndpointConnections)
| extend defaultAction = properties.networkAcls.defaultAction
| extend ipRules = tostring(properties.networkAcls.ipRules)
| project-away kind, name, managedBy, sku, plan, identity, properties, tenantId, tags, zones, extendedLocation, apiVersion, resourceGroup

The main goal here with this query and others is to filter the Blob Container with the relevant authentications, public access, and which one is exposed to the public network.

Because Azure Resource Graph Explorer uses query language, we use any parameters and filters we want. For example, to identify Blob exposure with specific rules.

resources
| where type =~ 'Microsoft.Storage/storageAccounts'
| extend allowBlobPublicAccess = parse_json(properties).allowBlobPublicAccess
| extend TLSver = parse_json(properties).minimumTlsVersion
| extend SAS = parse_json(properties).keyCreationTime
| extend Managed = parse_json(managedBy)
| extend Status = parse_json(properties)
| extend NetworkRules = parse_json(properties).networkAcls.virtualNetworkRules
| extend PrivateEndpoint = parse_json(properties).privateEndpointConnections
| extend NetworkACL = parse_json(properties).networkAcls
| where PrivateEndpoint == "[]" 
| where allowBlobPublicAccess == "true"
| where NetworkRules == "[]"
| where NetworkACL == '{"virtualNetworkRules":[],"defaultAction":"Allow","ipRules":[],"bypass":"AzureServices"}'
| project name,NetworkACL , NetworkRules,PrivateEndpoint, resourceGroup, allowBlobPublicAccess,TLSver, tags, SAS, Managed, Status

The result will be more specific because of the uses of the various filters.

For more Blob queries, visit the Resource Graph Explorer on my GitHub.

Defender for Storage

The Microsoft Defender for Storage is an Azure-native layer of security intelligence that detects unusual and potentially harmful attempts to access or exploit your storage accounts. It uses advanced threat detection capabilities and Threat Intelligence data to provide contextual security alerts. Those alerts also include steps to mitigate the detected threats and prevent future attacks.

Defender for Storage analyzes the telemetry stream the Azure Blob Storage and Azure Files services generate. When potentially malicious activities are detected, security alerts are generated. These alerts are displayed in Microsoft Defender for Cloud with the details of the suspicious activity, relevant investigation steps, remediation actions, and security recommendations.

Analyzed telemetry of Azure Blob Storage, including operation types such as Get Blob, Put Blob, Get Container ACL, List Blobs, and Get Blob Properties. Defender for Storage can be enabled at either the subscription or resource levels.

Microsoft Defender for Storage provides many benefits:

• Azure-native security
• Rich detection suite
• Response at scale
• Suspicious access patterns
• Suspicious activities
• Upload of malicious content

ℹ️TIP: The network ACL hierarchy is one of the biggest problems for cloud storage and Azure storStorageluding Blob Container. If you have Blob Container with Public Access, disable mode isn’t guaranteed that a sub-container is in the same state. It can cause by many reasons, but it is a situation in many environments. 

What can you do in this situation? Run the Azure Resource Graph Explorer to know which Container is exposed or use the Microsoft Defender for Storage. The Microsoft Defender for Cloud provides the resources and recommendations, including objects exposed to the Public Network. The recommendation can be by the Subscription or resource level, including ACL exposure. 

Microsoft Sentinel

Regarding Azure or multi-cloud scenarios, my favorite tool is the Microsoft Sentinel!

With security issues on Azure Storage, Blob Container, or any other storage (AWS, Google, BOX, etc.). The Microsoft Sentinel provides many benefits because of its excellent visibility. Once you enable logging for cloud storage, specifically for Azure Storage and Blob Container, you can run granular queries.

You can get the current state with inventory, but more important is to know who is accessed as anonymous to Blob Container. The following query is short and valuable.

StorageBlobLogs
| where TimeGenerated > ago(60d)
| where ServiceType == "blob"
    and Type == "StorageBlobLogs"
    and AuthenticationType == "Anonymous"
    and StatusCode == "200"
| project TimeGenerated, AccountName, Uri, AuthenticationType, StatusCode, StatusText

ℹ️ TIP: You can add more conditions to the query for more specific information. For example, you can remove the StatusCode == “200” to know if someone is attempting or scanning your Blob, or add the parameter with and Uri contains “token” to know if you have exposed token that is available or already accessed anonymously. 

ℹ️ Best Practice: To provide better visibility and traceability to identify the principal accessing the Storage, you should restrict and completely block SAS and Shared Key Authorization. Instead, leverage OAuth as much as possible. 

The following query provides a quick way to know which access is done by the best practice mentioned.

StorageBlobLogs 
| where AuthenticationType == 'OAuth' 
and RequesterUpn contains '@' 
and not(OperationName has_any('GetBlobServiceProperties', 'GetUserDelegationKey', 'CreatePathDir', 'ListBlobs')) 
| project TimeGenerated, Protocol, OperationName, AuthenticationType, Uri, RequesterUpn, CallerIpAddress, Category, TlsVersion

Enable the StorageBlobLogs (Azure Storage Account connector) With Microsoft Sentinel.

To log requests to your Azure Storage account, in order to evaluate anonymous requests, you can use Azure Storage logging. Azure Storage logs capture details about requests made against the storage account, including how a request was authorized. You can analyze the logs to determine which containers are receiving anonymous requests. Azure Storage logging supports using log queries to analyze log data.

Now that you know who is accessed anonymously to your Blob Container, you can also operate and close the public access.

Azure Policy

Azure Policy is a great way to achieve many goals on Azure resources, and such for Azure Storage when needs to enable logging or, when needed, disabling public access. The Azure Policy built-in definitions for Azure Storage provide many policies, specifically for Microsoft Storage.

TIP: Azure Policy comes with many policies but remember that you can develop any policy you need.

Configure diagnostic settings for storage accounts to the Log Analytics workspace, which deploys the diagnostic settings for storage accounts to stream resource logs to a Log Analytics workspace when any storage account missing this diagnostic setting is created or updated.

The following Policy is the recommended way to forward logs to Microsoft Sentinel.

Storage account public access should be disallowed – Anonymous public read access to containers and blobs in Azure Storage is a convenient way to share data but might present security risks. To prevent data breaches caused by undesired anonymous access, Microsoft recommends preventing public access to a storage account unless your scenario requires it.

ℹ️ TIP: Start with Audit mode to monitor existing resources but move to Deny mode as soon as possible.

PowerShell for Storage Defenders

PowerShell provides a significant way to verify if you have existing public access and verify if someone can change the existing permissions.

Verify that public access to a blob is not permitted

To verify that public access to a specific blob is disallowed, you can attempt to download the Blob via its URL. If the download succeeds, then the Blob is still publicly available. Suppose the Blob is not publicly accessible because public access has been disallowed for the storage account. In that case, you will see an error message indicating that public access is not permitted on this storage account.

The following example shows how to use PowerShell to attempt to download a blob via its URL. Remember to replace the placeholder values in brackets with your values:

$url = "<absolute-url-to-blob>"
$downloadTo = "<file-path-for-download>"
Invoke-WebRequest -Uri $url -OutFile $downloadTo -ErrorAction Stop

Verify that modifying the Container’s Public Access setting is not permitted

You can attempt to modify the setting to verify that a container’s public access setting cannot be modified after public access is disallowed for the storage account. Changing the Container’s public access setting will fail if public access is disallowed for the storage account.

The following example shows how to use PowerShell to attempt to change a container’s public access setting. Remember to replace the placeholder values in brackets with your values:

$rgName = "<resource-group>"
$accountName = "<storage-account>"
$containerName = "<container-name>"

$storageAccount = Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountName
$ctx = $storageAccount.Context

Set-AzStorageContainerAcl -Context $ctx -Container $containerName -Permission Blob

Verify Container with Public Access enabled is not permitted

If public access is disallowed for the storage account, you cannot create a new container with public access enabled. To verify, you can attempt to create a container with public access enabled.

The following example shows how to use PowerShell to attempt to create a container with public access enabled. Remember to replace the placeholder values in brackets with your values:

$rgName = "<resource-group>"
$accountName = "<storage-account>"
$containerName = "<container-name>"

$storageAccount = Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountName
$ctx = $storageAccount.Context

New-AzStorageContainer -Name $containerName -Permission Blob -Context $ctx

Outcome

Any client can read data in a Blob Container configured for public access. Avoid this unless expressly needed; don’t select Allow public access when creating a blob container. Such incorrect configuration could allow malicious actors to access the container blobs anonymously without requiring a shared access signature. Search for security issues in your environment and apply the Policy to prevent unauthorized access.

References

How Azure Security Center helps analyze attacks using Investigation and Log Search

Monitoring Azure Blob Storage | Microsoft Docs

Prevent anonymous public read access to containers and blobs

Hardening your Azure Storage Account by using Service Endpoints – Karim Vaes (wordpress.com)

Security recommendations for Blob storage – Azure Storage | Microsoft Docs

Microsoft-Sentinel-4-SecOps/Hunting/Azure-Blob

Built-in policy definitions for Azure Storage