Through our vast experience, Stroz Friedberg Incident Response Services has unique insight on how attackers attempt to cover their tracks and exfiltrate data from victim organizations. A relatively new strain of ransomware, Mount Locker, is changing the game and leaving behind not-so-subtle clues about its tactics for stealing data via AWS S3 buckets.
Laying the Groundwork
Mount Locker is a new ransomware strain, with one of the first reports shared on August 22, 2020 on Twitter.
The strain was first referred to as “Cbtucyny,” based on the .onion URL observed in the sample ransom note; however, it was later reported that the threat actors were referring to their ransomware as “Mountlocket.” In September 2020, BleepingComputer reported on the ransomware, provided a screenshot of its data leak website, and revealed the ransomware strain’s updated or correct name of “Mount Locker.”
On some recent Mount Locker incidents investigated by Stroz Friedberg, the data exfiltration technique was the same, but the threat actor toolkit and ransom notes were very different. Interestingly, the ransomware was deployed across some environments within the same ~24-hour period. Given the similarities observed, and as with many other ransomware variants, Mount Locker appears to be a “Ransomware as a Service” (RaaS), where affiliates pay ransomware developers for the ability to use the malware on victim networks.
In one matter, the ransom note and file extension closely matched those reported for Mount Locker. The ransom note contained a client ID, .onion website, claimed data exfiltration, and gave a 72-hour deadline for payment. As reported for Mount Locker, the ransom note was named “RecoveryManual.html” and the encrypted file extension was “.ReadManual.ID.” One notable difference in the ransom note was that the .onion link was prefixed with the victim organization’s name, rather than the reported “Cbtucyny” prefix.
The Script that Does it All
In one investigation, the threat actor moved laterally to the domain controller within two days of the first observed attacker activity. There, they created the folder C:\Windows\temp\vmware and used this as a home base for staging their tools. One PowerShell script was key to the attacker’s reconnaissance and exfiltration. We were able to carve the script from disk in various stages over time before the final version was ultimately used to initiate data exfiltration and ransomware deployment. This provides unique insight on the threat actor’s progression, version control, in-line comments, and edits and additions of modules. For example, the script was at one point named “shopping list collector v1.02” and later graduated to the simpler “[version] 4.31.”
One of the first components of the script downloads tools from a single GitHub account, which likely belongs to the attacker given the similarity between the GitHub account name and the author’s email address within the script. The script also includes a function to enable compatible TLS protocol versions on the host via the Windows Registry, to ensure the tools can be downloaded from the internet.
The script downloads four tools from GitHub, outlined below:
These tools are part of a data flow where SharpHound is first leveraged to map out the network. The *computers.json output file is decompressed and then parsed to compile a list of target hostnames, the latter is seen in the below figure.
The PowerShell script then outlines subfunctions which are later called by several main functions. The subfunctions identify the following information for target hosts:
These subfunctions are combined to execute the below eight main functions of the script:
As previously mentioned, the attacker maintained version control, comments, and a to-do list within the PowerShell script. These updates and notes are compiled in the below timeline.
According to the attacker’s comments within the PowerShell script, the AWSCollector module was added as part of v.4.31, on September 3, 2020. This module is by far the most interesting and is an unusual technique for threat actors to use to steal data. The module leverages AWS’ command line utility, accepts the threat actor’s AWS access key and secret access key, a target S3 bucket, and a few additional parameters. From the syntax used, the threat actor enabled AWS’ S3 Transfer Acceleration, which “enables fast, easy, and secure transfers of files over long distances between your client and an S3 bucket” as “data is routed to Amazon S3 over an optimized network path.” Three additional parameters were set for the maximum number of requests and the size of the upload chunks, as shown below:
- RunProgram -exe AWSCLIV2/aws.exe -params “configure set default.s3.max_concurrent_requests 60“
- RunProgram -exe AWSCLIV2/aws.exe -params “configure set default.s3.multipart_threshold 5GB“
- RunProgram -exe AWSCLIV2/aws.exe -params “configure set default.s3.multipart_chunksize 5GB“
Furthermore, the AWSCollector module creates log files with the name: ‘aws.’ + $instanceid + ‘.’ + $system + ‘.log.’ A sample log file is seen below, which includes progress, size, source file paths on disk and destination file paths within an AWS S3 bucket. This information provides key insight on the files and folders exfiltrated.
Several additional log files were located on disk that tracked the progress of the script’s main functions. From the PowerShell script, one of these logs is named “ldt.${instanceid}.log,” where {instanceid} is a timestamp. This log tracks whether a host was online and, if it is, the status of the Locker function (which encrypts files), status of data uploads to S3, and overall progress of the total jobs.
What’s Next?
At the very start of the PowerShell script, the threat actor left themselves a to-do list, including a variety of items to review, add, and fix. They provided us some humor with a comment to themselves; “[…] what to do next? <!- stupid idea! too much of this shit around.” The comments provide additional insight on future functionality of the PowerShell script. This includes encryption on the AWS command line and, notably, functionality to leverage the Telegram messaging application to receive notifications on process start up, completion, and system heartbeats. There are also comments to better clean up after themselves, including to remove the “vmware” folder used to stage the attacker’s tools.
Based on information from our active investigations combined with various threat intelligence sources, Stroz Friedberg’s incident response team believes that Mount Locker operates as part of a Ransomware as a Service affiliate group that has been active between at least May and September 2020. It seems as if this threat actor is just getting started and has plans for future development of this ransomware so we’re continuing to keep a watchful eye.
Author: Mary Braden Murphy