False LockBit, Actual Harm: Ransomware Instances Exploit AWS S3 to Snatch Data
Upon activation on the compromised device, the ransomware initiates its operations using the subsequent procedures:
- Retrieve the unique universal identifier (UUID) of the host device
- Integrate the pre-coded public key
The public key is stored in Privacy Enhanced Mail (PEM) format.
Unraveling the contents of the public key discloses RSA encryption and a modulus size of 2048 bits.
- An arbitrary master key is created and cryptographically secured using the previously incorporated RSA public key. (This indicates that solely the malicious actor in possession of the private key can decipher the master key.)
- Save the encrypted master key to the readme text file (README.txt).
- Employ AWS SDK for Go v2 library’s StaticCredentialsProvider to load fixed credentials. Fixed credentials cover ingrained AccessKeyID, SecretAccessKey, and AWS_REGION.
Following the initialization phase, the ransomware commences inspecting all files present in / (primordial directory for the macOS variant) by invoking the filepath.Walk function. Each ascertained file undergoes scrutiny to verify if it resides in the exclusion directory. Files meeting this criteria are exempted from encryption.
The ransomware encompasses a catalogue of file extensions (primarily for documents, images, and data files) that will be subjected to encryption.
The README.txt filename is excluded from the encryption process.
Exfiltration
Using the obtained host device UUID, the sample initializes an Amazon S3 bucket on the hacker-controlled AWS account utilizing the embedded authentication credentials.
Subsequent to the bucket’s creation, the S3TA functionality is activated through configurations modification.
The terminal step involves encrypting the file from start to finish. The encryption methodology entails AES-CTR, with the password formed by concatenating the md5 hash of the file name with the master key.
For illustration, the ransomware produces a random 16-byte master key 20 60 A3 EA 54 84 C9 27 57 76 1E CC 1F FC 12. The encrypted file is named text.txt.
Thus, the resultant concatenated byte sequence is 74 65 78 74 2E 74 78 74 63 20 60 A3 EA 54 84 C9 27 57 76 1E CC 1F FC 12 and its MD5 hash is 23 a3 ec c5 58 2d 97 41 07 3c 3b dc 31 7d 49 30.
Subsequently, files are transferred from the victim’s device to the perpetrator-controlled AWS account.
S3TA facilitates expedited data transfer across extensive distances. It capitalizes on the globally distributed edge locations within Amazon CloudFront. To activate this functionality, it must be enabled on the bucket. The bucket label must comply with Domain Name System (DNS) standards and avoid dots. An S3 bucket that has S3TA operational can be accessed through specific endpoints based on the AWS environment type:
- bucketname[.]s3-accelerate.amazonaws.com
- bucketname[.]s3-accelerate.dualstack.amazonaws.com
Each file, meeting the preceding file extension assessments and being under 100 mebibytes (MiB) in size, is uploaded to AWS via invocation of the Uploader.Upload function. This practice aims at conserving AWS space and optimizing expenditures, as uploading large files would lead to increased costs for the attackers.
The final step entails encrypting the file from its inception to conclusion. The encryption process involves AES-CTR, with the passphrase constituted by the MD5 hash of the filename connected to the master key.
The ransomware generates a random 16-byte master key (e.g., 63 20 60 A3 EA 54 84 C9 27 57 76 1E CC 1F FC 12). The encrypted file is designated as text.txt.
Consequently, the concatenated byte sequence reads 74 65 78 74 2E 74 78 74 63 20 60 A3 EA 54 84 C9 27 57 76 1E CC 1F FC 12 and its MD5 hash is 23 a3 ec c5 58 2d 97 41 07 3c 3b dc 31 7d 49 30. This is depicted in the presented image below (generated through CyberChef, solely utilized for visual representation).
This resultant hash serves as the AES key parameter for the crypto.AES.NewCipher function. A 16-byte initialization vector is randomly produced and fed into the crypto.cipher.NewCTR function.
Post-encryption, the file is renamed in the format: <original file name>.<initialization vector>.abcd. For instance, the file text.txt transitions to text.txt.e5c331611dd7462f42a5e9776d2281d3.abcd.
We executed the ransomware sample in a debugger to extract the master key. Subsequently, we confirmed to be able to decrypt the previously encrypted file accurately by selecting the appropriate cipher and inputting the correct parameters, exemplified in the displayed image below (created via CyberChef, utilized purely for visualization).
The README.txt file incorporates content encoded via base64. Decoding reveals the master key encrypted using crypto.rsa.EncryptPKCS1v15 with a pre-set public key as an argument, further encoded with base64. Following the encrypted base64 string are the hostname, OS version, and infected machine identifier. To decrypt the master key, access to the ransomware developer’s private key is imperative, a resource we lack.
Upon completion of processing all files, the ransomware alters the device’s wallpaper. We noted the utilization of two distinct wallpapers, both sourced or replicated from prior LockBit assaults or a security blog referencing the ransomware lineage. Notably, version 2.0 does not represent the most recent LockBit iteration. Moreover, vital figures associated with the ransomware activities have recently been apprehended earlier this year.
On macOS,The ransomware leverages osascript for altering the wallpaper. The command structure for osascript is as follows:
“tell application “System Events” to tell every desktop to set picture to “%s”.
When targeting Windows systems, the ransomware utilizes SystemParametersInfoW with the uiAction parameter set to SPI_SETDESKWALLPAPER to adjust the wallpaper.
Some Windows variants of the malware also consist of code for eliminating backups (shadow copy). Interestingly, the ransomware developer seems to have unintentionally copied shadowcopy.go from the ransomware-simulator project and retained the parameter /for without alteration.
Wrap-up
Cyber attackers are increasingly exploiting cloud services and functionalities to advance their malevolent operations. In this article, we examined a Golang ransomware that misuses Amazon S3’s Transfer Acceleration feature to transfer victim files to S3 buckets controlled by attackers. Such sophisticated capabilities empower adversaries to swiftly extract data while capitalizing on cloud service providers.
Additionally, identifying cloud provider account identifiers such as AWS Account IDs associated with malicious activities can serve as crucial Indicators of Compromise (IOCs). By monitoring these identifications, defenders can effectively pinpoint and counteract threats within their cloud ecosystems, underscoring the critical need for vigilant surveillance of cloud assets.
Malicious actors may also mask their ransomware samples as more renowned variants, and the reason behind this is quite evident: the notoriety of prominent ransomware attacks further coerces victims into complying with the attackers’ demands.
To strengthen security measures, organizations can also deploy security solutions like Vision One to proactively identify and thwart threats at an early stage and across the system.
AWS Security Response
We reached out to AWS regarding this incident, and received the subsequent response:
AWS can confirm that AWS services are functioning as expected. The observed activity breaches the AWS acceptable use policy and the implicated AWS access keys and account have been suspended.
Ransomware is not confined to any specific computing environment. Nonetheless, AWS equips customers with enhanced visibility and control over their security stance concerning malware.
We advise customers who suspect or detect the suspicious use of AWS assets to complete the abuse form or reach out to trustandsafety@support.aws.com.
We express our gratitude to Trend Micro for their engagement with AWS Security.
Signs of Intrusion
During our surveillance, we encountered various iterations of this ransomware. All versions featured encryption capabilities, though only a subset contained upload functionality and valid tokens. This, combined with other discrepancies across versions, implies that the ransomware is still undergoing development.
The comprehensive list of Indicators of Compromise (IOCs) can be accessed here.
About Author
