Analysis of LockerGoga Ransomware

We recently observed a new ransomware variant (which our products detect as Trojan.TR/LockerGoga.qnfzd) circulating in the wild. In this post, we’ll provide some technical details of the new variant’s functionalities, as well as some Indicators of Compromise (IOCs).

Overview

Compared to other ransomware variants that use Window’s CRT library functions, this new variant relies heavily on the less commonly used Boost library. For example, instead CRT’s rename function, it uses boost::filesystem::rename. The change makes technical analysis more difficult for researchers, as it makes function identification harder.

The functionalities for file enumeration and file encryption are split into different processes. File path sharing happens using the Boost.Interprocess library, which makes it harder to analyze the processes separately.

File encryption

If we execute the sample without any arguments, it moves the executable to the %TEMP% directory with hard coded name “tgytutrc{number}.exe” and executes it with the “-m” argument (where “m” stands for “master process”):

As we can see on the screenshot, the main executable uses functions from Boost library to copy and execute the sample.

exec_from_first

first_create_process_api_monitor

The main functionality is inside the “master” process, it enumerates files on the infected system and executes child processes to encrypt files.

If we provide additional argument “-l”, the process will create “C:\\.log.txt” file and write file paths and error messages.

To parse command line arguments, the sample uses Boost.Program_options library (ref. screenshot below)

master_process

Before starting the encryption phase, the “master” process enumerates sessions and logs off from all but the current process’s session.

The process uses ProcessIdToSessionId function to get a session associated with the current process.

enum_sessions_second

This is a list of active sessions on a test machine since session “1” is the session of the process, it logs off only from session “0”:

enumerate_sessions

After that, the “master” process changes the password for all administrator accounts to “HuHuHUHoHo283283@dJD“.

I’ve created a standard user, but it only changes the password for administrator accounts:

second_changes_admin_passwords

The “master” process creates a “shared memory” using the Boost.Interprocess library and executes child processes (in the same executable) with the argument “-i SM-tgytutrc -s”, where “-i ” specifies a shared section name and “-s” stands for “slave”.

According to Wikipedia: “shared memory is memory that may be simultaneously accessed by multiple programs with an intent to provide communication among them or avoid redundant copies

On the screenshot, we see that, after changing passwords, it uses Boost library to initialize shared memory and execute child processes (“slave” processes):

change_admi_pswds_create_subProc

slave_proc

Next, the “master” process enumerates files and writes their paths (encoded with Base64) in the shared memory.

The process uses Boost::Filesystem library to query paths, files, and directories:

boost_lib_files_enum

File paths are encoded with Base64:

shared_memory

Child processes decode the data from the shared memory.
The data on the shared memory has the following structure: The first “DWORD” represents the file index, while the second one represents the size of the “base64” encoded data:

base64_encoded_from_third_

After decoding a file path, a child process generates a key/IV pair using the Crypto++ library.

OS_RNG” function uses CryptoGenRandom function from Windows, another function is from Crypto++ library to generate a random numbers:

third_generate_key_iv

Before the encryption, a “slave” process renames a file using Boost::Filesystem::rename function:

third_remove_locked_and_rename_to_lockedNext, the child process encrypts the file’s content using the Rijndael algorithm. It also appends the generated key/IV pair in an encrypted form to the end of the file. The key/IV pair is encrypted with the public key, which is embedded in the executable:

third_append_enc_key_iv

After it encrypts a file, a child process overwrites the first byte of the encoded data in shared memory with a “0” byte.

overwrite_first_byte_after_reading_filePath

Network changes

After the encryption phase, the “master” process enumerates all network interfaces and disables them.

List of active adapters on my test machine:

list_of_adapters

The “master” process disables them one by one:

disable_interfaces

Next, it deletes the executable via “.bat” file which contains commands to delete the executable and the bat file itself.

second_end_delete_

At the end it logs off the current process’s session:

second_logoff_current_session

Conclusion

Overall, the latest variant of the LockerGoga ransomware is not complex or complicated. Because it uses the Boost library and Crypto++ instead of the more common CRT library functions however, it does make it a bit more troublesome for a threat researcher to analyze the sample.

Indicators of compromise (IOCs)

SHA256:

  • C97d9bbc80b573bdeeda3812f4d00e5183493dd0d5805e2508728f65977dda15

Hard coded mutexes:

  • MX-tgytutrc

Directory with malicious executables:

  • %APPDATA%\Local\Temp\tgytutrc8.exe


Articles with similar Tags