MedusaLocker ransomware – Part 2

Ransomware Denes Fodor todayMay 27, 2024 134

share close

We are a little late with the second part of the MedusaLocker ransomware series, but we have good reasons. Check out our LinkedIn site to see what we were busy with. 😊

In the first part, we discussed the nature of ransomware attacks and some aspects of MedusaLocker’s behavior. Now, we’ll delve into the malware analysis and explain why it’s interesting.

Our story

We were helping with a ransomware incident, the adversary was able to encrypt almost everything, the file servers, workstations, and backups as well. During our investigation we have found a familiar tool which was used by the threat actor to create persistence and communication between the C2 and the victim, the popular “FRPC”, which is a reverse proxy tool that can be used to expose anything from the inside to the outside bypassing firewalls. It also offers P2P connection mode, which comes very handy, not just for malicious actors.

The adversary has created two configurations for the FRPC, one for the Windows machines (“windows.toml”) and another for Linux (“linux.toml”). Let’s look at the “linux.toml” file, it contains the credentials and the destination server address in plain text. The IP address belongs to a hosting company located in Russia.


Now, the threatening ransomware

Medusa Locker is known and well documented, there have been multiple -slightly different – variations of it in the last 3-4 years. The core logic of the ransomware is the same, but there are differences in the implementation of logic that check whether the victim machine has been infected, e.g., using mutex[1], registry keys or the values of the encryption keys, and so on…

The strangeness of the attack we investigated is that the attackers have infected the environment twice in a short time and probably because of some issues they used PE (on Windows) and an ELF (on Unix) version of the malware.

As we have not seen any documentation about linux variation, we have decided to collect some interesting details about both and share our findings regarding the other components of the incident, like the C2 solution implemented.

Bonus: This post provides our readers with a short look at the inside of the decryptor.

Of course, we are trying not to create another technical analysis that was written before by other researchers.

Let’s start with the linux variant, it is called “33.out”.


Based on the readelf’s output, it seems like it was built on an older version of linux.


To be more specific, it was built on a Debian Wheezy which supports ended in 2018.


The windows variant’s original name is also “33_c_s.exe” and it was built on the 28 of November 2023. Keep that date in mind, it will be important later.

Both samples contain a resource file (on Windows it’s “SETTINGS”), they share the same XOR-key, and both have a string “PUTINHUILO1337” which can be found in many variants over the years.

We’ve decoded the resource file, and here is the comparison. On the left side you can see the resource from the PE and the ELF version on the right.


They are slightly different, but both are prepared to encrypt mounted shares from windows and linux filesystem and as you see, this time the “.crypto33” file extension was used, which explains the naming convention of the samples.

The malware parses this JSON file to read its actual configuration and about that element we have found a strange string in the PE version: 961c151d2e87f2686a955a9be24d316f1362bf21 3.11.2

Okay-okay, but what does it mean?

After some googling, we came across a previous finding of a researcher ( who already solved the mystery; it is a SHA1 hash of the string “JSON for Modern C++”.

It is a JSON library for C++ (, and if you remember the built date of the PE file (November 28, 2023) you can see that the version 3.11.3 was built on the same date, so the adversary has done an excellent job keeping up with the updates.

But let’s see what’s under the hood of the ELF:


It uses a well-known XOR decoding logic for the configuration file.

Of course, after that it parses the configuration file.



Creates an identifier (1280 bytes, base64 encoded blob) which is included in the ransom note. This value can be important for the attackers, as it’s a technical requirement to create the decryptors if the victim decides to pay the ransom.


Then enumerates the filesystem, goes through the directories, mounted devices (like shares) and encrypts everything that is not on the list of extension exceptions (aka. Skipping list). After that, it creates the ransom note in the directory where the files were encrypted.


All that is pretty much the same in the PE version, except, the ransomware creates a registry key named “PAIDMEMES” and two subkey, named “PUBLIC” and “PRIVATE” for the corresponding part of the RSA keys. TrendMicro has analyzed and documented this behavior before:

The RSA keys, which were used to encrypt the AES keys and subsequently the files, are encrypted with the hard-coded “MasterKey” in the config file. On the Linux machine, we didn’t find any keys that could correspond with the registry values “PUBLIC” and “PRIVATE”. Despite this, the ransomware functioned on Linux, suggesting these keys are not required for the encryption process.

But let’s talk about the encrypted files and their structure.

All the – encrypted – files have 1556 bytes long (0x614) blob appended to the end:

MedusaLocker-10The blob starts at offset 0x46BE.

Just before we find the magic bytes of JPG file end 0XFFD9 – which means that the AES and the RSA encryptions both were made without padding.




At the end, the last 20 bytes (0x14) are a footer. The 2 starting bytes contains the address, where the blob starts, in this case at offset 0x4CBE we see 0x46BE. The last 18 bytes are the same in every encrypted file on this machine.

The blob itself is the same in some files from different folders, except the 2 bytes with the starting address, but we have found 3 different appended blobs. Just guessing, but as the malware contains a “GenerateNewKey” string, we suppose, that it does not change for every file, but sometimes a new key is used.

If we do some calculations, we can see that:

  • the blob is 1556 bytes
  • the footer is 20 bytes
  • the rest is 1536 bytes

Recall that the identifier blob in the ransom note is 1280 bytes. This leads us to believe that the remaining 256 bytes constitute an RSA-2080 key.

The rare opportunity

We had the opportunity to examine the decryptor more closely. It was a PE version, compiled a mere 7 minutes after the cryptor.



A comparison of the two binaries (cryptor and decryptor) using BinDiff reveals an 82% similarity. The decryptor lacks 404 functions present in the cryptor but introduces 7 new functions.


The 7 additional functions in the decryptor (compared to the cryptor) comprise 5 library functions and 2 imported functions.


With a bit investigation their functionality is determined by the decompiler:






The decryptor’s embedded settings are in an XOR-ed JSON format, containing only 3 keys: the encrypted file extension, the RSA private key, and the starting path for decryption.


Okay, but how can we protect against ransomware attacks?

To protect against ransomware attacks, companies and users should keep their systems and applications updated with the latest security patches, avoid opening suspicious emails and attachments, use reputable endpoint security software and firewall to detect and block malicious activities, and backup important data regularly.

In addition, it’s highly recommended to consult with a Managed Security Service Provider (MSSP). An MSSP can provide expert guidance and proactive monitoring to help prevent and respond to threats like MedusaLocker.

The conclusion is that as our reliance on digital systems grows, so does the threat from ransomware like MedusaLocker. Staying informed and taking proactive measures are our best defense against these digital threats.

Allocating resources towards the enhancement of the company’s security measures and maintaining a robust defense system is a more cost-effective strategy than dealing with the financial implications of a ransom payment.


Written by: Denes Fodor

Tagged as: , , , , .

Rate it
Previous post

Cyber security Csaba Krasznay / April 30, 2024

Vulnerability trends in early 2024

What is being hacked and why? With the press reporting serious software vulnerabilities week after week, we investigated whether the situation this year is really as bad as the news suggests. Confluence vulnerability here, Ivanti vulnerability there, all of this [...]

Similar posts