Fake LockBit, Real Damage: Ransomware Samples Abuse AWS S3 to Steal Data
When executed on the infected machine, the ransomware first performs initialization through the following steps:
- Get the host machine universal unique identifier (UUID)
- Import the hard-coded public key
The public key is encoded in Privacy Enhanced Mail (PEM) format.
Decoding the values of the public key reveals RSA encryption and the modulus size of 2048 bits.
- A random master key is generated and encrypted using the previously imported RSA public key. (This means that only the threat actor who owns the private key can use it to decrypt the master key.)
- Write the encrypted master key to the readme text file (README.txt).
- Use AWS SDK for Go v2 library’s StaticCredentialsProvider to load static credentials. Static credentials include hard-coded AccessKeyID, SecretAccessKey, and AWS_REGION.
After the initialization, the ransomware starts enumerating all files available in / (root directory for the macOS variant) by calling the filepath.Walk function. Each enumerated file is checked to confirm if it is in the exclusion folder. If yes, such files will not be encrypted.
The ransomware contains a list of file extensions (usually for documents, photos, and data files) that will be encrypted.
The README.txt file name is excluded from encryption.
Exfiltration
Based on the acquired host machine UUID, the sample creates an Amazon S3 bucket on the attacker-controlled AWS account using the hard-coded pair of credentials.
Once the bucket has been created, the S3TA feature is enabled by modifying the configuration.
The last step is encryption of the file from the beginning to the end. The encryption algorithm is AES-CTR, with password being md5 hash file name concatenated with master key.
As an example, ransomware generates random 16-byte master key 20 60 A3 EA 54 84 C9 27 57 76 1E CC 1F FC 12. Name of the encrypted file is text.txt.
So the 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.
Files are then uploaded from the victim’s machine to the attacker-controlled AWS account.
S3TA enables users to achieve faster data transfer over long distances. It leverages the globally distributed edge locations in Amazon CloudFront. To use this feature, it must be enabled on the bucket. The bucket name should be Domain Name System (DNS) compliant and must not have periods. An S3 bucket with S3TA enabled can be accessed by the following endpoints, depending on the type of AWS environment:
- bucketname[.]s3-accelerate.amazonaws.com
- bucketname[.]s3-accelerate.dualstack.amazonaws.com
Each file, which passed the previous file extension checks and is smaller than 100 mebibytes (MiB), is uploaded to AWS by calling the Uploader.Upload function. This is due to saving AWS space and funds, as uploading big files will cost attackers more money.
The last step is encryption of the file from beginning to end. The encryption algorithm is AES-CTR, with the password being the MD5 hash of the file name concatenated with the master key.
The ransomware generates a random 16-byte master key (for example 63 20 60 A3 EA 54 84 C9 27 57 76 1E CC 1F FC 12). The name of the encrypted file is text.txt.
Correspondingly, the 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. This is shown in the screenshot below (generated via CyberChef, used here for visualization purposes only).
This resulting hash is used as AES key parameter of crypto.AES.NewCipher function. The initialization vector is a randomly generated 16-bytes and is passed into crypto.cipher.NewCTR function.
After the encryption, the file is renamed according to the following format: <original file name>.<initialization vector>.abcd. For instance, the file text.txt was renamed to text.txt.e5c331611dd7462f42a5e9776d2281d3.abcd.
We ran the ransomware sample in the debugger and dump master key. Then we verified that we can correctly decrypt the previously encrypted file by choosing the proper cipher and passing the correct parameters, as shown in the screenshot below (generated via CyberChef, used here for visualization purposes only).
The README.txt file contains base64 encoded content. Decoding it reveals the master key encrypted by crypto.rsa.EncryptPKCS1v15 with a hard-coded public key as its parameter, then encoded by base64. This base64 encoded blob is followed by hostname, OS version, and infected machine identifier. To decrypt the master key, we would need the ransomware developer’s private key, which we do not have.
After all files are processed, the ransomware changes the device’s wallpaper. We observed two different wallpapers in use, and both have been stolen or copied either from LockBit attacks or from a security blog mentioning the ransomware family. It should be noted however that 2.0 is not the latest LockBit version. Furthermore, key figures behind the ransomware operations have just been apprehended earlier this year.
On macOS, the ransomware uses osascript to change the wallpaper. The osascript command is as follows:
“tell application “System Events” to tell every desktop to set picture to “%s”.
On Windows, the ransomware calls SystemParametersInfoW with uiAction parameter set to SPI_SETDESKWALLPAPER to change the wallpaper.
In some Windows samples, we can also find code for deleting backups (shadow copy). Interestingly, the ransomware developer likely, without understanding, copied shadowcopy.go from a ransomware-simulator project and left the parameter /for unchanged.
Conclusion
Attackers are increasingly leveraging cloud services and features to further their malicious activities. In this blog, we analyzed a Golang ransomware that abuses Amazon S3’s Transfer Acceleration feature to upload victim files to attacker-controlled S3 buckets. Such advanced capabilities enable attackers to efficiently exfiltrate data as they take advantage of cloud service providers.
Furthermore, account identifiers of cloud providers such as AWS Account IDs linked to malicious activities can serve as valuable IOCs. By tracking these IDs, defenders can better identify and mitigate threats within their cloud environments, underscoring the need for vigilant monitoring of cloud resources.
Threat actors might also disguise their ransomware sample as another more publicly known variant, and it is not difficult to see why: the infamy of high-profile ransomware attacks further pressures victims into doing the attacker’s bidding.
To further boost security, organizations can also employ security solutions such as Vision One to detect and stop threats early and no matter where they are in the system.
AWS Security Feedback
We contacted AWS about this incident and received the following comment:
AWS can confirm that AWS services are operating as intended. The activity identified violates the AWS acceptable use policy and the reported AWS access keys and account have been suspended.
Ransomware is not specific to any computing environment in particular. However, AWS provides customers with increased visibility into and control over their security posture with respect to malware.
We recommend customers who suspect or become aware of AWS resources being used for suspicious activity to complete the abuse form or contact trustandsafety@support.aws.com.
We thank Trend Micro for engaging AWS Security.
Indicators of Compromise
During our monitoring, we have seen different versions of this ransomware. All had encryption features, but only some had upload functionality and valid tokens. This, along with other differences among variants, suggests that the ransomware is still in development.
The full list of IOCs can be found here.
Read More HERE
