A Conti-nuous issue

Introduction

In this blog, we shed light on our findings during a forensic investigation in the aftermath of a cyber attack. The initial attack began by exploiting a vulnerable PaperCut instance. The fact that vulnerable software leads to ransomware deployment is not unique. But what is uniquely valuable for companies are Eye Security’s cyber-experts and incident responders. They can undertake forensic analysis to find the true source of the attack - in this case Bl00dy. Armed with this information, we better understand the likely impact of such an attack on a given company and work in a more focused way to resolve the problem.

By sharing our expert analysis, we hope to help organisations improve their detection ability and become more resilient.

How it started

Recently, a company that fell victim to a ransomware attack gave us a call. Our Incident Response team quickly sprang into action, rolled out our Endpoint Detection and Response (EDR) software, contained the issue and started monitoring the client’s computer systems.

We noticed that several files were heavily modified and had a new extension appended, this new extension was .hack0. After a quick search we also found a file resembling the ransomware note, this note read as follows:

Don't Panic !!!!!

Files Are Encrypted and Can be absolutely Decrypted (reversed) to normal file again.

ALL Your Encrypted Files can be decrypted immediately and instantly 

IF You pay the money we request  in bitcoin.

Name your price ; Your price tells us how much important your files are to you.

Write to us for instant decryption: decrypt.support@privyonline.co

The email address mentioned in the ransomware note the Cybersecurity and Infrastructure Security Agency (CISA) has attributed to the Bl00dy Ransomware group. This group had been abusing CVE-2023-27350 in PaperCut MF and NG to deploy Ransomware in networks.

Finding familiar foes

During an Incident Response engagement, we try to gather as much information as possible. One way is to analyse the binaries left behind by threat actors. This helps us to get an idea of their usage and of other possible Indicators of Compromise. Additionally, we can leverage these insights to further protect our own customers.

During our analysis of this case, we were able to find some binaries we assumed were left behind by the actor. One of these binaries was called protected.exe. By analysing this binary we found out that this executable was most likely responsible for encrypting the network of the victim.

This article will focus on insights into the used binary protected.exe. It was protected with a packer which, after using Detect it Easy, was identified to be Themida/Winlicense [3.XX]. It is important to attempt to unpack this, as this will allow us to see the original program. We were able to unpack the binary using open source tooling, the unlicensed tool.

After verifying that the unpacking was successful we were able to start analyzing the actual encryption program. We quickly noticed that the disassembled code resembled something we've seen previously during other ransomware cases: leaked Conti source code.

One of the things that pointed us in the direction of the Conti source code, was the heavy use of stack string decoding and what these stack strings contained.

We initially decoded these strings with tools such as Angr scripts and the FLARE Obfuscated String Solver the output of these tools gave us several file extensions which the Conti ransomware code specifically targets. An example of the functions can be seen below:

While the examples above are database file extensions, we were also able to find strings indicating SMB functionality and the deletion of shadow copies. These strings, again, match the Conti source code. Additional examples include:

When looking at the logic of the encryption program we see a lot of similarities. The program follows the same steps as the original Conti ransomware. It will enumerate all files and create an object for each file. Here it will use an Enum to specify the required level of encryption for each file:

The Enum values found in the binary align with those found in the leaked Conti source code, further reaffirming the deployment of the leaked code. The Enum values used were:

enum ENCRYPT_MODES : char
{
    FULL_ENCRYPT = 0x24,
    PARTLY_ENCRYPT = 0x25,
    HEADER_ENCRYPT = 0x26
};

Old threats - new techniques

However this particular sample differs from the standard leaked Conti source code, because it seemed that the actor aimed to enhance the evasive capabilities of the ransomware. This is done by using methods described in the RefleXXion project.

The RefleXXion code on GitHub has two techniques which will attempt to bypass or remove ‘hooks’ from AV or EDR. The goal here would be to frustrate the functionality of these systems, rendering them ineffective and allowing the ransomware to run without being detected. Hooking is used by AV and EDR products to gain insights into a program’s execution flow and to determine if the executed code would result in malicious behaviour.

RefleXXion uses two techniques to bypass these hooks. The first technique will load ntdll.dllfrom harddisk and will parse the file in an attempt to find the .text section. This section will always contain the executable code of a program. After finding this section, it will check the actual code of ntdll.dll in memory, which is hooked and modified by AV and EDR products. RefleXXion will then overwrite the code in living in memory with the ‘clean’ code it found in the .text section of ntdll.dll .

If this technique fails, it will switch to another technique. Here instead of loading the ntdll.dll from disk, it will attempt to read this DLL from KnownDLLs cache. In similar fashion, it will attempt to find the .text section and again replace the hooked code from memory, with that loaded from the KnownDLLs. These DLL’s in the KnownDLLs cache, are untouched by AV and EDR products.

Both techniques are implemented in the sample we analysed. Here we can see part of the syscall enumeration process of RefleXXion:

It is interesting to note that the inclusion of the code seems to be done hastily. The original Conti source code has several methods to obfuscate strings and make analysis harder. None of these methods seems to be used in this sample to hide its functionality.

Conclusion

The inclusion of code that enhances the evasive capabilities of previously known ransomware samples, could signify that actors are improving older ransomware code, in both form and function. These modifications change the behaviour and are aimed at making detection harder.

The usage of leaked ransomware code is something we’ve seen more and more in recent months, where both new and experienced actors use the same leaked ransomware strains in their modified and unmodified forms. The availability of leaked ransomware code lowers the barrier of entry for criminals to try their luck in earning some money.

Because criminals don’t have to develop their own tooling, they can operate this part without much knowledge about coding or security concepts. The availability of this tooling could allow actors to quickly and frequently change parts of their Tactics, Techniques, and Procedures (TTPs), which could make tracking groups more challenging.

This dynamic landscape underscores the need for heightened efforts in enhancing detection and defence mechanisms to effectively mitigate the growing risks posed by these actors.

Indicators of compromise