Cyber criminals find opportunities within their own den of thieves. Recent findings published by Secureworks, suggest that REvil is being binary edited and used by LV Ransomware, for their own profit. Yes, malware creators are being exploited by other criminals, who aren’t investing resources to create a capability from scratch. LV Ransomware has figured out how to partially reverse engineer REvil’s malware, using readily available tools.

What Is LV Ransomware?

The REvil/Sodinokibi ransomware was first discussed in a Threat Report from May 2019, soon after it was first discovered. It rapidly rose to prominence as a RaaS (Ransomware-as-a-Service) offering, filling the void created by the disappearance of the GandCrab ransomware group. By some accounts, REvil ransomware is responsible for approximately 4 percent of attacks and was one of the first to utilize the tactic of leaking and selling stolen data in an attempt to increase pressure on victims to pay the ransom, a tactic now generally referred to as double extortion. In late 2020, the REvil developers claimed to be profiting to tune of over $US100 million a year, and that’s just their share, with the bulk of the profits going to the “affiliates,” the customers who utilize REvil for attacks via the RaaS offering.

Based on findings released by researchers from Secureworks, it appears that one of REvil’s rivals, LV Ransomware, may just be a pirated copy of REvil. This is a somewhat an ironic situation, of cyber criminals having their malware appropriated by another group without authorization. Adding insult to injury, it appears the theft, may not  have been too difficult to achieve. Using some reverse engineering skills and a few simple tools, including a hex editor, the LV Ransomware “authors” have replaced the encrypted configuration file, stored inside the malicious payload, itself stored inside the REvil/LV Ransomware executable. This process did not require any access to, or knowledge of, the REvil source code.

During analysis, the BluVector Threat Team performed the steps, using a publicly available LV Ransomware sample. The first step was  to unpack the malicious payload from the LV Ransomware sample. The malicious payload was encrypted and  stored in the enc section of the sample. The 32 byte key used to decrypt the payload was stored as two separate 16 byte strings in the .rdata section of the sample. The payload can be decrypted using the key and the RC4 algorithm. The payload is the actual LV Ransomware executable.

Data key used to decrypt the payload.

Decrypting the configuration file found in the payload executable is a very similar process. The .7tdlvx section contains the encrypted configuration file; the key:, a hash of the encrypted data; and the length of the configuration data. This time the key is the first 32 bytes of the .7tdlvx section. Once again, using the key and the RC4 algorithm – the configuration file, a JSON formatted text file, can be decoded. The configuration used by LV Ransomware samples contains an empty dmn entry, in REvil samples this is used to specify Command & Control (C2)sites, potentially indicating LV’s authors do not yethave a backend infrastructure mirroring REvil’s. This point adds further credence to the theory LV Ransomware is based solely on reverse engineering a REvil sample, with no visibility to other components of the full REvil infrastructure.

7tdlvx key
Config file

Once the LV Ransomware author obtained an un-encrypted copy of the configuration file following these steps, they could modify it to meet their needs. The most obvious modification being the ransom note text. Once the configuration file is modified, it’s basically the reverse process to create a functioning LV Ransomware sample. First the configuration file is encrypted using a 32 byte key, then the key, encrypted configuration hash, configuration length and the encrypted configuration are put into the .7tdlvx section. This is  a process which can be achieved using a hex editor. Then the edited payload executable itself, needs to be re-encrypted, using the key from the .rdata section. It is then placed in the enc section, within a copy of the original sample. This step, once again, can be performed using a hex editor.

LV Ransom Note

The end result is that the LV Ransomware authors now have a functioning version of REvil ransomware utilizing the configuration file they altered to their needs. As previously stated, all it took was some reverse engineering knowledge and a few tools, mainly a hex editor. However, to paraphrase the words of  Dr. Ian Malcolm in the first Jurassic Park movie, perhaps the LV Ransomware authors were too focused on whether they could have done this, rather than spending time considering if they should have done it. As mentioned, REvil ransomware is a highly lucrative enterprise and it’s developers are unlikely to take kindly to individuals, or groups, profiting from their malware. Often large scale cyber criminal operations are backed by, or directly operated by organized crime, which makes “pirating” REvil ransomware a potentially unwise undertaking, to say the least. Secureworks researchers stated they found no evidence of LV Ransomware being advertised on the usual dark web forums. Knowing thi, and the apparent lack of any LV Ransomware backend infrastructure, strongly suggest, it is a lone wolf operation. A lone wolf looking to secure a small portion of  ransomware profits for themselves.

How Does It Propagate?

The malware does not contain the necessary code to self-propagate. LV ransomware is known to use spam emails containing malicious attachments as the initial attack vector.

When/How Did BluVector Detect It?

Six samples (including one which was unpacked) are publicly available and BluVector’s patented Machine Learning Engine (MLE) detected them all. Regression testing has shown the samples would have been detected for an average of 84.5 months prior to their release.