Azure Storage Account - CraftedSignal Threat Feed

Azure Storage Account Deletion Detection

hello@craftedsignal.io — Tue, 09 Jan 2024 18:21:00 +0000

This detection identifies when an Azure Storage Account is deleted, a high-impact operation with significant consequences. Adversaries may delete storage accounts to disrupt operations, destroy evidence of their activities, or cause denial of service, potentially as part of ransomware or destructive attacks. Monitoring storage account deletions is crucial for detecting potential impact on business operations and data availability within Azure environments. The provided rule focuses on identifying storage account deletions performed by unusual users, leveraging Azure Activity Logs to pinpoint potentially malicious activity. The rule relies on the "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" operation name and user identity information.

Attack Chain

An attacker gains unauthorized access to an Azure account through compromised credentials or exploiting a vulnerability.
The attacker elevates their privileges within the Azure environment to gain the necessary permissions to manage storage accounts (requires Contributor or Owner role).
The attacker identifies a storage account containing sensitive data or critical application components.
The attacker executes the "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" operation to delete the targeted storage account using an unusual user account.
Azure Activity Logs record the deletion event, including details about the user, timestamp, and resource involved.
The attacker attempts to cover their tracks by deleting or modifying other logs and audit trails.
The deletion of the storage account causes data loss, application downtime, and disruption of business operations.

Impact

Successful deletion of Azure Storage Accounts leads to permanent data loss, impacting business operations and application availability. The number of affected victims depends on the storage account's contents and the criticality of the applications relying on it. This activity can result in significant financial losses, reputational damage, and regulatory compliance issues. The deletion of storage accounts may be part of a larger ransomware or destructive attack targeting cloud infrastructure.

Recommendation

Deploy the Sigma rule "Azure Storage Account Deletion by Unusual User" to your SIEM, using logs-azure.activitylogs-* index, and tune the new_terms field for your environment.
Review Azure RBAC permissions and restrict storage account deletion capabilities to authorized users only, based on the guidance in the rule documentation.
Configure Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted, as described in the rule documentation.
Implement Azure Resource Locks to prevent accidental or malicious deletion of critical storage accounts, per the rule documentation.

Azure Storage Account Key Regeneration

hello@craftedsignal.io — Thu, 04 Jan 2024 15:00:00 +0000

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.

Attack Chain

An adversary gains initial access to an Azure account, potentially through compromised credentials or exploiting a vulnerability.
The adversary enumerates existing Azure storage accounts within the compromised subscription to identify potential targets.
The adversary authenticates to the Azure Resource Manager API using the compromised credentials or an established session.
The adversary executes a command to regenerate a storage account access key using the Azure CLI or PowerShell.
Azure Activity Logs record the event with operation_name as MICROSOFT.STORAGE/STORAGEACCOUNTS/REGENERATEKEY/ACTION and event.outcome as Success.
If successful, the adversary can then use the newly generated key to access the storage account and its contents.
The adversary attempts to access or download sensitive data stored within the Azure Storage Account, such as backups or proprietary files.
The adversary establishes persistence by using the new keys in automated scripts to access data in the storage account.

Impact

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.

Recommendation

Deploy the Sigma rule "Azure Storage Account Key Regenerated" to your SIEM to detect unauthorized key regenerations in Azure Activity Logs.
Investigate any detected instances of storage account key regeneration, especially those performed by unfamiliar users or from unusual locations, by examining the event.outcome and associated user activity logs.
Implement multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise, mitigating initial access (TA0001).
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).
Establish a process for regular, documented key rotation and create exceptions in the detection rule for these known events.

Azure Storage Account Blob Public Access Enabled

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This alert focuses on detecting the enabling of public access to Azure Storage Account Blobs. This configuration change allows anonymous internet access to blob containers, bypassing typical authentication requirements. The activity is detected by monitoring for the Microsoft.Storage/storageAccounts/write operation within Azure Activity Logs. Observed in cloud ransom-based campaigns, threat actors such as STORM-0501 have exploited this misconfiguration to expose data for exfiltration. Detecting this behavior is critical to prevent unauthorized data access and potential ransomware attacks, particularly when sensitive information is stored within Azure Blob storage. The rule specifically looks for modifications where the allowBlobPublicAccess property is set to true.

Attack Chain

Initial Compromise: The attacker gains initial access to an Azure account, potentially through compromised credentials or a vulnerable application.
Privilege Escalation (if needed): The attacker escalates privileges within the Azure environment to gain the necessary permissions to modify storage account settings.
Storage Account Discovery: The attacker identifies target storage accounts containing valuable data.
Modify Storage Account Configuration: The attacker executes the Microsoft.Storage/storageAccounts/write operation to modify the storage account's public access settings, specifically setting allowBlobPublicAccess to true.
Data Exfiltration: Once public access is enabled, the attacker accesses and exfiltrates the data stored in blob containers without needing authentication.
Lateral Movement (optional): The attacker leverages the compromised storage account to gain access to other resources within the Azure environment.
Ransom/Extortion (in some cases): The attacker encrypts the data in the storage account and demands a ransom for its recovery, or threatens to release the exfiltrated data publicly.

Impact

Enabling public access to Azure Storage Account Blobs can lead to significant data breaches and financial losses. Successful attacks can result in the exposure of sensitive customer data, intellectual property, or confidential business information. The STORM-0501 campaign demonstrates how this vulnerability can be exploited in cloud ransom-based campaigns. The impact can range from reputational damage and regulatory fines to significant operational disruptions. The number of affected records could be substantial depending on the size and content of the exposed blob containers.

Recommendation

Deploy the Sigma rule Azure Storage Account Public Blob Access Enabled to your SIEM to detect unauthorized modifications to storage account access settings.
Implement Azure Policy to prevent enabling public blob access on storage accounts containing sensitive data as described in the overview.
Review Azure activity logs for any instances of Microsoft.Storage/storageAccounts/write events as outlined in the attack chain to identify potential unauthorized changes.
Audit all blob containers within affected storage accounts (referenced in the overview) to identify which data may have been exposed and assess the potential impact of the exposure.
Monitor the azure.resource.name field to track which storage accounts are being targeted.