MountLocker Ransomware-as-a-Service Offers Double Extortion Capabilities to Affiliates

Since mid-October 2020, the BlackBerry Incident Response Team have been actively tracking MountLocker affiliate campaigns as part of ongoing investigations. The affiliates are typically responsible for the initial compromise, distribution of MountLocker ransomware, and exfiltration of sensitive client data during a breach.

In coordination with the BlackBerry Research and Intelligence Team, our researchers and investigators have produced the following wide-ranging report on MountLocker. It covers this threat’s operators, affiliates, ransomware, decryptor, and associated tactics, techniques, and procedures (TTPs).

Key Findings

• MountLocker is a Ransomware-as-a-Service (RaaS), active since July 2020.
• The MountLocker ransomware was updated during early November 2020 to broaden the targeting of file types and evade security software.
• Victim’s files are encrypted using ChaCha20, and file encryption keys are encrypted using RSA-2048.
• The ransomware appears to be somewhat secure; there are no trivial weaknesses allowing for easy key recovery and decryption of data. MountLocker does however use a cryptographically insecure method for key generation that may be prone to attack.
• MountLocker affiliates were observed:
  • Using commercial-off-the-shelf tools such as CobaltStrike Beacon to deploy MountLocker ransomware.
  • Exfiltrating sensitive client data via FTP prior to encryption.
  • Engaging in blackmail and extortion tactics (alongside the operators) to coerce victims into making hefty payments to recover and prevent the public disclosure of stolen data.
• Owing to the RaaS and affiliate program, targeting is geographically diverse and becoming more prominent.

Operators and Affiliates

Our investigations into MountLocker-related affiliate campaigns suggests that threat actors often used remote desktop (RDP) with compromised credentials to gain access to a victim’s environment. In one instance, after establishing a foothold in an organisation, there was a delay of several days before activity resumed. It is likely that the threat actors were negotiating with the MountLocker operators to join their affiliate program and obtain the ransomware during this pause. Upon obtaining the MountLocker ransomware, the threat actors were observed returning with several “public” tools, including CobaltStrike Beacon and AdFind from Joeware. Over a period of approximately 24 hours:

• AdFind is used to perform network reconnaissance.
• A custom batch file is used to exfiltrate sensitive documents from key systems via FTP.
• CobaltStrike Beacon is leveraged to spread laterally and deploy the MountLocker ransomware.
  
  

Figure 1. MountLocker kill-chain

The following crude batch script (sanitized for confidentiality reasons) was used by the attackers to perform exfiltration of sensitive data. The script starts by uploading a “desktop.ini” file to the sever using curl, then enumerates a hardcoded root directory (localdir) and all subdirectories. Each file is uploaded to the FTP server as it goes:

Figure 2. MountLocker FTP exfiltration batch script

Successful MountLocker affiliates have been known to seek multi-million-dollar payments for decryption services and to prevent public disclosure of stolen data. The MountLocker operators are currently hosting a site on the dark web where they announce their recent targets and supply links to leaked data. The site is currently listing five victims; we believe the actual number to be far greater:

Figure 4. MountLocker full data dump

Ransomware

The MountLocker ransomware, at less than 100Kb in size, is lightweight and simple in construction. It is typically deployed as either an x86 or x64 Windows portable executable (PE) file, although occasionally as a Microsoft Installer (MSI) package:

Figure 5. Composition of a x64 MountLocker PE file

Features

• Simple, lightweight, and efficient ransomware
• Semi-unique file extension per victim organization
• Uses ChaCha20 for file encryption and RSA-2048 for key encryption
• Weak key generation using GetTickCount

Behavior

Upon execution, MountLocker will process any command-line arguments supplied by the operators:

Figure 6. Command-line arguments

Next, MountLocker initializes debug logging and creates a run-once mutex. The mutex is based on the serial number of the volume containing the Windows directory, and yields a 32-character uppercase hexadecimal string:

Figure 7. Run-once mutex

The ransomware then proceeds to initialize the encryption keys and create the ransom note. MountLocker contains an embedded 2048-bit RSA public key supplied by the attackers. It is imported and used to encrypt a random session key generated using the cryptographically insecure GetTickCount API. This offers the slim possibility that knowing the timestamp counter value during ransomware execution could lead to the session key being brute-forced.

After initializing the encryption keys, MountLocker will create the ransom note from a template and add the ransomware file extension to the registry. When a user double clicks an encrypted file, the ransom note is opened via Explorer. The file extension is a hex encoded 4-byte (or 8 character) “Client ID”, which is unique per victim organization:

Figure 9. Attackers' RSA public key embedded in MountLocker

The ransom note can vary slightly between samples, and in some cases incorrectly states that AES encryption was used. It contains a Tor .onion URL to contact the MountLocker operators via a “dark web” chat service to discuss a price for decryption software:

Figure 10. Typical Mountlocker ransom note

After initialization is complete, prior to encryption, MountLocker will attempt to terminate a range of processes belonging to security software, office applications, browsers, and databases:

MountLocker then proceeds to enumerate first local and then remote volumes looking for files to encrypt. For each volume found, it takes the following steps:

1.      If specified via command-line (using /marker:) create a marker file on the root of the volume.

2.      Recursively iterate over all files/folders:

a.      If the FindFirstFile function returns ERROR_ACCESS_DENIED, try to change permissions of the root directory by setting the owner and DACL (discretionary access control list) values in its security descriptor to the same ones as the parent process.

3.      For each file found:

a.      Check whether the parent folder path is one of the following, and therefore excluded from encryption:

b.       Check if the file extension is allowed. MountLocker contains a huge list of over 2600 file extensions that it will target for encryption, including known file extensions for databases, documents, archives, images, accounting software, security software, source code, games, backups and various custom data formats. Common file extensions for executable files (.exe, .dll, .sys) are not targeted.

c.       Ensure the filename is not “RecoveryManual.html”.

d.      Memory map the file.

e.      Generate a random encryption key for the file, again using the cryptographically insecure GetTickCount API (via rdtsc, and without the use of a Sleep API call!):

Figure 11. Create ChaCha20 file key

a.      Encrypt the file key with the session key using ChaCha20, and write both the encrypted file key (32-bytes) and encrypted session key (256-bytes) to the file:

Figure 12. Encrypt the file key with the session key and write the file header

a.      Memory map the input file and ChaCha20; encrypt it using the file key in 64MB chunks:

Figure 13. Encrypt file contents

a.      Move the file and restore the owner and DACL:

Figure 14. Move file after encryption and optionally set named security information

Post encryption, the composition of a MountLocker encrypted file is as follows, where:

• The red highlighted region is the 32-byte ChaCha20 file key, encrypted using ChaCha20 with the session key.
• The green region is the ChaCha20 session key, encrypted using RSA with the attackers’ 2048-bit public key.
• The blue highlighted region is the original file contents, encrypted using ChaCha20 with the randomly generated file key.
  
  

Figure 15. MountLocker file composition

After the encryption process is completed, MountLocker will delete volume shadow copies to prevent the restoration of the encrypted files:

Figure 16. Delete volume shadow copies

Finally, in the absence of the /nodel command-line argument, MountLocker will drop the following batch file to remove itself from disk:

Figure 18. Execute cleanup batch file

Version 2

MountLocker version 2 first surfaced in the wild during late November 2020, with a compilation timestamp from earlier in the month (November 6th). It is considerably smaller in size than the previous versions (approximately 50% smaller, at 46Kb for the x64 build) owing to the removal of the vast file extension “include” list. Instead, MountLocker version 2 turns this process on its head, and targets a far smaller list of file extensions to explicitly exclude from encryption:

• .exe, .dll, .sys, .msi, .mui, .inf, .cat, .bat, .cmd, .ps1, .vbs, .ttf, .fon, .lnk

Overall, the code bears approximately 70% similarity to the initial MountLocker release, with no apparent changes to:

• Cryptographic initialization and ransom note creation
• Client ID calculations
• Volume traversal
• DACL modifications
• ChaCha20/RSA encryption

As for updates, the most obvious initial differences are the reworded debug messages:

Figure 19. Updated debug messages in MountLocker version 2

The biggest change is in the process termination code and deletion of volume shadow copies. This is now implemented using a PowerShell script that gets written to a temporary directory and executed via a PowerShell one-liner prior to encryption:

Figure 20. Drop and launch PowerShell script from MountLocker version 2

The script itself will simply Base64 decode and gzip decompress a further PowerShell script, which is then invoked using iex:

Figure 21. MountLocker PowerShell decoder

Once decoded, the underlying PowerShell script deletes volume shadow copies then attempts to terminate all services and processes running outside of the Windows directory. The script will avoid terminating processes belonging to itself, Tor, PowerShell, several browsers, and a long list of security software (allowing the victim to still use Tor to­­­­ contact the MountLocker operators to negotiate payment):

Figure 22. Process termination script in MountLocker version 2

MountLocker aims to evade security software that is not configured to terminate the entire process tree when handling alerts. It does this through the deletion of volume shadow copies and termination of processes in a separate process (powershell.exe).

Finally, in addition to removing the large file extensions list, MountLocker version 2 has an updated list of folders that are excluded from file encryption:

Figure 23. Updated exclude folders in MountLocker version 2

Decryptor

The only MountLocker decryptor we’ve observed in the public domain is heavily based on the first x86 MountLocker ransomware codebase. It shares about 70% of the original functionality, including the run-once mutex, process termination and volume traversal.

During the decryption process, the program will search all local and network volumes, as well as mapped shares, looking for encrypted files. The encrypted file and session keys are read from each file, and a checksum of the session key is computed. If the checksum doesn’t match a global session key checksum then the attackers RSA private key will be imported and used to decrypt the session key. The decrypted session key is then used to decrypt the file key using ChaCha20:

Figure 26. Attacker's RSA private key embedded in the decryptor

Finally, the file key is used to ChaCha20 decrypt the file in 64MB chunks:

Figure 27. ChaCha20 file decryption

Conclusions

The MountLocker Operators are clearly just warming up. After a slow start in July they are rapidly gaining ground, as the high-profile nature of extortion and data leaks drive ransom demands ever higher. MountLocker affiliates are typically fast operators, rapidly exfiltrating sensitive documents and encrypting them across key targets in a matter of hours.

Since its inception, the MountLocker group have been seen to both expand and improve their services and malware. While their current capabilities are not particularly advanced, we expect this group to continue developing and growing in prominence over the short term.

Our AI-based endpoint security solution BlackBerry® Protect® has thwarted several MountLocker attacks in customer’s environments, preventing the ransomware from ever being deployed. BlackBerry Protect uses machine learning to provide an automated safeguard against both simple and sophisticated threats. It does this without the need for signatures, heuristics, sandboxes, cloud connections, or extensive human intervention.

Appendix

Indicators of Compromise (IoCs)

MITRE ATT&CK

Hunting

The following VirusTotal query uses a simple content search to find related samples:

https://www.virustotal.com/gui/search/content%253A%2522Crypt%2520Avg%253A%2522/files

The following VirusTotal query uses a behaviour search to find related samples:

https://www.virustotal.com/gui/search/behaviour_files%253A%2522.readmanual.%2522/files

YARA

The following YARA rule looks for common MountLocker ransomware strings in the .rdata section of a PE file: