Hey guys! Few days ago I was looking at different malwares and accidentally I ran jigsaw.exe. It turned out pretty bad for my files but I thought why not analyze it and maybe try to crack it.
Jigsaw Ransomware, named after the iconic character that appears in the ransom note, will delete files every hour and each time the infection starts until you pay the ransom. At this time is currently unknown how this ransomware is distributed.
You can find the ransomware here, but I suggest you to use a VM before running the executable. Okay, so once you have downloaded and extracted the exec file, run it in your VM. I prefer using either Windows 7/8 because the newer versions of Windows are frequently updated with security patches and come enabled with defenders that might block some of the processes even after disabling the defender.
I’ll be using Windows 7. So once you run the jigsaw.exe, wait for few seconds and then you will see something like this on your screen.
Click OK and wait for some more time and then you see something like this.
So now, we know that the file jigsaw.exe successfully executed and it must have injected some malicious process. So now, we’ll take a snapshot of this current state of the VM in order to create a mem dump that contains all the processes: system as well as injected.
Now we create the mem dump. For creating the mem dump, you can refer to my previous blog, where I’ve quickly discussed all the steps create a .raw memory dump that is suitable for malware analysis.
Okay, so let’s jump into the mem dump now. Once, we have the mem dump, first thing I’ll do is view the info about the dump that I just created.
We can use the command
volatility -f jigsaw.raw imageinfo for this.
I’ll be using the profile Win7SP1x64 as it is the first profile that is suggested by volatility.
With the help of
pslist plugin, we can view all the processes that were running in the system at the time of snapshot.
Now the first thing you can try here, is that you can verify all the processes by googling to see if any process is malicious or not. But most of the processes here are generated by the system. But there was one process that I found malicious which was
drpbx.exe having process ID
2344 and when I Googled it, I got these results:
The first thing I saw was that this process was present in the Jigsaw ransomware. So after further research I came to know that two processes are injected by jigsaw malware in total. One being
drpbx.exe other being
firefox.exe which sets a specific registry key that allows to install itself for autorun at windows startup. So whenever you restart your system,
firefox.exe will be injected as well. So in our dump we only have
drpbx.exe and it is the one that is getting injected every time. So let’s analyse it in depth.
To display a process’s loaded DLLs, use the
Here, the command that I’ve used to view the DLLs of
volatility.exe -f jigsaw.raw --profile=Win7SP1x64 dlllist -p 2344
Analysing the DLLs, I found two which were suspicious in this case, considering that it is a ransomware. These are APIs to perform the encryption operations.
So till now, we’ve verified three things:
• It replicates itself with two files:
• It modifies registry keys to launch itself at windows’ startup.
• It uses CryptEncrypt API to perform the encryption operations.
Now to verify if
drpbx.exe is an independent process or not, I’ll dump this process and run it.
For dumping a specific process, the command is:
volatility.exe -f jigsaw.raw --profile=Win7SP1x64 procdump -p 2344 --dump-dir ./dump
Now, be cautious as this is the infected process. Donot run this on your computer.
Here, I can use VirusTotal to verify if this is a pre-existing malware file or not.
As it gets confirmed that this is the file we were looking for. So, our next goal would be to break down this file.
This is a .NET 32-bit executable file. Thus, I’ll be using a tool called ILSpy to decompile this .NET exec.
m m m This shows the EncryptionPassword as well the Extension of the files after getting encrypted.
EncryptionPassword was OoIsAwwF23cICQoLDA0ODe== which when converted into binary gives
That is actually
192-bits. That means the password is using a 192-bit encryption.
The result of the malware execution is that all non essential files are encrypted and they have a
Going further, I was able to find a function
AesCrytoServiceProvider that shows that the encryption taking place is
The following class was basically responsible for entire Encryption and Decryption of files.
You can have the access to entire encryption code, here:
Thus, we found out the malicious processes, then dumped that process, found the APIs used for encryption along with the EncryptionKey and entire encryption/decryption algorithm.
I am also in process of writing my own decryptor for Jigsaw Ransomware. Once done, I’ll share that too!
Until next time! :D