<?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>Storage Account - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/storage-account/</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/tags/storage-account/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>Azure Storage Account Key Regeneration</title><link>https://feed.craftedsignal.io/briefs/2024-01-04-azure-storage-key-regen/</link><pubDate>Thu, 04 Jan 2024 15:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-04-azure-storage-key-regen/</guid><description>Detection of Azure Storage Account key regeneration events, which can signify potential credential access or persistence attempts by adversaries aiming to gain unauthorized access or disrupt services.</description><content:encoded><![CDATA[<p>This threat brief focuses on the detection of Azure Storage Account key regeneration events. Regenerating these keys can impact dependent applications and Azure services. An adversary might regenerate a storage account key to gain unauthorized access to storage resources, potentially leading to data exfiltration or service disruption. The detection rule monitors Azure activity logs for successful key regeneration operations, providing an opportunity to identify and respond to potential credential misuse. Key rotation is a normal part of operations, however, unscheduled key rotation, or key rotation from unfamiliar locations or users should be investigated.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An adversary gains initial access to an Azure account, potentially through compromised credentials or exploiting a vulnerability.</li>
<li>The adversary enumerates existing Azure storage accounts within the compromised subscription to identify potential targets.</li>
<li>The adversary authenticates to the Azure Resource Manager API using the compromised credentials or an established session.</li>
<li>The adversary executes a command to regenerate a storage account access key using the Azure CLI or PowerShell.</li>
<li>Azure Activity Logs record the event with <code>operation_name</code> as <code>MICROSOFT.STORAGE/STORAGEACCOUNTS/REGENERATEKEY/ACTION</code> and <code>event.outcome</code> as <code>Success</code>.</li>
<li>If successful, the adversary can then use the newly generated key to access the storage account and its contents.</li>
<li>The adversary attempts to access or download sensitive data stored within the Azure Storage Account, such as backups or proprietary files.</li>
<li>The adversary establishes persistence by using the new keys in automated scripts to access data in the storage account.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful regeneration of Azure Storage Account keys can lead to unauthorized access to sensitive data, including customer information, proprietary data, and backups. This can result in data breaches, financial loss, and reputational damage. The scope of the impact depends on the permissions associated with the compromised account and the sensitivity of the data stored in the affected storage account.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule &quot;Azure Storage Account Key Regenerated&quot; to your SIEM to detect unauthorized key regenerations in Azure Activity Logs.</li>
<li>Investigate any detected instances of storage account key regeneration, especially those performed by unfamiliar users or from unusual locations, by examining the <code>event.outcome</code> and associated user activity logs.</li>
<li>Implement multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise, mitigating initial access (TA0001).</li>
<li>Review and harden Azure Storage Account access policies and permissions to adhere to the principle of least privilege, limiting the impact of potential credential compromise (T1552).</li>
<li>Establish a process for regular, documented key rotation and create exceptions in the detection rule for these known events.</li>
</ul>
]]></content:encoded><category domain="severity">low</category><category domain="type">advisory</category><category>azure</category><category>credential-access</category><category>storage-account</category></item></channel></rss>