Executive Summary

• Data exfiltration: This stage of an incident lifecycle has evolved from a rare occurrence to a common tactic in ransomware attacks over the past five years.
• Azure Storage Explorer: Recent investigations by modePUSH have identified the use of Azure Storage Explorer by ransomware groups like BianLian and Rhysida for stealing sensitive data. This tool, used for managing Azure storage and objects within it, is being repurposed by threat actors for large-scale data transfers to cloud storage.
• Actionable Insights: This blog covers the forensic evidence left by Azure Storage Explorer and AzCopy, providing critical insights for incident responders. Understanding these emerging tactics is vital for enhancing incident response and safeguarding critical data from sophisticated exfiltration strategies.

Introduction

While the core principles of incident response remain relatively constant, new trends that notably reshape the landscape will always emerge. One of the most profound shifts observed is the increased prevalence of data exfiltration during ransomware incidents. In the earlier days of ransomware threat actors performing data exfiltration was more of an uncommon exception. Today, it has become a standard tactic for threat actors, providing them additional leverage during negotiations.
‍
At modePUSH, we have frequently observed threat actors utilizing tools like MEGAsync and Rclone for large-scale remote file copying and syncing, specifically for data exfiltration. By analyzing Windows operating system artifacts such as Shellbags, modePUSH investigators have traced the movements of these actors as they navigate directories and file shares in search of sensitive data. Despite exfiltrating large amounts of data, threat actors must still ensure that this dataset contains valuable and protected information.

Azure Storage Explorer

In recent engagements, modePUSH has observed the use of another tool for data exfiltration: Azure Storage Explorer.  ModePUSH's recorded usage of the Windows OS AMD64 version of Azure Storage Explorer so far has been primarily from the BianLian ransomware group but also includes the Rhysida ransomware group. This Microsoft application, also available for Windows ARM-based devices, Linux, and MAC OSX, provides a graphical interface to manage various Azure storage types and components and provides folder/file upload and download functionality.

Behind the scenes, the file transfer capabilities involving storage blobs, file shares, ADLS Gen2, and managed disks are handled by the command line Azure storage data transfer tool AzCopy. In our most prolific incident involving Azure Storage Explorer, the BianLian group used it to copy hundreds of files from the main file server for a company.

One aspect that made the use of this tool for data exfiltration particularly unique and interesting is the proactive nature of the threat actor. They didn't just use a standalone executable; instead, they installed it on the system, even upgrading the .NET version to version 8 before installing Azure Storage Explorer.

During the installation, the choice is given to either install it for the current user account or all users on the system, placing the main executable StorageExplorer.exe and the additional program files in either of these directory locations unless the default location is manually changed:

- %USERPROFILE%\ AppData\Local\Programs\Microsoft Azure Storage Explorer

- C:\Program Files\Microsoft Azure Storage Explorer

The AzCopy executable, assuming the AMD 64-bit version was installed, is located under the following subdirectory path:
- app\node_modules\@azure-tools\azcopy-win64\dist\bin\azcopy_windows_amd64.exe
‍
When a threat actor leverages Azure Storage Explorer for data exfiltration, they are most likely to use it as we have observed in multiple instances uploading files to a blob container. This approach is favored because Azure Blob Storage is optimized for handling large volumes of unstructured data while offering high scalability. In addition, it is very unlikely that an outbound connection to a Microsoft IP address hosting an Azure storage account would be blocked by network security controls.

Azure Storage Background

In Azure Blob Storage, all your data (referred to as objects) is stored as "blobs" within containers. If you're more familiar with those public cloud providers, these containers are similar to the buckets used in Amazon S3 and Google Cloud Storage.

To start, let’s break down the structure of Azure Blob Storage, which consists of three key resources:

1. Storage Account: The overarching entity that provides a namespace for your data.
2. Container: A logical grouping within the storage account that holds your blobs.
3. Blob: The actual data object stored within a container.

AzCopy Logging and Analysis

Azure Storage Explorer and the AzCopy instances it launches use the INFO level logging setting by default. Each tool has its section in the Azure Storage Explorer settings page where a user can configured the logging level. In both instances where we observed this used for data exfiltration, the default logging level of INFO was left unchanged.

Azure Storage Explorer simplifies obtaining the AzCopy command for file transfers by providing a link to copy the command directly to your clipboard.

For any failed file transfer activities, Azure Storage Explorer also provides a “Retry…” link to reattempt the same AzCopy command, or more interestingly, for incident response investigations, a “Go to AzCopy Log File” option.

Clicking “Go to AzCopy Log File” opens the corresponding .azcopy folder in Windows Explorer.

You’ll notice two types of logs created in this directory for each new AzCopy job launched by Azure Storage Explorer. For incident responders and forensic investigators, the regular log file—without the “-scanning” suffix—contains the information most useful for an investigation. This file includes entries such as the AzCopy command generated for the associated job and details of any file activity, including uploads, downloads, and copies across storage containers. The AzCopy command log entry example provided below was generated using all default settings for Azure Storage Explorer.

These logs capture the outcome of operations for all files involved in the AzCopy job. To identify possible data exfiltration, the two key events to look for are UPLOADSUCCESSFUL and UPLOADFAILED, seen after the“Starting transfer” event for a file.

There are practical situations where other events could become relevant for incident response. For instance, if a threat actor used Azure Storage Explorer or AzCopy directly to import toolkits or malicious programs, the DOWNLOADSUCCESSFUL and DOWNLOADFAILED events would reveal details about files brought into the network from Azure.

Another scenario that is more involved but still very possible, especially with the growing adoption of cloud services, involves Azure Storage Explorer already being installed on a system. This installation could allow a threat actor to perform a copy operation into a storage account they control. In such cases, the COPYSUCCESSFUL and COPYFAILED events would be crucial.

Notably, the "Logout On Exit" setting in Azure Storage Explorer is not enabled by default. It retains any valid Azure Storage sessions when the application is reopened.

At the end of the AzCopy log file, you’ll find a relevant and valuable summary for analyzing data exfiltration and other potential uses of Azure Storage Explorer by the threat actors.

Conclusion

As the landscape of ransomware and data exfiltrationcontinues to evolve, understanding the tools and tactics employed by threatactors is crucial for effective incident response. ModePUSH's observed use ofAzure Storage Explorer by threat actors for data exfiltration highlights theimportance of scrutinizing all activities taken during a compromise timeframe.By staying informed about these emerging trends and leveraging the availableforensic artifacts, incident, and forensic investigators can better defendagainst and investigate these sophisticated threats and protect critical data.
‍

IOCs

File Paths

- %USERPROFILE%\AppData\Local\Programs\Microsoft Azure Storage Explorer

- C:\Program Files\Microsoft Azure StorageExplorer

Executables

- StorageExplorer.exe

- azcopy_windows_amd64.exe

AzCopy Log file Location

- %USERPROFILE%\.azcopy

Network

- .blob.core.windows.net