Defender for Storage is the Azure-native layer of security intelligence that detects potentially harmful attempts to access or malicious activity. With the use of Microsoft Threat Intelligence and security AI, contextual security alerts and recommendations are available. Defender for Storage is part of the Defender for Cloud stack. Cloud storage is a common target for attackers focussed on sensitive information for further exfiltration.
| Blog information: Blog published: January 31, 2023 Blog latest updated: January 31, 2023 |
What is Defender for Storage?
Defender for Storage is the Azure-native layer for protecting storage accounts and is part of Defender for Cloud. Currently, the following cloud storage types are supported:
- Blob Storage
- Azure Files
- Azure Data Lake Storage Gen 2
Defender for Storage is important for detecting/identifying attempts to exploit storage accounts.
Image source: Microsoft
When the Defender for Storage plan is enabled all detection logic is automated and part of the plan itself. Common question; do we need additional log configuration? The answer is no, there is no requirement for collecting more events for the core protection futures part of Defender for Storage. It is recommended to enable more in-depth diagnostic auditing and hunt for more use cases based on all ingested logs. (more details later in this blog)
What are known cloud storage threats?
Currently, there are a couple of known cloud storage threats. The most common data breaches are based on anonymous access to misconfigured resources/ compromised credentials or breaches involved using social engineering.
Common attacks:
- Malware upload: Upload malware to a storage account and use it as an organization’s entry point and distribution point.
- Data Exfiltration: Data Exfiltration of sensitive files outside the cloud storage accounts
- Cloud ransomware: Encrypt and delete data part of the storage account
Cloud storage accounts are used quite often and can be used for any type of data. In some cases, authentication data (keys, tokens, credentials) or other sensitive information is part of the public cloud storage account, which can be abused for other attacks/ lateral movement inside the organization. Common example; PowerShell script with managed identities shared on public blob stores.
When malware/ phishing content is available on machines the Defender for Endpoint product detects malicious files. Within cloud storage accounts it is different with more impact: For example;
Replacing file: The attacker discovers a cloud storage account that is used for deploying scripts which is part of the deployment mechanism (GPO or other tools). When there is malicious access to a cloud storage account; it is easy to replace files with malicious files.
Common threats:
- Reconnaissance: Scanning accounts/containers/ blobs for publicly available data and possible secrets for the movement against more cloud storage accounts
- Using search engines: With the use of search engines (Google Dorking/Shodan/ Public information) public blob URLs/ containers can be found.
- Credential/ Access token theft: Phishing, Credential Theft, HTTP Man in The Middle
- Lateral movement from cloud storage assets
Recommended is to view the MITRE threat mapping for the full attack mapping. (source Microsoft)
More information: Threat matrix for storage services | Microsoft.com
Detections in Defender for Storage
Defender for Storage contains a couple of detections based on storage telemetry logs. All detections are improved with behavioral models and Microsoft Threat Intelligence. Defender for Storage maps detections based on MITRE ATT&CK.
Important to know: Defender for Storage doesn’t access the Storage account data and has no impact on its performance. It is all based on collected telemetry/ operation types.
The following alerts are available
More information: Reference list of alerts | Microsoft Learn
| Alert type | MITRE tactics | Severity |
| Access from a suspicious application | Initial Access | High/Medium |
| Access from a suspicious IP address | Pre Attack | High/Medium/Low |
| Phishing content hosted on a storage account | Collection | High |
| Storage account identified as source for the distribution of malware | Execution | Medium |
| Storage account with potentially sensitive data has been detected with a publicly exposed container | Collection | Medium |
| Authenticated access from a Tor exit node | Initial Access / Pre Attack | High/Medium |
| Access from an unusual location to a storage account | Initial Access | High/Medium/Low |
| Unusual unauthenticated access to a storage container | Initial Access | High/Low |
| Potential malware uploaded to a storage account | Lateral Movement | High |
| Publicly accessible storage containers successfully discovered | Collection | High/Medium |
| Publicly accessible storage containers unsuccessfully scanned | Collection | High/Low |
| Unusual access inspection in a storage account | Discovery | High/Medium |
| Unusual amount of data extracted from a storage account | Exfiltration | High/Low |
| Unusual application accessed a storage account | Execution | High/Medium |
| Unusual data exploration in a storage account | Execution | High/Medium |
| Unusual deletion in a storage account | Exfiltration | High/Medium |
Important: Defender for Storage uses the hash reputation method supported by Microsoft TI to determine the status. There is no direct scanning of the uploaded files. Defender for Storage compares the hashes in the storage account with known hashes by threat intelligence.
How to enable Defender for Storage?
Enablement is possible with the use of Defender for Cloud. In Defender for Cloud, it is required to enable the plan Defender for Storage. On the subscription level itself, it is possible to enable only the per-storage account pricing.
There are currently two pricing models:
- Per-storage account pricing (Subscription level)
- Per-transaction pricing
For per-transaction details: Set-up Microsoft Defender for Storage Per-transaction pricing
Pricing
Important is the monitoring of cost. Transactions can be increasing the cost. By default, the start price is $10 for each storage account/month. Storage accounts that exceed 73 million monthly transactions will be charged $0.1492 for every 1 million transactions that exceed the threshold.
Use the Microsoft Defender for Storage Price Estimation workbook for more price calculations.
Enable using Defender for Cloud
Enablement is with the use of Defender for Cloud easy for the complete subscription.
- Sign in to the Azure portal and navigate to Microsoft Defender for Cloud and open the Environment settings. Open one of the available subscriptions:
- Enable Defender for Storage with the per-storage account pricing for the subscription level
When the plan is enabled for the complete subscription; it will protect all available storage accounts.
Use the per-transaction pricing for protecting a small set of storage accounts. It is recommended to protect all new storage accounts, new storage accounts can be created and used for further deployment of malicious files. Only for the per-transaction plan, it is possible to exclude storage accounts via the AzDefenderPlanAutoEnable tag.
View estimated transactions
When the plan is enabled Defender for Storage gives the estimated analyzed transactions/day for the last two weeks of usage. Open the storage account in Azure and open the details in the Defender for Storage section for the transaction statistics.
Structure in storage blobs
There is a known structure in the blob service concept. Each storage blob contains the following components/ structure.
- Account
- Container
- Blob
It starts all with a storage account. For example, the storage account contains the name: maliciousblobstore. The account name is always unique.
A container provides a grouping of a set of blobs. All blobs must be in a container. See this as a folder; for example files/ Movies/ Pictures.
A blob is a file of any type and size. For example Eicarr.zip / Image1.png / movie.mp4
http://<storage account>.blob.core.windows.net/<container>/<blob>
https://maliciousblobstore.blob.core.windows.net/files/eicar_com.zipPublic storage accounts can be easily discovered using different OSINT tools or using Google and other tools. All storage accounts are created with the default URL structure; the ending is always blob.core.windows.net.
Permissions
Storage accounts contain a different set of permissions. Every container is associated with a public access level. The permissions can be configured based on the container:
- No public read access (private)
- Public read access for blobs only (available via complete full URL)
- Public read access for containers and blobs
No public read access is the default for each container and can be accessed only with an authorized request.
Blobs within the container can be read by anonymous request, but container data is not available anonymously. There is no enumeration possible with the blobs inside the container.
Container and blob data can be read by anonymous request in the container. and enumerate inside the container.
When public; the file is directly available via the URL structure:
Files can be “protected” with the use of a Shared Access Signature (SAS token) that allows access to the objects. The URIs are quite commonly visible on the public web. Within seconds public SAS tokens are visible on GitHub. Microsoft explained the SAS structure. More information: SAS parameters | Microsoft Learn
Example of SP:
https://maliciousblobstore.blob.core.windows.net/files/eicar_com.zip?sp=r&st=2023-01-30T20:22:08Z&se=2023-01-31T04:22:08Z&spr=https&sv=2021-06-08&sr=b&sig=cfZkxWdsTLN8uJsJk%2Fl4e2uNfrZw%2BFbvpTOR0FNiofQ%3DWith the use of the account/container information, it is possible to view all related content.
https://maliciousblobstore.blob.core.windows.net/files?resttype=container&comp=list
Collect additional events
For active hunting, it is recommended to add additional logging for each diagnostic account. Defender for Storage is by default protecting with a set of default activities, more hunting is possible when diagnostic settings are enabled. Diagnostic settings are disabled by default.
Diagnostic settings can be easily applied in the Azure Portal for each storage account. When configuring it is possible to streal all events directly to Log Analytics, event hubs, or other solutions.
Make sure to include the StorageRead/ StorageWrite/ StorageDelete and Transaction metrics for all available services.
Enable logging for all of the services:
And configure the destination source: (Send to Log Analytics when using Sentinel)
Simulation of malicious attempts
Discovery/ reconnaissance of the Azure Blobs is the first step. With the name convention, it is easy to search for public storage accounts. Example; *.blob.core.windows.net. With the use of Google, there are +- 2.980.000 results.
site:*.blob.core.windows.netMore properties are allowed, including an intext search for CONFIDENTIAL
site:"blob.core.windows.net" and intext:"CONFIDENTIAL"
It is quite easy to check against public storage accounts. There are quite some tools available (AZ-Blob-Attacker/Microburst/Basic Blob Finder/ GrayHat Warfare and many more)
GrayhatWarfare is a simple website/ searchable database for searching against public accounts. The result shows more details (Account, Files, Container).
When clicking on the count all files are directly visible including limited metadata:
Let’s assume you have a leaked account name and key. With the use of PowerShell, it is easy to connect without any authentication from the user/admin itself. Only the account key/account name is needed.
az storage container list --account-key lYhFwFIio7FZi9KQec4C7a9L2JfleHSVTPEzQyxlyKEXEFn2BN9KMhk94oC3Ipb39KQ== --account-name maliciousblobstore
By running the command via PowerShell the container name is visible:
Now it is possible to list the blob names with the use of the known account name, key, and container:
az storage blob list --account-key lYhFwFIio7FZi9KQec4C7a9L2JfleHSVTP406gO5IEzQyxlyKEXEFn2BN9KMhk94oC3Idb6J23T2+AStpb39KQ== --account-name maliciousblobstore -c files
When the account key/account name is available with the correct permissions. It is possible to upload/ delete/ download files.
Tor node
Access from a Tor node is one of the available alerts in Defender for Storage. Use the SAS URL and access the SAS URL directly from the browser. Within a couple of hours, the following security alert is visible in the Defender for Cloud portal: “Access from a Tor exit node to a storage blob container”
Potential malware uploaded
When uploading malicious files – Defender for Storage checks the hash against available/ TI data. Defender for Storage uses the hash reputation method supported by Microsoft TI to determine the status. There is no direct scanning of the uploaded files. Defender for Storage compares the hashes in the storage account with known hashes by threat intelligence.
Connect Defender for Storage alerts with Microsoft Sentinel
For sending alerts (SecurityAlert) to Microsoft Sentinel, use the Defender for Cloud connector in Sentinel for all available subscriptions.
Alert synchronization
When connecting Defender for Cloud to Microsoft Sentinel there is the option for enabling alert synchronization. When an alert is closed in Defender for Cloud; the alert will be closed in Microsoft Sentinel as well. Important: The incident status will not be changed in Sentinel; only that of the alert itself.
Bi-directional alert synchronization can be used to automatically sync the status bi-directional. When the incident is closed in Microsoft Sentinel; the alert will be closed in Microsoft Defender for Cloud.
How to connect
Open the Defender for Cloud connector page in Sentinel and enable the toggle for each subscription. Important: Be careful with the button; Enable Microsoft defender for all subscriptions and Enable All
Enable the Status to Connected and configure Bi-directional sync for automatically sync alerts. Don’t forget to enable the incident analytics rule “Create incidents based on Microsoft Defender for Cloud” in Microsoft Sentinel.
Conclusion
Defender for Storage gives some more extra insights. Important; Defender for Storage is not applying any baseline/ protection to the Defender for Storage accounts, make sure the Storage Account is protected and limited. It is recommended to turn on soft delete for blobs/ containers to recover a container it has been deleted, HTTPS traffic, and some more basics. There are more protections available. Read all available security recommendations for Blob storage
In one of the upcoming blogs, workflow automation will be explained for building automated responses from Sentinel/ or other workflows.
Sources
Must read from inversecos.com: How to Detect and Compromise Azure Blobs and Storage Accounts
Interesting research from Cyberark: Hunting Azure Blobs Exposes Millions of Sensitive Files
Microsoft Threat Matrix for Storage service: Threat matrix
Microsoft: Security recommendations for Blob storage
Microsoft: Security baseline
