<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Azure Storage Accounts - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/azure-storage-accounts/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Tue, 09 Jan 2024 16:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/azure-storage-accounts/feed.xml" rel="self" type="application/rss+xml"/><item><title>Unusual Azure Storage Account Key Access by Privileged User</title><link>https://feed.craftedsignal.io/briefs/2024-01-azure-storage-key-access/</link><pubDate>Tue, 09 Jan 2024 16:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-azure-storage-key-access/</guid><description>Detects unusual access to Azure Storage Account keys by users with Owner, Contributor, Storage Account Contributor, or User Access Administrator roles, potentially indicating compromised identities as seen in STORM-0501 ransomware campaigns.</description><content:encoded><![CDATA[<p>This threat brief focuses on the detection of unusual access patterns to Azure Storage Account keys, specifically by users holding high-privilege roles such as Owner, Contributor, Storage Account Contributor, or User Access Administrator. The access of these keys allows for full administrative control over the storage resources. Microsoft recommends using Shared Access Signature (SAS) models instead of direct key access for improved security. This behavior was observed in STORM-0501 ransomware campaigns, where compromised identities with elevated Azure RBAC roles retrieved storage account keys to conduct unauthorized operations on the storage accounts. The detection strategy focuses on identifying when a user principal with these high-privilege roles accesses storage keys for the first time within a 7-day window, highlighting potentially malicious or anomalous behavior.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>Initial compromise of a user account with a high-privilege Azure RBAC role (Owner, Contributor, Storage Account Contributor, or User Access Administrator). This may be achieved through phishing or credential stuffing.</li>
<li>The compromised account logs into the Azure portal or uses Azure CLI/PowerShell with valid credentials.</li>
<li>Attacker enumerates available Azure Storage Accounts within the subscription.</li>
<li>Using the compromised account, the attacker executes the <code>MICROSOFT.STORAGE/STORAGEACCOUNTS/LISTKEYS/ACTION</code> operation to retrieve the storage account keys.</li>
<li>The attacker uses the retrieved storage account keys to perform unauthorized actions on the Storage Account, such as reading, modifying, or deleting data.</li>
<li>Data exfiltration occurs using the compromised storage account keys, potentially involving tools like AzCopy or custom scripts.</li>
<li>The attacker may attempt to move laterally to other storage accounts or Azure resources using the compromised keys.</li>
<li>Ransomware deployment within the storage account, encrypting data and demanding payment for its recovery, as observed in STORM-0501 campaigns.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>A successful attack can lead to unauthorized data access, modification, or deletion within Azure Storage Accounts. The impact includes potential data breaches, financial losses, and reputational damage. As observed with STORM-0501, compromised storage account keys can facilitate ransomware deployment, rendering critical data inaccessible until a ransom is paid. Organizations in all sectors that utilize Azure Storage Accounts are potentially vulnerable. The compromise can allow attackers full control over the storage account leading to complete data loss.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Implement the Sigma rule &quot;Azure Storage Account Keys Accessed by Privileged User - New Access&quot; to detect first-time key access within 7 days by privileged users based on <code>azure.activitylogs.operation_name: &quot;MICROSOFT.STORAGE/STORAGEACCOUNTS/LISTKEYS/ACTION&quot;</code> and <code>event.outcome: &quot;success&quot;</code>.</li>
<li>Enable Azure Activity Logs and ensure they are being ingested into your SIEM to provide the data source necessary for the provided Sigma rules.</li>
<li>Rotate storage account keys immediately upon detection of unauthorized access and audit recent activities on the affected storage accounts.</li>
<li>Enforce the use of Azure AD authentication or SAS tokens instead of storage account keys to reduce future risks, as recommended by Microsoft.</li>
<li>Review and restrict the assignment of high-privilege roles like Owner and Contributor, following the principle of least privilege.</li>
<li>Configure Azure Policy to restrict the <code>listKeys</code> operation to specific roles or require additional approval workflows.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">threat</category><category>azure</category><category>storage account</category><category>credential access</category><category>ransomware</category></item><item><title>Multiple Azure Storage Account Deletions by User</title><link>https://feed.craftedsignal.io/briefs/2024-01-02-azure-storage-deletion/</link><pubDate>Tue, 02 Jan 2024 10:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-02-azure-storage-deletion/</guid><description>A single user or service principal deleting multiple Azure Storage Accounts within a short time period may indicate malicious activity such as data destruction, service disruption, or a ransomware attack.</description><content:encoded><![CDATA[<p>This detection identifies when a single user or service principal deletes multiple Azure Storage Accounts within a short time period. This behavior can indicate an adversary attempting to cause widespread service disruption, destroy evidence, or execute a destructive attack such as ransomware. Mass deletion of storage accounts can have severe business impact and is rarely performed by legitimate administrators except during controlled decommissioning activities. The original Elastic detection rule was published on 2025/10/08 and updated on 2026/04/10. This threat is important for defenders because Azure Storage Accounts are critical infrastructure components that store application data, backups, and business-critical information.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains unauthorized access to an Azure account or service principal.</li>
<li>The attacker enumerates available Azure Storage Accounts within the subscription.</li>
<li>The attacker uses the Azure portal, CLI, or API to initiate deletion of multiple storage accounts.</li>
<li>Azure Activity Logs record the &quot;MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE&quot; operations.</li>
<li>The attacker attempts to disable or delete backups to hinder recovery efforts.</li>
<li>If successful, the deletion of storage accounts results in data loss and service disruption.</li>
<li>The attacker may attempt to exfiltrate additional data before final deletion.</li>
<li>The attack aims to cause maximum impact by deleting as many storage accounts as possible in a short timeframe.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Mass deletion of storage accounts can result in significant data loss, service disruption, and financial damage. The number of affected storage accounts can vary, but the impact is generally high due to the critical nature of stored data. This attack could impact any organization using Azure Storage Accounts, including those in the technology, finance, and healthcare sectors. If successful, organizations may experience data breaches, compliance violations, and reputational damage.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule &quot;Azure Storage Account Deletions by User&quot; to your SIEM and tune for your environment.</li>
<li>Review Azure Activity Logs for the &quot;MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE&quot; operation to investigate potential mass deletion attempts.</li>
<li>Implement Azure Resource Locks on all critical storage accounts to prevent accidental or malicious deletion.</li>
<li>Configure Azure Policy to require approval workflows for storage account deletions using Azure Blueprints or custom governance solutions.</li>
<li>Enable Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>cloud</category><category>azure</category><category>storage</category><category>impact</category></item></channel></rss>