LUNA Ransomware Attack Pattern Analysis

Principaux points abordés

• LUNA is ransomware that achieves cross-platform capabilities through its development in Rust
• The Windows capabilities are comparable to other ransomware peers
• The Linux capabilities, while functional, are less elegant than the Windows variant

Préambule

LUNA Ransomware, which Elastic tracks as REF5264, is a Rust-based ransomware first identified by Kaspersky in their report introducing it in July 2022. Rust as a programming language is known in the developer community for being simpler to implement cross-platform software to work on various target operating systems. It’s able to do this through a convenient cluster of tools that abstract away some operating system peculiarities, likely allowing the malware author to focus more on core functionality.

From the Kaspersky report we were able to collect two LUNA Ransomware samples: (1) a Linux ELF binary, and (2) a Windows PE executable.

This research covers:

• Execution and behavior of each sample
• Description of the encryption mechanism
• Comparison across our samples
• Comparison to other ransomware
• Detection opportunities

Execution Chain

In the following sections, we'll describe both the Linux and Windows execution chains.

Linux execution

Our Linux sample required an argument to execute. The options were -file [file] to encrypt a single file, or -dir [directory] to walk and encrypt the contents of a specified directory and drop a ransom note. If executed with no arguments, Linux LUNA returns a help page with instructions to use one of the two available arguments. If executed with both the -file and -dir arguments (including multiple files or directories), all arguments are used.

There are no functional protections against encrypting system directories or files. We were able to demonstrate this through encryption of /etc. The execution loop continued as expected until it encrypted the shadow and sudoers files and the process was unable to verify privileges for further file access. The test machine then became unresponsive and required reverting to a prior snapshot. Encryption of these critical system files prevents further encrypting of privileged files and directories the malware attempts to access.

All encrypted files are appended with a .Luna extension, i.e. /etc/passwd.Luna. If using the -dir flag, a r** eadme-Luna.txt ransom note will be created at the root of each encrypted directory as well as subdirectories such as /etc/readme-Luna.txt and /etc/ssl\readme-Luna.txt . While there are no ransomware notes dropped when encrypting an individual file using the -file flag, the encrypted file is still appended with the.Luna** extension.

You may notice the backslash instead of a forward slash in the above full path /etc/ssl\readme-Luna.txt. This is an interesting artifact of LUNA hardcoding a **** to append to subdirectories when building the full path for the ransom note. This behavior is expected and would go unnoticed in a Windows environment, but drew our attention when we saw it in Linux. It does not appear to hinder functionality.

The ransom note is embedded in the binary in a Base64 format and placed in the root of the targeted directories.

The ransom note contains grammatical and spelling errors, listing two ProtonMail email addresses. ProtonMail is an end-to-end encrypted email service based in Switzerland. ProtonMail is popular with privacy-minded individuals and organizations because it uses client-side encryption to protect email content and user data before they are sent to ProtonMail servers.

The phrase “All your files were moved to secure storage” may be either a translation error for “encrypted” or an attempt to trick the victim into believing their data has been encrypted and stolen to later be used for extortion. This could also refer to some operation that is to occur before encryption takes place. There is no network connectivity aspect of this malware.

There is a threat of extortion with the phrase “we can show your real face”, but no extortion site has been observed as other extortion activity groups, like CUBA Ransomware, have used.

Linux Exclusions

Our Linux LUNA sample includes functional but largely unnecessary exclusions leftover from the Windows implementation. These checks are performed in the -dir execution flow before a file is sent to the add_file function for encryption. As an example, see the .ini , .exe , .dll , and .lnk extensions and OpenServer , Windows , Program Files , Recycle.Bin , ProgramData , AppData , and the All Users directories below. Of note, while the .Luna extension is included in the vestigial exclusions, it is present in both Windows and Linux.

Linux LUNA checks for Windows file extensions and folders and will not encrypt files with the specified extensions on a Linux victim.

The check for the .Luna extension is useful in that it prevents re-encrypting an already encrypted file.

Windows execution

The Windows sample we found was a more full-featured product that included much of the functionality present in other mature ransomware families. It still includes the -dir and -file flags, but now if the malware is run without arguments, the Windows LUNA will perform some preliminary defense evasion, file protection preparation, and enumeration measures before entering the -dir execution loop. Additionally within the -dir execution flow Windows LUNA file and directory exclusions are functional and serve to protect critical system processes from being corrupted by encryption. This is different from what was observed with the Linux LUNA implementation which does not exclude sensitive OS directories or files that can impact system stability.

LUNA uses service and process termination to de-conflict any files locked by other programs to successfully encrypt them along with disabling security products that may prevent ransomware execution. It does this by leveraging a built-in Rust process builder ( std::sys::windows::process::Command::new ) to call three new processes with their own pre-defined command-line arguments.

• Service Control
• Net
• TaskKill

Service Control

Service Control is a Windows utility used to modify services’ entries in the registry and in the Service Control Manager database. In this case, it’s used to ensure a service that is stopped cannot be restarted and interrupt malware execution.

• "C:\WINDOWS\system32\sc.exe" config [service] start=disabled
  • "C:\WINDOWS\system32\sc.exe" : Service Control executable
  • config [service]: Specifies the service (as an example, WinDefend) that will be modified
  • start=disabled : Sets the start type of the service to “disabled”

LUNA does not check that a service exists before issuing the service disable command. So it will commonly get 1060 errors to the console indicating that sc.exe attempted to modify a service that does not exist.

Our LUNA sample attempts to disable 253 different services. See the Appendix: Windows Services Termination List for the complete list.

Net

Net ( net.exe ) is a Windows utility used in command-line operations for the control of users, groups, services, and network connections. In this case, it is used to stop the running services that have already been prevented from restarting by sc.exe.

• "C:\WINDOWS\system32\net.exe" stop [service] /y
  • "C:\WINDOWS\system32\net.exe" : Net executable
  • stop [service]: Specifies the name of the service (as an example, WinDefend) that will be stopped
  • /y : Carries out the command without first prompting to confirm actions

Again there are no checks that the service is actually running on the victim machine. For Net, this manifests as 2185 errors printing to the console for each attempt to stop a nonexistent service.

TaskKill

TaskKill ( taskkill.exe ) is a Windows utility used to end a task or process by the process ID or image name. LUNA uses TaskKill to terminate processes by name that could interfere with the malware’s operation by maintaining file access locks on files targeted for encryption.

• "C:\WINDOWS\system32\taskkill.exe" /im [process name] /f
  • "C:\WINDOWS\system32\taskkill.exe" : TaskKill executable
  • /im [process name]: Specifies the name of the process (as an example, msmpeng.exe) that will be terminated
  • /f : Specifies that processes be forcefully ended

Once again, there are no checks that the process is actually running. TaskKill produces “process not found” errors printed to the console for attempts to kill non-existent processes.

Our sample contained a hardcoded list of 997 processes to kill. See the Appendix: Windows Process Termination List for the complete list.

Disk enumeration

Next, Windows LUNA executed with no arguments uses a function called get_all_drives to brute-force the enumeration of all the available drives by going through the English alphabet and verifying if the drives are mapped to the machine using Rust library std::fs::read_dir. If the volume exists, it will be flagged for encryption at a later stage.

All volumes identified are then passed to LUNA’s walk_dir function that will drop ransom notes, enumerate subdirectories, and encrypt files similar to the Linux version with the exact same ransomware note.

Windows exclusions

Unlike the Linux version, however, the Windows LUNA file and folder exclusions are respected to prevent making the targeted machine inoperable or inadvertently stopping encryption prematurely.

We compared these exclusions with those from our CUBA Ransomware Malware Analysis report. LUNA did not include the file extensions .sys or .vbm , both identified in the CUBA analysis. Also, LUNA excludes all of the \Program Files , \ProgramData , and \AppData directories and subdirectories, which CUBA encrypts - or has narrower exclusions to subfolders. This seems like an overly broad exclusion methodology as it misses some valuable data that would be disruptive if encrypted.

Encryption Implementation

LUNA uses a multi-step encryption implementation approach designed to make the author’s decryption tool the only known way to recover targeted files.

Encryption process

The malware author generates a public/private key pair before compilation and embeds the public key in the LUNA binary for later use by the malware. The author maintains the private key until the victim has met their demands.

In many cases, ransomware actors generate a new “author’s” key pair for each victim organization.

Within the add_file function, each time LUNA encounters a new file to encrypt, the malware will generate its own public/private key pair associated with that file. It does this by using the open source library x25519-dalek x25519 elliptic curve Diffie-Hellman key exchange with RngCore::fill_bytes random number generator used for entropy, which is built into Rust.

Elliptic curve (ECC) key generation offers several performance improvements over RSA for equivalent key size. Generally, for a given key size ECC offers greater cryptographic strength and is faster to derive a public key from a private key. This speed improvement helps when a new key pair is generated for every file to be encrypted on a victim machine.

At this point, there are two sets of public/private keys: the authors and the malware’s.

LUNA will then use the malware-generated private key and the author’s embedded public key to derive an AES key.

Files can then be encrypted by chunk with AES in the counter (CTR) mode and an initialization vector (IV). The hardcoded IV is the string “Luna” padded with zeros to be 16 bytes long as required by the AES-CTR cipher algorithm.

Initialization vectors are broadly used in cryptography to provide input to initialize the state of the cipher algorithm before the plaintext is encrypted. In most other contexts it is randomized and shared with the public key. This randomization provides a similar function to salt for hashed passwords.

Using the std::io::Seek trait, Rust is able to abstract the OS appropriate seek , ie lseek for Linux. The malware uses this function to read data from the target file, encrypt it, and write it back to the original file.

LUNA first overwrites the original file with the encrypted content, then appends the malware’s public key created for that file and the string “Luna” as a file marker. The extension .Luna is then added to the filename.

At this point, the AES and malware’s private keys are no longer needed and must be destroyed so only the author’s private key can be used for decryption.

LUNA then moves to the next file and starts again.

Decryption process

In order to decrypt a file encrypted with this method we need the AES key and the IV. The IV is hardcoded into the malware and already known, however, the AES key is discarded once the file is encrypted. The AES key was initially generated using the malware’s private key and the author’s public key, but the malware’s private key has also been discarded.

While we also have the malware’s public key in the encrypted file itself, the author’s private key is required, in combination with the malware's public key, to derive the AES key. The AES key in combination with the hardcoded IV can then be used to decrypt each encrypted chunk.

Below you can see a graphic outlining the encryption and decryption process of the LUNA ransomware.

Chunk encryption

Like many ransomware families, LUNA encrypts files differently based on size. This serves to enhance performance and allows the ransomware to make a larger volume of data unusable in a shorter period of time.

If the file is smaller than 320 kB the entire contents of the file are encrypted using the above-described method. If the file size is between 320 kB and approximately 3 MB then only the first 320 kB will be encrypted. For files larger than approximately 3 MB LUNA will encrypt 320 kB chunks deriving the space between chunks by a byte value calculated at run-time based on the file size.

LUNA encryption POC

If you're interested in trying this out yourself to see the encryption/decryption process in action, check out Elastic's Malware Analysis and Reverse Engineering (MARE) team's Python POC in the LUNA Encryption POC Appendix. This script illustrates the implementation of the LUNA encryption/decryption mechanism.

Résumé

The samples were nearly identical in their core functionality of the -dir and -file execution paths, the encryption mechanisms utilized, and hard-coded values. Hardcoded value similarities include:

• Extension exclusion values
• Folder exclusion values
• Initialization vector
• Author’s public key
• Ransomware note

The most obvious difference between the two LUNA samples we looked at is the enhanced functionality of the Windows PE sample when provided no arguments and the adherence to the extension and folder exclusions for Windows.

There are many differences between the two OS packages; it is probably more convenient to provide a single decryption tool for all endpoints ransomed, irrespective of the OS. A uniform encryption and decryption framework could indicate that the LUNA ransomware is used in a Ransomware-as-a-Service implementation or that LUNA is provided as a kit that can be tailored to specific campaigns.

These differences and similarities lead us to the following assessments of these samples:

1. The Windows sample is much more mature than the Linux sample as reflected in the drive enumeration, services disable/stop, process termination, and exclusions employed to enable the malware to be deployed broadly with little detailed knowledge of the victim machines.

2. The Linux sample contains vestigial Windows features. The exclusions could be modified to fit some specific Linux distributions, but it could be a challenge to create one list that has broad coverage in the diverse Linux ecosystem.

3. The service disable/stop and process terminate lists are very large when compared to other mature ransomware samples. While it does not impede the encryption function of the malware, it generates a tremendous amount of noise that could alert defenders. Calling sc config [service] start=disabled and net stop 253 times for many services that do not exist, or taskkill /im 997 times for processes that do not exist provides an excellent opportunity to interdict ransomware execution before encryption begins. This would be much quieter with prior service and process enumeration, as is common with other ransomware campaigns.

4. The Linux sample did not include the safeguards built into the Windows variant. This caused the Linux sample to encrypt files needed to validate entitlements to system files, such as the sudoers and passwd files. Possibilities, why the Linux sample did not include safeguards :

   1. the malware authors did not have a firm enough understanding of Linux system files and directories to know what should be excluded;
   2. a time constraint prevented the completion of a mature Linux sample;
   3. a lack of widely available ransomware exclusions lists for Linux;
   4. inclusion of a Linux sample was opportunistic because the sample was developed in Rust, which is cross-platform; or
   5. Linux capabilities were included as a “selling point” for a Ransomware-as-a-Service offering

Observed Adversary Tactics and Techniques

Tactiques

Using the MITRE ATT&CK® framework, tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Découverte
• Évasion par la défense
• Impact

Techniques / sub techniques

Les techniques et les sous techniques représentent la manière dont un adversaire atteint un objectif tactique en effectuant une action.

Observed techniques/sub techniques:

• Indicator Removal on Host
• File and Directory Discovery
• System Service Discovery
• Data Encrypted for Impact

Détections

Our detection/protection philosophy regarding ransomware focuses on pre-encryption detection when defenders still have an opportunity to interdict malware execution before data is lost.

YARA

For LUNA Windows and Linux variants, the YARA rule below detects strings embedded in the malware and byte sequences related to core functionality.

rule Multi_Ransomware_LUNA {
    meta:
        Author = “Elastic Security”
        creation_date = "2022-08-02"
        os = "Linux, Windows"
        arch = "x86"
        category_type = "Ransomware"
        family = "LUNA"
        threat_name = "Multi.Ransomware.LUNA"
        reference_sample = "1cbbf108f44c8f4babde546d26425ca5340dccf878d306b90eb0fbec2f83ab51"
    strings:
        $str_extensions = ".ini.exe.dll.lnk"
        $str_ransomnote_bs64 = "W1dIQVQgSEFQUEVORUQ/XQ0KDQpBbGwgeW91ciBmaWxlcyB3ZXJlIG1vdmVkIHRvIHNlY3VyZSBzdG9yYWdlLg0KTm9ib"
        $str_path = "/home/username/"
        $str_error1 = "Error while writing encrypted data to:"
        $str_error2 = "Error while writing public key to:"
        $str_error3 = "Error while renaming file:"
        $chunk_calculation0 = { 48 8D ?? 00 00 48 F4 48 B9 8B 3D 10 B6 9A 5A B4 36 48 F7 E1 48 }
        $chunk_calculation1 = { 48 C1 EA 12 48 89 D0 48 C1 E0 05 48 29 D0 48 29 D0 48 3D C4 EA 00 00 }
    condition:
        5 of ($str_*) or all of ($chunk_*)
}

Endpoint rules

For Windows LUNA there is the opportunity to prevent execution before encryption in the “no arguments” execution flow. As outlined in the previous sections, this execution flow attempts to disable and stop 253 services and terminate 997 processes whether or not they exist on the victim machine.

Our Threat Research And Detection Engineering team (TRADE) tuned and promoted a behavioral endpoint rule targeting these pre-encryption environmental preparation TTPs.

The below rule identifies and prevents attempts to disable the Windows Defender services.

query = '''
process where event.action == "start" and
  process.pe.original_file_name : ("net.exe", "sc.exe", "cmd.exe") and
  process.command_line : ("*disabled*", "*stop*") and process.command_line : ("*WdNisSvc*", "*WinDefend*") and
    (process.parent.executable :
                    ("?:\\Windows\\Microsoft.NET\\*",
                     "?:\\Users\\*",
                     "?:\\ProgramData\\*") or
    process.parent.name : ("rundll32.exe", "regsvr32.exe", "wscript.exe", "cscript.exe", "powershell.exe", "mshta.exe"))
'''

optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

Références

Les éléments suivants ont été référencés tout au long de la recherche ci-dessus :

• https://securelist.com/LUNA-black-basta-ransomware/106950/
• https://www.virustotal.com/gui/file/1cbbf108f44c8f4babde546d26425ca5340dccf878d306b90eb0fbec2f83ab51
• https://www.virustotal.com/gui/file/ad8d568811e05e12cde78f76c3b7cbbde0d20aee5b4e918a3a8d515f5e242bb6

Annexe

LUNA encryption POC

We are providing an encryption POC, written in Python, that mimics and visualizes the encryption implementation of the LUNA ransomware.

Note: like LUNA, each time the script is run, the encrypted output will be different because the private keys are generated each time.

Prerequisites:

• Pyton 3
• cryptography and termcolor Python modules

Usage:

• Save the below script as luna_encryption_poc.py
• install the dependencies with pip install --user cryptography termcolor
• execute the script with python luna_encryption_poc.py

from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.primitives.asymmetric import x25519

from termcolor import colored

# Malware author generates public key and embeds into malware, keeps private key for decryption later
author_private_key = x25519.X25519PrivateKey.generate()         # Unknown author's priv_key generation method
author_embedded_public_key = author_private_key.public_key()

# Malware generates key pair
malware_private_key = x25519.X25519PrivateKey.generate()
malware_public_key = malware_private_key.public_key()

# Serialization of malware pub_key
malware_public_bytes = malware_public_key.public_bytes(encoding=serialization.Encoding.Raw,
  format=serialization.PublicFormat.Raw)
print("Malware Public Key:  ", colored(malware_public_bytes.hex(), "blue"))

# AES key generated by malware's private key and author's embedded public key
# malware_private_key is discarded after this step and not needed for decryption
shared_key_generated = malware_private_key.exchange(author_embedded_public_key)
print("Generated Shared Key (AES): " + colored(shared_key_generated.hex(), "cyan"))

# Encryption Step with AES + IV null-padded LUNA string
iv = bytearray(b'4c756e6100000000')                             # 'Luna....' 16 bytes sized needed for AES CTR

# AES stream cipher (CTR) created using AES shared key and IV
cipher = Cipher(algorithms.AES(shared_key_generated), modes.CTR(iv))
encryptor = cipher.encryptor()

# String to be encrypted
plaintext = b"You know, for search!"
print("Plaintext: ", colored(plaintext, "green"))
print("Plaintext.hex(): ", colored(plaintext.hex(), "green"))

# Encryption of string using AES stream cipher
ct = encryptor.update(plaintext) + encryptor.finalize()

# Mock encrypted file with cipher text + public bytes + file marker
file_marker = b"Luna"                                           # 0x4c756e61
encrypted_file = ct + malware_public_bytes + file_marker

file_ciphertext = encrypted_file[:-36]
pub_key_from_encrypted_file = encrypted_file[-36:-4]
file_marker_from_encrypted_file = encrypted_file[-4:]

print("Encrypted File contents: \n",
    colored(file_ciphertext.hex(), "red"),
    colored(pub_key_from_encrypted_file.hex(), "blue"),
    colored(file_marker_from_encrypted_file.hex(), "yellow"))
print("\t",
    colored("Encrypted content", "red"), "        ",
    colored("Embedded malware's pub_key", "blue"), "       ",
    colored("Embedded file marker", "yellow"))

# Serialization
malware_public_key_from_file = x25519.X25519PublicKey.from_public_bytes(pub_key_from_encrypted_file)

# AES key derived from author's private key and malware embedded public key
shared_key_derived = author_private_key.exchange(malware_public_key_from_file)
print("Derived Shared Key (AES): ", colored(shared_key_derived.hex(), "cyan"))

# Decryption using derived AES shared key and IV
redo_cipher = Cipher(algorithms.AES(shared_key_derived), modes.CTR(iv))
decryptor = redo_cipher.decryptor()
result = decryptor.update(file_ciphertext) + decryptor.finalize()
print("Decrypted plaintext: ", colored(result, "green"))

This Python script will display the malware public key, the shared AES key, the plain text as a string, the plain text as a hex value, the encrypted text, and finally decrypt the encrypted text back into the original plain text as a string.

Windows services termination list

Windows process termination list