The ransomware builders remind me old times, where Nukes and Exploiters were freely available on the underground communities, when few clicks were enough to bypass many AV vendors and attackers were activists or single people challenging the system. Nowadays the way the “builders” are developed and the way the criminality is abusing them to generate new Malware is a lot more sophisticated compared to 20 years ago during the romantic “hacking for fun” era. The impact of such a Malware in the contemporary society is something that needs high attention since the digitization approaching the entire world. For such a reasons I believe it would be interesting to study, when possible and when available, how Ransomware Builder have been developed. The main attentions nowadays is on Ransomware binaries rather than on builders, but since “builders” are (in a way) more closed to the Malware developer — in fact generated ransomware are very similar each other because automatically generated by the builder — I believe that studying the builders would give us a more closed knowledge about the Malware author.
Light Technical Analysis
Before getting into code, it would be useful to remind that Paradise Ransomware was firstly launched on 2017 through phishing emails containing malicious IQY attachments that downloaded and installed the ransomware. The first versions of the ransomware contains flaws that allowed international researchers to build a free decryption tool (for details HERE) able to recover files from the old version of the Ransomware. After some revisions the Ransomware became strongest by adopting RSA encryption which made impossible the decryption without the private key.
As reported by BleepingComputer (HERE) source code leaked during this (2021) summer on XSS.IS forum.
The source code is written on .NET, by giving it a chance to run on a local and virtualozed environment, it runs smoothly and without any issue on a basic version of .NET framework over a Microsoft Visual Studio.
The leaked source code looks like following the default structure on Microsoft VS. As you might appreciate from the following image the leaked folder structure is simple and lean.
After a quick and incomplete overview of the code it is possible to appreciate several “quick findings”. While the produced ransomware (Paradise) is something that eventually will get of public domain (since inoculated on victims machines) the attacker would insert a lot of “security check” (in order to get harder the analyst life) but the builder is used to be a confidential “piece of code” which is hold by affiliate criminal groups and for such a reason the developer ( which works with limited amount of time – he needs to make economy himself -) is not used to implement checks and precautions used in the final payload. So here they are, quick findings ahead.
- Language: Russian. Over the source code it’s easy to find developer comments, which according to google, belongs with Russian language.
- Username of building computer: MALIKA. Microsoft Visual Studio lets some information regarding the user who compiles the source code into binary. These information are reported into .csproj file used to configure the environment settings for compiling and linking time. The following image shows the the username used to compile the project.
- Configurable settings: Keys and More. Instead of getting configuration files from external resources the builder (acting as a server) needs to be configured introducing configuration strings directly on the source code. It looks like the builder is made for advanced users only (maybe internal usage and not for affiliate?).
- Ransomware name: Paradise. Strings and configuration takes the analyst to believe this builder is really the Paradise builder even from an inside perspective.
- In memory name:
dp_main. Even if you run Paradise Ransomware with different configuration name, the system would add a
dp_mainin the running environment memory. Indeed the sample count on such a string in order to understand how many parallel processes are running
Beside the “quick findings” it would be interesting to check used practices and Ransomware characteristics. One of the first characteristics is in the persistence method. While the “Autorun” is quite simple and very abused the Paradise ransomware seems to copy itself in a specific directory named
DP (under the romantic
appdata service directory) and looks like it names the Paradise Ransomware always in the same way, uncaring about configuration settings. The name is
DP_Main.exe as showed in the code below.
Shadow copies deletion is quite a standard practice for successfully ransomware. Even in this case the action is quite standard, by running the following command in a cmd.exe:
ProcessStartInfo psiOpt = new ProcessStartInfo(@"cmd.exe", @"/C sc delete VSS");
Interesting and quite characteristic the way Paradise Ransomware does check-in into its command and control system. From this function it would be possible to serialize a network detection rule (even if would be quite general, so pay attention to false positives in case you are going to implement it ) such as:
One of the most interesting piece of code (at least in my personal point of view) is in the way the sample manage encryption keys. Getting into details, what moves my interest starts from the main function at line
718 which I report following.
In other words if in the systems (host) there is no keys, Paradise Ransomware generates them and save both of them on the local machine ! Unfortunately the process to save private keys to HD does it well by encrypting them, but … there is still something to do here (bu I’m not going to stress out this pint out). Most interesting for the analysis is the process that uses this Ransomware to deal with keys. The following image shows the function named
SavePrivateKey, which actually does not what you aspect to do.
SavePrivateKey the attacker actually saves a combination between encrypted(private) key and public RSA key as shown in the previous image. Indeed it then calls a new function named
SavekeysToFiles which saves them into a unique files called
DecryptionInfo.auth. Finally one more interesting characteristic is in the way Paradise encrypts files. A questionable choice by Malware author is the ability to encrypt “only” the first 10MB of big files. If the files are smaller it divides file in 117 bytes and loops over them.
Following the analyzed files composing the leaked codebase.
Every code owns specific characteristics, every Malware Author makes decisions and such decision reflect in the way they write source code. Analyzing Malware source code lets us the ability to compare style and design patterns. Today in my quick Paradise Ransomware source code analysis I highlighted only few of the many characteristics that could be observed by reading someone else’s code. I believe that sharing this information would be useful to everybody working in cyber defense sphere.