AWS ransomware - and what's really behind it

Recently, a customer contacted InfoGuard's Computer Security Incident Response Team (CSIRT) and reported that an attacker had deleted several AWS S3 buckets. The attacker then left a ransom note. In this post, which is based on the original from the dfir.ch blog, we examine a recovery binary in detail that the attacker left behind after deleting the buckets. Our Head of Investigations, Stephan Berger, also explains why the binary file is just a diversionary manoeuvre to increase the pressure on the victim. But first things first.

The backstory: We received a report that the attacker had deleted several AWS S3 buckets before allegedly downloading the data. The original ransom note was as follows (we have of course made sensitive information unrecognisable):

Another version of this ransom note, lacking the recovery component, has been uploaded to VirusTotal. It was initially submitted on January 29, 2024, from France, matching roughly our timeline.

Tracing the attack and reconnaissance

We traced the initial actions of the attacker back to January 18, 2024, when they executed two standard reconnaissance commands against the AWS Simple Email Solution (SES) and Amazon Simple Storage Service (S3):

• GetSendQuota
• ListBuckets

Invictus-IR created a CSV file with interesting CloudTrail events from another ransomware incident in the cloud. It is highly recommended that defenders and SOC members check their security monitoring for these event names, as these events could tell that an attacker has access to an AWS endpoint.

Figure 1: Important CloudTrail event logs

Deletion of Buckets

On February 5th, the attacker utilized the command DeleteBucket to erase all buckets, leaving behind the previously mentioned ransom note. Before the deletion of the buckets, the following commands were recorded in the CloudTrail logs:

• GetBucketVersioning (siehe Abbildung 1 – die Versionierung war nicht aktiviert)
• GetBucketReplication
• GetBucketObjectLockCon guration
• GetBucketLogging
• GetBucketRequestPayment
• GetAccelerateCon guration

You call it recovery – We call it scam

Within the ransom note, the following three Linux commands are mentioned:

• tar xzvf recoveryBYESZ2ESTHWPWHDRAXZ7.tgz
• chmod +x recovery
• ./recovery

The attacker placed this archive (recoveryBYESZ2ESTHWPWHDRAXZ7.tgz) in the same folder as the ransom note, including a text file called aws.txt. The complete archive includes numerous unrelated folders containing Linux libraries, C source code files, Python files, etc.,to boost the archive size and give the archive a more ‘serious’ touch.

Focusing only on the recovery part, we read the following statement inside the ransom note:

You need to be authenticated into aws-cli with credentials to perform restore run -> aws configure and authenticate if you are not already ! Once the recovery starts, you need to be sure your connection does not drop, your computer does not crash.

Analysis of the binary

The recovery binary (called simply recovery, see above) was initially uploaded to VirusTotal on February 2nd, 2024. Upon launching the recovery binary, it prompts us for the AWS key. Subsequently, the binary informs us that it verifies the account information and then prints details about it.

After entering the AWS key, the binary indicates it is checking something. However, based onthe strace output (see my post about using strace for Linux malware analysis), the code simply sleeps for five seconds (the number 5 was passed on as an argument to the system call clock_nanosleep).

Upon further examination of this behavior, we discover a call to the sleepRandom() function, directing the binary to sleep for a random duration. This aligns with the observed behavior in the strace output.

Figure 2: Welcome to AWS recovery

The sleepRandom() function utilize the sleep() function under the hood:

Figure 3: sleepRandom() function

The aforementioned account information was retrieved from the file aws.txt, which was included within the “recovery package” alongside the recovery binary. Below is a mockup version of the file:

Here is an excerpt from the strace output, showing the process of reading the aws.txt file (openat() followed by read()):

The binary generates a new directory (mkdir) and places randomly named files within it. The openat() syscall is used again, but this time, unlike above, the parameter O_CREAT is passed to the function - If pathname does not exist, create it as a regular file.

Upon revisiting the binary in Ghidra, we observe that the following two functions are responsible for creating files and folders:

• createFoldersFromFile();
• displayFileInfo();

To create the folders, the binary reads the bucket names from the aws.txt file and generates a folder for each bucket.

Figure 4: createFoldersFromFile()

The total number of files and the total file size are calculated exclusively from the information provided in the aws.txt file - the binary does not connect to the Internet or AWS.

Figure 5: displayFileInfo()

Similar to verifying the AWS access key, the downloading process is a red herring, as evidenced by the strace log.

While executing the binary, after displaying the “Downloading” message, the terminal prints the following message: “Download has been paused - please make payment.” Upon investigating the download functionality of the binary, it was obvious that not a single line of code initiates a network connection to check keys, buckets, or access rights.

Figure 6: Download has been paused

The Download has been paused message is yet another red herring, tricking the victim into paying the ransom. The user is prompted to enter the Transaction ID/Hash of the paid ransom, however, once again, the binary does nothing with the information entered by the user besides increasing the pressure on the victim.

Finally, the “downloading” of the data will continue, showing the user how much time is left until completion.

Figure 7: Transaction ID/Hash

The analysis of the binary has shown that nothing is checked behind the curtains; not a single domain is contacted, nor was a network connection done.

Figure 8: Time until recovery is finished

ELF DIGEST, the non-profit Linux malware analysis service, also does not find any trace of network connections. Here is the report from which we took the screenshot (requires a user name).

Figure 9: Report from ELF Digest

Our conclusion 

The network traffic analysis showed that the attackers most likely stole solely 2 GB of data, compared to the over 1 TB of data available on the bucket. Thus, a restore would not have been possible anyway. The whole “recovery” binary is just a neat trick the attackers use to trick the victims into paying the ransom. The analysis with a dynamic approach (strace) and a static one (Ghidra) proved successful, allowing us to quickly gain insights into the binary.

You can find out more about our Cyber Defence Services – from Security Operations and Hunting & Intelligence to Managed Detection & Response (MDR) and Incident Response & Forensics – on our website:

Prevention is better than cure: thanks to our Incident Response Retainer, you are perfectly prepared for a security incident. Quickly, efficiently and effectively. We look forward to discussing this with you without obligation.