There’s been a recent surge in cloud ransomware attacks. Examples of such attacks were observed by Sophos X-Ops, which detected the ransomware group BlackCat/ALPHV using a new Sphinx encryptor variant to encrypt Azure storage accounts by employing stolen Azure Storage account keys. The BlackCat/ALPHV ransomware group is the same entity that claimed responsibility for infiltrating MGM’s infrastructure and encrypting more than 100 ESXi hypervisors.

In this blog post, we’ll provide a brief overview of concepts and attacker incentives for ransomware attacks, focusing particularly on ransomware in the cloud environment. We’ll also discuss Azure Storage Accounts, point out forensic artifacts in Azure that can help investigate such attacks, and offer methods for attack detection. Finally, we’ll provide insights on mitigating and preventing ransomware attacks on Azure cloud environments.

On-premises Ransomware vs Cloud Ransomware

Ransomware activities can be perpetrated by individuals or attack groups to extort money from victims. Ransomware usually operates by encrypting victims' information such as files and disks, effectively blocking them from their data. To regain access to the data, a victim needs a decryption key from the attackers. Exploiting the locked access, the attackers ask for ransom from the victim.

It is no surprise that attackers have adapted to crafting cloud-based ransomware, considering the increasing migration of computing resources to cloud environments. With the cloud facilitating many assets like VMs (Virtual Machines), Storage, databases and more, it becomes an attractive goal for ransomware.

Cloud ransomware differs from on-premises ransomware in terms of its impact, recovery, and protection complexities. A cloud ransomware attack can be highly damaging because the resources are frequently used as backup or recovery storage for on-site networks and data. Additionally, cloud ransomware is susceptible to exploitation through misconfigurations, potentially granting remote access and enabling enumeration.

Storage Accounts are an effective way for attackers to get ransomware on cloud environments and abuse access to data. Before we discuss Account Storage abuse for ransomware, we first need to understand Azure Storage Accounts.

Understanding Azure Storage Accounts

In the Azure ecosystem, Storage Accounts act as a central hub for managing and handling Azure Storage. These Storage Accounts are used to manage and access containers, blobs, files, tables, and queues. The data stored within the components of a storage account can include critical information like customer data and code, making the management of these storage accounts highly sensitive and significant.

There are several ways to access data resources within an Azure Storage Account:

Access Keys: ‍

The access keys are comprised from two keys that are generated at the creation of the storage account: The primary key and the secondary key.

The primary key is for primary usage for accessing data storage resources, and the secondary key is a recovery/failover key (for example, to be used during primary key rotation or a regeneration of the primary key). These keys can be shared and used by anyone who has them. The Access Keys provide access to all the data (data layer) in the storage account, making them a coveted target for attackers.

For more on access keys: Microsoft’s documentation

Shared Access Signature (SAS):‍

Shared access signature (SAS) is a signed URL that shares a commonality with Access Keys in that they both provide access to individuals possessing the SAS. However, SAS introduces an extra layer of security, as it provides more detailed and specific access controls (such as permission level, time expiration and scope), determined by the type of SAS in use.

Account SAS – Enables configuration and access at the service level with resources such as Files, Tables, and Queues.

Service SAS – Operates at an object level, allowing access to specific entities like individual Files or Blobs.

User Delegation SAS – Is a SAS token secured with Azure AD credentials (with a user delegation key) and by the permissions specified for the SAS.

For more on SAS: Microsoft's documentation

Role-Based Access Control (RBAC):

Azure RBAC is Azure’s access management system, enabling assignments and managing specific roles and permissions for users and services within Azure resources. It provides granular control to ensure secure and compliant access.

RBAC assignments can be applied to both the Azure Storage account's Management and Data layers. For instance, an RBAC role assignment in Azure Storage can grant access to all blobs within a storage account or to specific individual blobs.

For more information: Microsoft’s documentation

What Can Ransomware on an Azure Storage Account Look Like?

As mentioned above, an Azure Storage account has a lot of power in data and data management. Using the Storage Account allows a threat actor to manipulate data or encrypt it for ransomware usages.

The attackers can gain access to a Storage Account in a few ways such as using an account with sufficient RBAC roles (such as Storage Blob Data Contributor, Storage Blob Data Owner, Storage Table Data Contributor, and others, including custom roles) that have data access and key listing permissions.

Another method for adversaries to get access to a Storage Account, is by obtaining the access keys that allow access to storage resources. An abuser can list the storage account keys if they have a role with the permissions of Microsoft.Storage/storageAccounts/listKeys/action.

With these permissions, the attacker can easily list the keys for the storage account and use them to access the data.

Recently, Sophos posted a thread explaining a recent investigation conducted by Sophos X-Ops, where the threat actor pivoted from on-premises environment to Azure portal and then to Azure Storage Accounts using Azure access key.

After obtaining the necessary permissions to access the storage account, threat actors have multiple ways to encrypt files, including:

1. Mass downloading of storage objects, locally encrypting them, and subsequently re-uploading them to the storage account.
2. Utilizing Azure Key Vault to generate a new encryption key, which they then employ to encrypt blob storage or file shares. Subsequently, they may delete the encryption key to hinder access to the encrypted objects. It's worth noting that Azure offers the option to download a local copy of the generated key following its creation.

Detection of Cloud Ransomware Attacks

Ransomware incidents usually stem from a sequence of shortcomings in cloud threat detection. Responding promptly to a ransomware attack and preventing threat actors from accessing storage account assets requires the proactive identification of attack techniques employed along the attack kill-chain.

One common tactic employed by threat actors to execute a successful ransomware attack is the manipulation or disabling of critical tools, as indicated by the MITRE ATT&CK framework under Technique T1562. In the context of Azure storage accounts, this may manifest as:

1. Permitting public access to storage containers
   (MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/WRITE)

2. Enabling access via storage account keys
   (MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE)

3. Disabling Blob Versioning
   (MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/WRITE)

4. Deleting blob versions (DeleteBlob)

5. Additionally, detecting deviations in user behavior, such as instances where a user lists storage account keys for the first time, or user that list keys of all storage account in the subscription, can provide valuable insights into potential security breaches.

All actions are logged and available under the subscription activity log and can be routed to Azure sentinel or external monitoring solution through Diagnostic settings.

Another log source that is crucial to collect and proactively monitor to determine an attack, is the blob resource logs – StorageRead, StorageWrite, StorageDelete. Monitor for high volume of StorageRead actions followed by StorageWrite, or sequence of StorageDelete actions followed by StorageWrite of the same file; these patterns could serve as indicators of ongoing encryption activities.

Proactive threat detection and monitoring along the attack kill-chain are pivotal for safeguarding Azure Storage Accounts against ransomware threats.

Prevention of Ransomware Attacks in Azure

• Limit Network Access: control which networks can connect to your storage account, to minimize the risk of unauthorized access. Consider adding the storage account to a dedicated Virtual Network or setting certain Firewall Rules to allow access for defined IP addresses.
• Use Managed Identities: Instead of using access keys, leverage Azure Managed Identities to grant services or applications permissions to access your storage accounts securely. Managed identities are a more secure way to authenticate without exposing keys.
• Use Azure RBAC: Implement Azure Role-Based Access Control (RBAC) to control and limit the permissions granted to users and services. Assign only the necessary permissions to individuals or applications.
• Rotate Keys Regularly: If you must use access keys, rotate them on a regular basis, and ensure that the old keys are no longer in use.

• Use Azure Data Protection: Backup and recover the data stored in Azure storage account. You can use the Azure Blob Backup and Blob Versioning to maintain access to objects that were encrypted or deleted by the threat actor.

Summary

Proactive measures such as log collection, threat hunting, and having a robust incident response plan are essential for defending against ransomware attacks on Azure storage accounts. These actions help enterprises detect threats early, respond effectively, and minimize the impact of attacks on their cloud environments.

‍